Tag Archives: wordpress

Fail, Programming, Rants, WordPress

WordPress options in Standalone vs Multisite ( aka update_option vs update_site_option )

2 Comments

While researching how data needed to be migrated for Multisite functionality in BackupBuddy I’ve had to do a lot of digging into the differences between how options (and other) data is stored and retrieved in Standalone versus Multisite WordPress setups. This was an extremely confusing venture and not intuitive at all. I’ll start with a table of my resulting findings and explain from there. In this example I’m using update_option() and update_site_option(). The same structure is followed for transients and other data as well so this basis should work for you. It is important to note that when in a Multisite environment the terms site and blog are used interchangeably by WordPress core in code and mean the same or entirely different things depending on context. This is an unfortunate failure of WordPress and adds to the confusion.

  update_option update_site_option [global]
Standalone Site wp_options [local (effectively global)] wp_options [global]
Multisite Main Site or Network Admin wp_options [local] wp_sitemeta, site_id (aka network id) set [global]
Multisite Site (non-main site) wp_##_options [local] wp_sitemeta, site_id (aka network id) set [global]

In a Standalone WordPress installation update_option() stores data in the wp_options database table. The update_site_option() function falls back to update_option() when in standalone mode so there is really not much of a functional difference here. This data can be updated / retrieved anywhere in the WordPress installation so it’s effectively global. It’s best to use the proper one though in case the site is ever migrated into a network with BackupBuddy.

In a Multisite WordPress installation things get … weird and non-intuitive. The verbage used by WordPress is very confusing unfortunately. (Individual sites in a Network installation are called Sites — but in code they are often called blogs and you can have multiple blogs within a site (you can technically have multiple blogs within multiple sites within one Network but that’s another story…). Things vary depending on where you are so keep your eye out for this. If you are in the main site dashboard, main site front-end, or Network admin, update_option() will place data in wp_options. Data manipulated while in the Network Admin behaves as if it was manipulated within the Main Site (!). If you are in another of the Network’s site admin/dashboard that is not the main site and not the Network Admin then update_option() stores data in wp_##_options where ## is the ID number of the blog. These options are only available within the respective area. These are `local options`. If at any time you want to set an option that is globally accessible by its name anywhere in the entire network use update_site_option().

Uncategorized

Disable post revisions in WordPress 3.0

1 Comment

I recently had a customer that had ~70,000 revisions on posts on his WordPress site. This caused his database to skyrocket to 400mb+. I discovered the cause of these revisions to be the plugin FeedWordpress. FeedWordPress was triggering WordPress to create massive amounts of revisions. Because of this the plugin I wrote, BackupBuddy, could not back up his site without running into PHP timeout issues. In this post is the solution I used to resolve this problem.

In the root directory of your WordPress installation, open wp-config.php in a text editor and insert the following line on a new line somewhere between the top ( looks like ) lines of the file:

define('WP_POST_REVISIONS', false);

Running the following SQL (change wp_ to your prefix) in phpmyadmin will clear out all revisions:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision';

Finally, run the following SQL query to optimize (clean up) your posts table:

OPTIMIZE TABLE wp_posts;