Debugging a broken WordPress install where the file name and path causing the error doesn’t seem to even exist

I’ve been tasked to complete what appears to be a migration of a WordPress site from a development URL (/newblog) to a production URL (root) that seemed to have already been attempted by somebody else and got messy somewhere along the way and am seeing errors I have never seen before.

After seeing some really strange things (I tracked down an error earlier that involved me simply resaving a file with the same contents – it was as if some kind of cache was in operation), I got an error like what I pasted below (obviously examplesite.com is a made up domain).

Read More

What I don’t understand is that there is no such directory called /newblog anymore, so how can it be saying the error is found in /var/www/examplesite.com/newblog/wp-content/plugins/akismet/widget.php ?

I’ve checked the database and there is no reference to any path with /newblog in it.

Warning:
include_once(/var/www/examplesite.com/newblog/wp-content/plugins/akismet/widget.php):
failed to open stream: No such file or directory in
/var/www/examplesite.com/newblog/wp-content/plugins/akismet/akismet.php
on line 49

Warning: include_once(): Failed opening
‘/var/www/examplesite.com/newblog/wp-content/plugins/akismet/widget.php’
for inclusion (include_path=’.:/usr/share/php:/usr/share/pear’) in
/var/www/examplesite.com/newblog/wp-content/plugins/akismet/akismet.php
on line 49

Warning:
require_once(/var/www/examplesite.com/newblog/wp-content/plugins/jetpack/class.jetpack-user-agent.php):
failed to open stream: No such file or directory in
/var/www/examplesite.com/newblog/wp-content/plugins/jetpack/jetpack.php
on line 4467

Fatal error: require_once(): Failed opening required
‘/var/www/examplesite.com/newblog/wp-content/plugins/jetpack/class.jetpack-user-agent.php’
(include_path=’.:/usr/share/php:/usr/share/pear’) in
/var/www/examplesite.com/newblog/wp-content/plugins/jetpack/jetpack.php
on line 4467

Related posts

Leave a Reply

1 comment

  1. Using your example path:

    /var/www/examplesite.com/newblog/wp-content/plugins/akismet/widget.php
    

    This fragment of that path:

    /var/www/examplesite.com/newblog/
    

    Is basically the base install path that is usually stored in wp_options in siteurl, home, dashboard_widget_options and even others. But when it comes to migrating an install—like what you are attempting to do—it can really get in the way.

    The issue is that WordPress attempts to make initial installs so simple, they make them hard to migrate. The best solution that I use on a regular basis is to hard-code the install paths within the wp-config.php file like this:

    define('WP_SITEURL', 'http://www.examplesite.com');
    define('WP_HOME', 'http://www.examplesite.com');
    define('WP_CONTENT_DIR', '/var/www/www.examplesite.com/wp-content');
    define('WP_CONTENT_URL', 'http://www.examplesite.com/wp-content');
    

    Of course, the settings I have set above are based on my best guess of your setup. Assuming a standard Unix /var/www/ install path and your site URL. But in general—and in my experience—simply setting these paths explicitly in your wp-config.php is the best way to go to migrate a site & even make it more portable.

    Also, check the .haccess file. It should basically be:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress
    

    But if someone placed the site in a directory on the server that is not the root—like newblog—it could be something like this:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /newblog/
    RewriteRule ^index.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /newblog/index.php [L]
    </IfModule>
    # END WordPress
    

    Note the two places where newblog are in that example above. But from what you describe it all sounds like a config issue.

    And if worse comes to worse, I recommend you figure out what version of WordPress the site is using—look in the file /wordpress/wp-includes/version.php—and then download a clean install of WordPress, set the config to load the old/damaged site’s database & such & then copy the wp-content folder from the old install into the new install. Hopefully the previous developer did not muck with the WordPress core files, so just copying the wp-content & using the old directory should help you out.