WordPress problems
While a reinstallation of the core WordPress files is often a good call to cut malicious code from a site, there are other avenues of detection to pursue first.
Note
Problems with phantom edits
Sometimes folks edit stuff and changes don't show up. Damn, that's frustrating.
Are you working on the right web page? This sounds silly, but it happens all the same, sometimes for instance when a host relocates a server. To be sure, add a comment <!-- hey! --> to a theme template file, clear or disable your browser cache, and refresh the page. On the page, right-click and choose to view the source code to see if the comment is there (<!--comments--> don't show up on a live page). If not, talk to your host to find out where the files really live.
Is a caching plugin hiding new content? Try disabling caching plugins, delete or disable your browser cache, and refresh the page. Worked? Great . Have a play with the caching options. Didn't work? Read on L.
Incompatible plugins
Have you made plugin changes? If so, there's a big red flag. We'll revert them to see if the problem's gone. Also, after WordPress updates, bear in mind, plugins sometimes sulk.
Deactivate all the plugins and see if the problem's plugged. If so, reactivate them a few at a time, re-trying the site. Repeat the process to whittle down to a pained plugin then, being a good netizen, let the developer know and maybe swap it for an alternative.
If you can't get into your Dashboard to deactivate plugins, rename the plugins directory to, say, plugins_BACKUP. That deactivates them and, hopefully, you'll be able to regain access, seeing messages like this on the plugins page:
Now rename the plugins_BACKUP folder to plugins. They remain deactivated and you can try isolating a problem plugin if the site is otherwise working properly.
Injected plugins
There's an outside chance that some witless wonder has added an illegitimate plugin, although by having deactivated yours, that may have been deactivated too. Then again, if the problem reoccurs, or before deactivating plugins, crack open your database and seek out the active_plugins record of the wp_options table.
Most commonly, we use phpMyAdmin, linked for instance from cPanel, to query a database. Having opened the tool, choose your database to open its table structure. Now, click on the SQL tab (found on the top menu) and run this command—substituting the
wp_
prefix for any bespoke prefix you may have—hitting Go:
SELECT * FROM wp_options WHERE option_name = 'active_plugins';
A single row will load. Click on the pencil icon to open the edit screen, then look for a suspect entry like this. Most likely it will be recorded at the end of the list:
Note the path of any bad plugin, which almost certainly points to your uploads folder tree, and delete the offender. Now erase the plugin's active_plugins record, up until it's semi-colon and being careful to leave the previous record's semi-colon. Your other plugins will become deactivated by doing this, so reactivate those in the usual way.
Widgets, third party code and theme problems
If that didn't work, then use similar trial and error on any widgets or third party code.
Pay close attention to your theme. Try another: assuming you aren't using it, try the default WordPress theme, Kubrik or TwentyTen, which shipped with the platform and ought to be uninfected. If you use Dougal Campbell's tip-top Theme Preview plugin, you can evaluate themes without your users seeing any difference to the site, so that's handy:
If the problem disappears, your theme could have been injected with code. Scour theme files for discrepancies such as iframes, unwarranted links, or JavaScripts and scrutinize header.php, index.php, single.php, and footer.php files (though these are merely the most likely candidates to take the hit). The next section will help with this ...
Fun 'n' frolics with files
Scouring core files for injected code can take anything from hours to days to do, with no guarantees and plenty of headaches. Unless you know your way around the WordPress file base blindfold, and even if you do, here are some shortcuts.
Scrutinizing file changes
A dead simple way to check for recently changed files is by sorting them with, say, the SFTP client FileZilla's last modified column (oddly, cPanel isn't this bright). Using this function, for example, you can easily detain suspicious recently altered theme files.
Alternatively, save time and add powerful functionality by using a terminal instead which, as is detailed in Chapter 5, is possible even with most shared hosts.
This find command will search, recursively into the directory tree, for any files modified in the last day, listing those on the terminal screen:
find /path/to/search -type f -mtime -1 –printIf you want to search for the last three days, swap -mtime -1 for -mtime -3.
Remote file comparison
Still terminally tapping, there's also an easy way to compare the differences of suspect files to those of original counterparts:
diff /path/to/file1 /path/to/file2That shows only the differences. This gives the side by side contrast:
diff -by /path/to/file1 /path/to/file2Finally you can compare a directory and its sub-folders with another, again from backup:
>diff -r /path/to/folder1 /path/to/folder2Local file comparison
Rather than using your server's terminal to compare files, let's cut some slack with a GUI. In this case, detain any suspect files locally and, you know what, cross-examine them against their known-good-backup equivalents. Here are the tools for the job:
PSPad (Windows) – http://pspad.com
WinMerge (Windows) – http://winmerge.org
Meld (Linux/Mac) – http://meld.sourceforge.net
Deep file scanning
The powerful Exploit Scanner plugin, from WordPress Don Donncha O Caoimh, checks both the web files and your database, throwing up possible problems for further analysis:
Using this plugin's deep-probing pointers, clean any scurrilous code and re-check the site:
There are some pretty tasty generic scanners out there too. Here are a couple of cuties:
