Script to update an OpenShift repository with changes made on server

If you haven’t tried OpenShift yet, you should!

Anyway I have a WordPress installation there. When upgrading WordPress to a new version, files are changed on the server but they would be overwritten if I push the repository. So I created a script to download a snapshot of the OpenShift app, extract the changes in the php directory where WordPress resides, and add them to repository.

It is fully automated except for the crucial git push.

The script is called and is meant to be commited to the root of each repository.

PHP Allowed memory size of 134217728 bytes exhausted (tried to allocate 71 bytes)

I’m a very happy user of New Relic for my websites, even if I’m only leeching on the free tier.

One of my WordPress sites, has been suffering from this out-of-memory error for quite some time now and I finally tracked it down. New Relic shows the stack trace, with the failing line on top:

in wpdb::get_results called at /usr/share/wordpress/wp-includes/wp-db.php (1413)
in wpdb::get_results called at /usr/share/wordpress/wp-includes/meta.php (295)
in update_meta_cache called at /usr/share/wordpress/wp-includes/post.php (4133)
in update_postmeta_cache called at /usr/share/wordpress/wp-includes/post.php (4113)
in update_post_caches called at /usr/share/wordpress/wp-includes/query.php (2534)
in WP_Query::get_posts called at /usr/share/wordpress/wp-includes/query.php (2695)
in WP_Query::query called at /usr/share/wordpress/wp-includes/query.php (2791)

So, it fails when updating the postmeta cache. What’s that? Well, had a look in the database.

In the database I found the wp_postmeta table. A quick check revealed that it contained thousands of syndication_item_hash entries. These are added by the FeedWordPress plugin.

Unfortunately is quite low priority for me, and the blogs I have been syndicating seem quite dead. But the upside is that I could just disable FeedWordPress and delete all syndication_item_hash entries from the wp_postmeta table.

Now my web server should work much better!

Incorrect result from WordPress plugin_dir_url

Consider this code in akismet.php from the ubiquitous Akismet plugin for WordPress:

define('AKISMET_PLUGIN_URL', plugin_dir_url( __FILE__ ));

My WordPress installation is at /usr/share/wordpress, but the Akismet plugin is installed to /var/lib/wordpress/plugins/akismet/ and there is a symlink (symbolic link) inbetween. This means that __FILE__ is /var/lib/wordpress/plugins/akismet/akismet.php but plugin_dir_url does not understand this, and will incorrectly return:


This is not a proper URL for my WordPress installation!

I’m still on WordPress 3.0.something, but it seems like this issue is still a problem in newer versions. There are a number of bug reports for this and similar issues:

I used the WP_fix_for_plugin_basename_to_allow_symlinks_2011-07-28* pair of patches attached to bug report 16953 to solve the issue on my server. It will patch the plugin_basename implementation, which seems to contain the root cause of this issue.

The WordPress Pharmacy Hack

A number of WordPress blogs around the world have been hacked (or cracked, whichever word you prefer) and a "pharmacy" subdirectory have been injected below the WordPress root. I know of these victims at the moment:

The injected web pages are advertised by fooling Yahoo! search to make a weird GET request to a totally different web site, resulting in log lines like this: – – [29/Aug/2008:04:03:50 +0200] "GET /\"\" HTTP/1.0" 404 15145 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp;"

I really recommend every WordPress user to add at least one extra level of protection to their wp-admin subdirectory. It’s not safe.