Posted by rotnme on February 8, 2011 at 5:48am
I have posted this problem previously but have still not resolved it. I just got off the phone with my hosting provider (ugh, yes it's go daddy) and they were of no help whatsoever. When I am in site building/modules and click on update.php all I get is a blank screen, no error message, just a blank screen. When this problem first arose I fooled with stuff, I don't actually remember what but nothing resolved it. Since then I have reinstalled drupal 6.20 and am again faced with the same situation. Go daddy was no help, I'm at a loss as to what to do, needless to say I have modules that are in need of updating but I am hesitant just because I cant run update.php. Any thoughts/info is much appreciated.
Mark
Comments
Same as it ever was
Funny, I just launched a site on GoDaddy. They can really turn your head around and add complications where they aren't needed, in the hopes of selling you a service you don't need and they won't adequately support.
Same as it ever was: don't troubleshoot on GD. Troubleshoot locally on your xAMP sandbox. You need to see your AMP error logs to trace the problem. For the record, you can add a php.ini file to the root of your GD account, but this is only for creating an error log, not for increasing memory limits, which is most likely where the problem is on a GD account. Besides, you should have a local dev environment anyhow, right?
Yesterday, my GD site went down while I was performing trivial ckeditor-based content edits. (i.e., WSOD) The fix? Wait. They're internal monitors automatically restart sites that timeout. Sounds great, right? Heck no, it only masks problems. Meanwhile, locally there were no errors in my MAMP box, so I knew that waiting the the solution.
That said
That said, the process of adding new modules tends to require additional php memory, something GD is notoriously deficient at. It is always best to add or update modules locally, not on GD, and then upload. I believe this is Drupal's SOP, regardless of host, anyhow. This moves the vulnerable process to where you can watch it and make informed decisions for corrective actions, without compromising a running site.
Troubleshooting on GD is like bowling in the dark.
A little confused
When you say
Are you referring to the process of un-compressing the tarball? Or are you saying - add the module to local dev site, run update, then upload the site? If the later, does the database automatically pick up the changes? In my uneducated mind, it seams like the site and database would be out of sync.
No
The later. What data set are you using locally? Of course that matters. For forum/comment/social sites, this is a non-trivial matter something you'd have to plan when your site is at it's lowest point in traffic. No, there's no event in updating files that would trigger an automatic database update, besides update it to what?
The files and data should be the most recent copy from your live site. Do the update, and upload the changed files and new database.
Getting Used to the Process
This is good timing for this topic. I'm currently utilizing Drupal Commons for a site I'm developing, which is a fairly complex package (for me anyway) of mods, themes, etc. DC originally had a lot of non-core mods wrapped into what they called "features", a package of mods. In the latest version, they "unpacked" those mods to allow for better updating. In their upgrade instructions the mention to be sure you replace your code, not "merge" it. In other words, a lot of the mods had changed locations and if you just move/extract the files in place, you'd have mods in two different places, etc.
So, in my eyes, the best way to ensure this was to remove all of the old code (except for the sites folder where I have some mods I added) and completely replace it with the new. Ultimately this worked, but the process was a touch scary for someone only 5 months into Drupal (what? I completely wipe out all the old code, put in new and it works just fine? and talks to the database just fine?) I understand the separation of the code and the database and the care developers have to take in ensuring backward compatibility. I'm sure through more experience I'll become more comfortable with the process.
Rob
It depends on your comfort level
Usually; yes. It is really cool.
Drush is an excellent command line utility for drupal that will reap benefit for you time investment in learning it, such as for site updates. WordPress has a convenient interface for updating core and plugins, but drush manages the process better, albeit not as UI friendly.
I can't wait to switch to
I can't wait to switch to another hosting provider, looking into who now. I have a local mamp site but that is working fine. My memory limit on godaddy 192m, config memory limit 64m. This was all set prior to things going awry and all worked just fine.
Try putting this snippet just
Try putting this snippet just below the opening php tag in the index.php file in your Drupal root:
<?phperror_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
?>
Then run update.php and tell us what the output is.
<?php // $Id: index.php,v
<?php // $Id: index.php,v 1.94 2007/12/26 08:46:48 dries Exp $ /** * @file * The PHP page that serves all page requests on a Drupal installation. * * The routines here dispatch control to the appropriate handler, which then * prints the appropriate page. * * All Drupal code is released under the GNU General Public License. * See COPYRIGHT.txt and LICENSE.txt. */ require_once './includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL); $return = menu_execute_active_handler(); // Menu status constants are integers; page content is a string. if (is_int($return)) { switch ($return) { case MENU_NOT_FOUND: drupal_not_found(); break; case MENU_ACCESS_DENIED: drupal_access_denied(); break; case MENU_SITE_OFFLINE: drupal_site_offline(); break; } } elseif (isset($return)) { // Print any value (including an empty string) except NULL or undefined: print theme('page', $return); } drupal_page_footer();tried inserting it everywhere and it broke my site listing error messages at whatever line I put it in at. Thoughts on where you think it should go? I was hoping that this would shed some light on this.
it broke my site listing
it broke my site listing error messages at whatever line I put it in at
Well, those lines aren't breaking your site. They just display the errors as opposed to giving you the blank white screen you were talking about at the beginning of this thread. What we are interested in is the output to your screen. So paste the error messages you are receiving here and that will help us understand what is going on.
A good place to insert those lines is just after the opening php tag in index.php
Parse error: syntax error,
this is what I get
That doesn't seem right at
That doesn't seem right at all. Can you post the first few lines of index.php?
Yup
That's what I'm saying.......
<?php // $Id: index.php,v 1.94 2007/12/26 08:46:48 dries Exp $ /** * @file * The PHP page that serves all page requests on a Drupal installation. * * The routines here dispatch control to the appropriate handler, which then * prints the appropriate page. * * All Drupal code is released under the GNU General Public License. * See COPYRIGHT.txt and LICENSE.txt. */ require_once './includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL); $return = menu_execute_active_handler(); // Menu status constants are integers; page content is a string. if (is_int($return)) { switch ($return) { case MENU_NOT_FOUND: drupal_not_found(); break; case MENU_ACCESS_DENIED: drupal_access_denied(); break; case MENU_SITE_OFFLINE: drupal_site_offline(); break; } } elseif (isset($return)) { // Print any value (including an empty string) except NULL or undefined: print theme('page', $return); } drupal_page_footer();this is index.php....... where exactly should I put your snippet.
Thanks
It should look like
It should look like this:
<?php
// $Id: index.php,v 1.94 2007/12/26 08:46:48 dries Exp $
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
/**
* @file
* The PHP page that serves all page requests on a Drupal installation.
*
* The routines here dispatch control to the appropriate handler, which then
* prints the appropriate page.
*
* All Drupal code is released under the GNU General Public License.
* See COPYRIGHT.txt and LICENSE.txt.
*/
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
$return = menu_execute_active_handler();
// Menu status constants are integers; page content is a string.
if (is_int($return)) {
switch ($return) {
case MENU_NOT_FOUND:
drupal_not_found();
break;
case MENU_ACCESS_DENIED:
drupal_access_denied();
break;
case MENU_SITE_OFFLINE:
drupal_site_offline();
break;
}
}
elseif (isset($return)) {
// Print any value (including an empty string) except NULL or undefined:
print theme('page', $return);
}
drupal_page_footer();
?>
That being said, any thoughts
That being said, any thoughts how I can right this mess?