Support » Fixing WordPress » Site dead after WP upgrade

  • After reading that an upgrade was available, I decided top just overwrite the 3 files mentioned for the security fixes (wp-includes/pluggable.php, wp-admin/includes/media.php and wp-admin/media.php).

    After going back to my site I found it wasn’t working and the blurb mentioned a problem with wp-includes/pluggable.php
    I overwrote it again and the problem was still there so I decided to go ahead with a full upgrade.

    After the upgrade I cleared my cache and went to my site, only to find it is even more messed up now.
    There is too much on the page to paste it here, here is the site in question:

    I don’t know what the problems is or how to fix it.
    Of course I can just restore from a backup (and did) but then I am without the security fixes.

    I’ve since tried the whole process 3 times and still have the same problem.

Viewing 10 replies - 1 through 10 (of 10 total)
  • Actually, it’s getting more wierd now.

    Sometimes the site is showing normally, then it suddenly fails and spouts a load of jargon at me.

    It appears that you have a redirect installed, and for some reason it works some of the time. When I first clicked on your link, I was taken to:
    Which appeared to be ok

    I went back and forth a few times, then your link changed to:
    and I get what appears to be a php listing I don’t recognize, and the errors:
    Warning: Cannot modify header information – headers already sent by (output started at /data/web/12/61/1f/ in /data/web/12/61/1f/ on line 122

    Warning: Cannot modify header information – headers already sent by (output started at /data/web/12/61/1f/ in /data/web/12/61/1f/ on line 694

    Which I think would indicate that you still have a version mis-match in your files.

    It seems like I can open my browser, go to the link you gave, and get the first link I listed above about 3 times before it reverts to the other link. Since I’m just hitting the back button, I should be getting a copy from cache.

    So I’m not sure what you have here, I am hoping that these observations help

    Hmm, after the site was hacked a while ago (probably because I wasn’t updating wordpress) I couldn’t get my first page to display so I used a plugin which forces another page to be the first page.

    I have updated all the plugins so I don’t think it is a plugin problem but I’m really not up on this kind of stuff.

    It also happens when I’m in the admin panel, it will be working for a while then suddenly that dodgy page comes up.

    Still, I’d be interested in seeing what happens if you dis-able that plugin

    Might be a conflict with WP – now a days you can set what page shows as the “first page” in the options, er, settings part of the admin.

    Maybe the plugin and the core are butting heads?

    Well I made copies of the wp-content/plugins and wp-content/themes folders and deleted them both then copied over the folders from the worpress 2.5.1 tarball.

    So I have no manually installed plugins or themes, just the wordpress default stuff and the problem is still there.

    For reference, this is what comes up on the page when it fails: [code] ://[^/]+|i’, ”, get_option(‘siteurl’) . ‘/’ ) ); /** * It is possible to define this in wp-config.php * @since 2.0.0 */ if ( !defined(‘COOKIE_DOMAIN’) ) define(‘COOKIE_DOMAIN’, false); /** * It is possible to define this in wp-config.php * @since 2.5.0 */ if ( !defined( ‘AUTOSAVE_INTERVAL’ ) ) define( ‘AUTOSAVE_INTERVAL’, 60 ); require (ABSPATH . WPINC . ‘/vars.php’); // Check for hacks file if the option is enabled if (get_option(‘hack_file’)) { if (file_exists(ABSPATH . ‘my-hacks.php’)) require(ABSPATH . ‘my-hacks.php’); } if ( get_option(‘active_plugins’) ) { $current_plugins = get_option(‘active_plugins’); if ( is_array($current_plugins) ) { foreach ($current_plugins as $plugin) { if (” != $plugin && file_exists(ABSPATH . PLUGINDIR . ‘/’ . $plugin)) include_once(ABSPATH . PLUGINDIR . ‘/’ . $plugin); } } } require (ABSPATH . WPINC . ‘/pluggable.php’); /* * In most cases the default internal encoding is latin1, which is of no use, * since we want to use the mb_ functions for utf-8 strings */ if (function_exists(‘mb_internal_encoding’)) { if (!@mb_internal_encoding(get_option(‘blog_charset’))) mb_internal_encoding(‘UTF-8’); } if ( defined(‘WP_CACHE’) && function_exists(‘wp_cache_postload’) ) wp_cache_postload(); do_action(‘plugins_loaded’); // If already slashed, strip. if ( get_magic_quotes_gpc() ) { $_GET = stripslashes_deep($_GET ); $_POST = stripslashes_deep($_POST ); $_COOKIE = stripslashes_deep($_COOKIE); } // Escape with wpdb. $_GET = add_magic_quotes($_GET ); $_POST = add_magic_quotes($_POST ); $_COOKIE = add_magic_quotes($_COOKIE); $_SERVER = add_magic_quotes($_SERVER); do_action(‘sanitize_comment_cookies’); /** * WordPress Query object * @global object $wp_the_query * @since 2.0.0 */ $wp_the_query =& new WP_Query(); /** * Holds the reference to @see $wp_the_query * Use this global for WordPress queries * @global object $wp_query * @since 1.5.0 */ $wp_query =& $wp_the_query; /** * Holds the WordPress Rewrite object for creating pretty URLs * @global object $wp_rewrite * @since 1.5.0 */ $wp_rewrite =& new WP_Rewrite(); /** * WordPress Object * @global object $wp * @since 2.0.0 */ $wp =& new WP(); /** * Web Path to the current active template directory * @since 1.5 */ define(‘TEMPLATEPATH’, get_template_directory()); /** * Web Path to the current active template stylesheet directory * @since 2.1 */ define(‘STYLESHEETPATH’, get_stylesheet_directory()); // Load the default text localization domain. load_default_textdomain(); /** * The locale of the blog * @since 1.5.0 */ $locale = get_locale(); $locale_file = ABSPATH . LANGDIR . “/$locale.php”; if ( is_readable($locale_file) ) require_once($locale_file); // Pull in locale data after loading text domain. require_once(ABSPATH . WPINC . ‘/locale.php’); /** * WordPress Locale object for loading locale domain date and various strings. * @global object $wp_locale * @since 2.1.0 */ $wp_locale =& new WP_Locale(); // Load functions for active theme. if ( TEMPLATEPATH !== STYLESHEETPATH && file_exists(STYLESHEETPATH . ‘/functions.php’) ) include(STYLESHEETPATH . ‘/functions.php’); if ( file_exists(TEMPLATEPATH . ‘/functions.php’) ) include(TEMPLATEPATH . ‘/functions.php’); /** * shutdown_action_hook() – Runs just before PHP shuts down execution. * * @access private * @since 1.2 */ function shutdown_action_hook() { do_action(‘shutdown’); wp_cache_close(); } register_shutdown_function(‘shutdown_action_hook’); $wp->init(); // Sets up current user. // Everything is loaded and initialized. do_action(‘init’); ?>
    Warning: Cannot modify header information – headers already sent by (output started at /data/web/12/61/1f/ in /data/web/12/61/1f/ on line 694 [/code]

    I’ve no idea what to do at this point except start my site up from scratch.

    Well I can tell you it’s falling apart on line 327 of “wp-settings.php” which is:

    00327: define('SITECOOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('siteurl') . '/' ) );

    right after the ? in https? is where raw text starts spewing out. I’d try reuploading wp-settings.php

    Then I’d try commenting out line 326 and 327 and see if it will load.

    There’s a line right before it that uses almost the same syntax so I wonder if “get_option(‘siteurl’)” is failing… ???

    EDIT: I see the site seems to be working now. Now I wonder if it was a matter of not being able to access the database to “get_option” as it were. If so, there really ought to be some sort of trapping to prevent this sort of ugly failure mode.

    The site is working now because I downgraded wordpress to the previous version and everything was working again.

    I then tried the upgrade again and the problem returned so I’ve downgraded once again and it’s working again.

    So it’s certainly the upgrade causing the problems.

    I’ll do the upgrade again when I have a little time and try what you suggested with wp-settings.php to see if that helps.

    Well I found time to do the upgrade again, ready to try editing the file, only to find that the site seems to be working normally now.

    The only thing I did differently was re-download wordpress.

    Maybe the previous download was corrupt or something?

    Possibly – I don’t remember the thread, but I do recall someone else saying that they had the same thing. First download, install, trouble. Second download, install, A-OK.


Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Site dead after WP upgrade’ is closed to new replies.