Archive for December 2011

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().

Categories Fail, Programming, Rants, WordPress
Comments (0)

If you are running WordPress on OS X using XAMPP for local development then you likely have tried to upload core or a plugin and encountered the following error while prompted for FTP Connect Information:

To perform the requested action, WordPress needs to access your web server.

This is because by default XAMPP runs as the user `nobody` on Mac and this causes some permissions issues. Additionally WordPress prior to upgrading writes a file to the system and then checks to see which user wrote the file. If this file does not match the user running PHP it will refuse to upgrade, even if write permissions existed. chmod 777 is not sufficient to get past this; you must have the correct user as well. I don’t know why they did this and if there’s a technical reason for it, but it’s annoying.

The solution: Edit your httpd.conf to run as your username for the user and staff for the group.

Open httpd.conf in TextEdit:

sudo open -e /Applications/XAMPP/xamppfiles/etc/httpd.conf

Change:

User nobody
Group nogroup

To:

User your_mac_username
Group staff

Restart Xampp and this should correct the problem; you can verify it worked by running in a .php file.

If you still encounter issues you can check a couple of other things. First verify ownership (most likely problem):

sudo chown -R your_mac_username:staff /path_to_webroot/www/

Next confirm permissions (you can change 777 if you need higher security):

sudo chmod -R 777 /path_to_webroot/www/

Categories Uncategorized
Comments (0)