I thought I would document this experience I had when upgrading some sites to WordPress 3.0.

After WordPress 3.0 came out I took some time to upgrade blogs I manage and was impressed how well the upgrades fared. No issues, fair warnings and ultimately upgraded sites. However, on one of my development sites, after the upgrade, I noted an error about “error re-declaring the function flush_rewrite_rules()”. I knew, for this site in particular, that I had written some custom code to rewrite the urls and in this case I had innocently included a function called “flush_rewrite_rules()”. Coincidentally, in WordPress 3.0 a new core function has been created called “flush_rewrite_rules()” and because that now exists my function is interfering with this and required fixing. The fix, in this case was to rename my custom function and test and I thought nothing more of it. (I know – I should have participated in the beta test).

I didn’t think anything of it after that until I was asked to assist with another clients site. This time the client had innocently upgraded their site to WordPress 3.0 and encountered a white screen with the long PHP error referencing “error re-declaring the function  flush_rewrite_rules()”. The difference this time was that it was in a plugin causing the issue and as such the site was rendered inaccessible.

For this client I connected via FTP and downloaded the plugin code, searched for the function named  ”flush_rewrite_rules()” (along with any references to it) and renamed it through the code. After uploading the change the site was restored back to normal.

A simple fix for this site but also a simple lesson in heeding the warnings / suggestions given by the WordPress upgrade tool when upgrading to WordPress 3.0

I came across weird behaviour recently relating to breadcrumbs. In a site I was working on the breadcrumb functionality (provided by a plugin) was not consistent – it was incorrect on single post pages but correct on category pages. It didn’t make sense. There are not many options for the breadcrumb plugin so it was difficult to see the fault lying there. I did notice that the site used a custom menu and that code was used on all pages. So, my troubleshooting took to dissecting the header and then menu code.

In the header was a call to the custom menu and in that file each menu element was created with a new WP_Query to get a subset of links / pages. I saw that the syntax to fire off each query was as I would expect  but I did notice that the $wp_query object wasn’t saved before these additional queries and subsequently restored afterwards. So, I figured that was messing things up and added that code in. No change. Now, I went a little deeper and added code in the menu to display the current categories after each menu (the categories are used in the breadcrumbs). Now, it was making sense. So, the categories were being messed up after each query in the menu code and that affected the single post pages.

The fix was simple and one line of code at the end of the custom menu code before returning to finish the header code:

wp_reset_query();

And, as per the codex for wp_reset_query() it is recommended to be used after a custom query. The breadcrumbs were now working as expected.

I’ve recently worked on a couple of blog sites that had been victim to malicious activity. The evidence was different in both cases and for one consisted of search results that promoted drugs that enhance performance. And we’re not talking about blog performance For both sites there was hidden text and html code in all the posts containing offsite links to seeming random and unrelated websites. The job I had was to remove any sign of malicious code and sanitize the sites. Additionally I was getting browser warnings indicating malware was present on the page I was navigating to. The warnings suggested I don’t continue lest my PC be infected further.

Investigating a hacked WordPress site

With WordPress there are a few good ways to speed up the job of troubleshooting a hacked site and speed may be of essence with something like this. I asked the client when there were first signs of the malicious content or behavior – believe me it’s actually very useful to know the exact date & time you first experience the issue as you’ll see later. So, if that time information is not available or cannot be remembered viewing the server error logs promptly could give you some more information. Armed with that information and presuming you can get into the site’s admin dashboard you try the following fairly standard actions to help uncover the culprit and mitigate further issues:

• Disable all plugins
• Switch to default theme
• Use Theme Authenticity Checker

The Theme Authenticity Checker plugin does a quick scan of all installed themes for unnecessary code – typically this code consists of statements or functions like “eval( blah blah);” code injected somewhere in any of a themes files. Pay attention to anything TAC highlights – perhaps removing un-needed themes. For any theme that is highlighted as containing potentially malicious code you’ll need to edit the affected file or remove and re-install the theme files from the originals. That’s a drag if you’ve made theme modifications but it means you can revert to being back online. In one of the cases here I was re-enabling the plugins one at a time and I found that a plugin was causing one issue (preventing the blog from displaying) and by removing it from the plugins folder I could continue.

However, perhaps your blog site is non-functioning and you can’t get into your site’s admin dashboard? Well, now’s the time you use FTP or SSH connect to the server hosting the website. Remember I said how useful it is to remember the date & time you first noticed the hacking / issue? Well, here’s where you can navigate to the following folders and look for files that have been changed around the same date/time:

• wp-content
• wp-admin
• wp-includes
• wp-content/themes/*
• wp-content/plugins/*
• the folder above wp-content – sometimes public_html or public

* The above folder list is not exhaustive but typically this is where the malicious code is to reside

In each of these folders look for other folders or files that have recently been created. These are sure indications that modifications have been made and you need to target those files or folders.

Fixing a hacked site

After searching in the above folders on the clients sites here’s what I found:

• A folder called “backup” and in there was malicious file  ”backup-loader” that had code to display an authentic looking message on the WordPress dashboard.
• An include statement at the top or within the index.php
• A file/folder combination called “__notes/notes” that was included in index.php
• Malicious code in wp-includes/theme.php
• Malicious code in functions.php – an eval statement that referred to a setting in the wp_options database
• Malicious javascript code in the wp_options database

With FTP you can download, use a code editor, and then upload fixed files. With SSH using a code editor directly to removing the malicious code in the php files. Identifying the code to remove was pretty easy as often the code segments looked out of place and therefore easy to remove and test. The wp_options code required the use of a MySQL database client like PHPMyAdmin to manually edit the table and remove the code and the related entry / record to prevent re-infection.

Cleanse and Sanitize

I said before that one of the effects of this hacking was that all the posts and pages had been injected with additional HTML code. Again with a MySQL client I looked through the blog database tables and found that also infected were the “revision” records for each affected post or page. Each malicious link was hidden from view with a CSS “style display:none” command and each link was injected in random locations within the post content. This made cleansing a labor intensive job (I could have possibly written some code to scan and remove but time didn’t permit) as I had to manually edit each post in the database – copying and pasting to a code editor and then pasting it back into the database, view the page or post, view the source to ensure the malicious code was gone.

Check in with Google Webmaster Tools as well to see if Google has identified malware on your site. If it has then follow it’s suggestions as to how to get the information Google stores about the site updated to reflect the current, non-malware, site.

WordPress Security Review

Once your site is cleansed and working you might take a look at further locking down access to reduce the chances of this happening again. Changing your admin and FTP passwords regularly is always good practice but there are more hints and tips in my WordPress Security post.

I successfully managed to fix these sites using the techniques described above – if you ever experience similar incidents then this short guide will help you. I do recommend now after all of this, taking a database backup and upgrading to the latest version of plugins and WordPress as soon as possible.

Thoughts, ideas always welcome in the comments.

*Update* After I completed this project I came across an updated version of Exploit Scanner – more information here. A useful tool to assist in fixing a compromised WordPress installation.

There are times when you see your blog fly and other times it seems like it’s taking to an age to load. In your email you’ve got mail from users saying that the blog performance is degrading and not as good as it used to be. You keep checking that your blog cache program is enabled and wonder what else you can do. Well, you can wonder no more as I’ve collected the best tips on how to review your site configuration and restore the performance you and your users are used to.

Let’s take a look at the options you can explore to better improve the performance of your blog.

Blog performance break the speed limit

Blog Theme

Review your theme options, widgets and settings. Use firebug to see if all your theme images are loading correctly especially if you’ve experienced issues during a theme upgrade. Review your themes CSS files to see if there are references to images or other files that are no longer required or perhaps are missing. Disable any unnecessary widgets in your blogs dashboard. You may also check out your theme is generating valid code using the W3C Markup Validation Service or check with your theme developer or the support forum for your theme.

Blog Plugins

Simply put – do you need all the plugins activated on your site? Perform a quick plugin audit, comparing what you see on your home page and blog pages with your active plugins. If there are plugins that are active but not used then deactivate them one by one and refresh your blog page to see that it’s still all working. Sometimes going back to basics and deactivating all plugins is the only way to go. Also make sure you have the latest versions of the plugins you decide on keeping.

Blog Hosting

This can play a big part in the performance of your blog. With the big shift from shared (cheap) hosting to still cost effective and high performance VPS offerings like Slicehost (the host I use) and many others, there are more opportunities to gain improved performance by picking the right host. Look at your hosting package and compare the next one up with your existing host.

Blog Optimization

This can offer up some simple and not so simple tips to help you speed up the responsiveness of your blog. There are many tools you can use – Firebug add on in Firefox, Pingdom, YSlow another addon for Firefox and even Google has a performance tool for Firefox. You can even try Is My Blog Working which, along with Pingdom can give you an idea of the time it takes to load your site. You can compare the load time before and after any of the changes you make.

View the server log

This is probably the most technical tip in this post and varies wildly from host to host. I have found that sometimes it can lead you straight to a bottleneck because you see lots of errors being reported and at other times you are swimming through the log struggling to find what’s occurring. Perhaps with this one work with your hosting tech support or a WordPress consultant if you feel you are still struggling with blog speed.

Blog Caching

This is typically performed by a plugin but there are lower level server options available if you’re running on a VPS or non-shared server. Such options include APC – Alternative PHP Cache – and these can improve the server performance and that blends through to your WordPress performance.

Within WordPress there are a number of caching plugins that you can choose to use – WP-Super-Cache and W3-Total Cache. I’ve used both and both can benefit from tuning of their options so be sure to review the options carefully. The basis of these WordPress caching tools is that they generate a single html page of your posts / home page that the web server can deliver to a browser much more efficiently than processing the page on each request. Most of the caching plugins have multiple options for tuning how it should work on your blog – try changing the available options to see if the performance improves.

Blog Security

Blog Security

Securing your blog is important and there are many options that will help you. Now, there’s no substitute for good security but you might not want to put too many locks on the blog such that it takes too much time to do something simple. And each security layer can add a level of performance sapping complexity. Review your blogs security options and pare them down to the minimum necessary or within your security comfort level.

Blog Advertising

Advertising makes the blog world go around (along with B2B opportunities of course) and I’ve worked on one or two sites that have multiple advertising sections and there have been times where the site won’t completely load because it’s waiting for a piece of advertising to load. Review with your advertising contacts/services to see that you have the most optimal code for your advertising sections on your blog.

So, you can see there are many ways you can speed up your blog or at least tweak it for performance in some areas. If there’s a tip I’ve missed but you’ve used and benefited from then please leave a comment!

WordPress & jQuery

The release of jQuery 1.4 brings many javascript improvements in performance, better handling of attributes, manipulation of DOM events and many more. Head over to the jQuery site for more details and a breakdown of the new features and improvements.

That’s great and we all like speed and flexibility improvements. Now, how would you like these in your blog from today? Well a very quick and easy modification to your theme can have you utilizing the latest version of jQuery from Google’s CDN servers. I took the code block from the source site below, inserted it in my functions.php but replaced the jQuery version number. Check out the adjusted code block below:

if( !is_admin()){
   wp_deregister_script('jquery');
   wp_register_script('jquery', ("http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"), false, '');
   wp_enqueue_script('jquery');
}

See where I just put “..jquery/1/jquery…” – by referencing the “1″ instead of “1.3.2″ we will get the latest version of jQuery loaded on the site. A quick look at the source code and we can see that the inserted javascript source is indeed via Google’s CDN and by clicking on the source code we see it’s version 1.4. To use simple terms in this code we are telling WordPress to “forget” it’s usual jQuery source / script setting, then preparing WordPress for the new settings (please load jQuery from Google’s CDN) and then serving up the new information for WordPress to use.

A quick and easy way to give your blog / site the benefits of the recent jQuery updates and improvements. If you encounter an issue with your site or  jQuery after this change you can easily revert to the previous version (1.3.2) by either removing the code block you added or, to keep jQuery hosted by Google’s CDN, adjusting the version number from “1″ to “1.3.2″. For those more familiar with jQuery coding there’s a list of “backwards incompatible” changes settings on the jQuery site.

If you’ve changed your site over to jQuery 1.4 how did it work out? As smoothly as mine did? Leave me a comment.

Source: http://digwp.com/2009/06/use-google-hosted-javascript-libraries-still-the-right-way/