With the last Ubuntu releases, the included Apache and WordPress upgrades caused me to do more and more workarounds to get everything up working after doing the upgrade.
Initially starting a few years ago with Ubuntu 11.x, I installed Apache, PHP, MySQL, phpMyAdmin and WordPress via apt-get, according to the official Ubuntu WordPress documentation. I wanted some blog sites to run on a virtual Ubuntu server and it basically worked without problems.
With the next Ubuntu distro upgrades, I always had to look for workarounds. The WP plugins, themes and uploads directories suddenly moved and instead symbolic links were created. This caused the WP Admin GUI to show permission errors and other problems when updating plugins or installing new themes.
In the meantime, my blogs have grown quite large and a start from the beginning with exporting/importing and maybe even losing parts of settings or media was not an option.
To be safe, make a snapshot of your virtual machine. Also copy the the current wp-config.php to another location, e.g. your home directory.
If you are using themes like “twentyeleven”, also copy it. During the upgrade the theme folder could be deleted, if it still resides under /usr/share/wordpress!
Hints after upgrading to 13.10
Problems after upgrades between 11.x and 12.x to 13.04 could nearly all be solved if you changed wp-config.php after the upgrade back to the original content path (/usr/share/wordpress/…) and manually correcting the permissions via “chmod -R www-data /usr/share/wordpress”.
With the 13.10 upgrade, where also Apache is upgraded to 2.4, I decided to correct to correct all these problems.
First do the upgrade with “do-release-upgrade” to 13.10.
The most important thing in newer Ubuntu WordPress (apt-get) releases: Do not change anything under /usr/share/wordpress, not even wp-config.php. You should only modify data under /var/lib/wordpress, and this is where themes, plugins and uploads should reside.
You can copy/move these (but only these!) directories from /usr/share/wordpress/themes etc., delete the symbolic links under the var/lib-wordpress directories first. Don’t forget to chown the whole /var/lib/wordpress directory again. The manual under /usr/share/doc/wordpress/README.Debian gives you more details about this.
To make Apache be able to accept the /var/lib directory before accessing the /usr/share content, add the following line to your Apache VirtualHost config file:
Alias /wp-content /var/lib/wordpress/wp-content
Then restart Apache.
Configuration for all the WordPress sites have moved to /etc/wordpress. Here you can insert all modifications you might wanted to do in wp-config.php earlier.
With the Apache 2.4 upgrade, in /etc/apache2/sites-enabled / available directories only config files are accepted if they end with “.conf”. Make sure they have the right ending and the symbolic link in sites-enabled is still OK.
The Apache upgrade could also have modified restrictions to .htaccess files. In /etc/apache2/apache2.conf, make sure the directories /usr/share (usr/share/wordpress), /var/www and /var/lib (/var/lib/wordpress) have the AllowOverride parameter set to All. Otherwise the WordPress .htaccess are not accepted any more and an empty web page could be displayed, or the permalinks might not work. Also note the “order deny, allow, …” syntax has changed in Apache 2.4, in case you need this option.
Try a “service apache2 restart” and note errors. It could display warnings regarding “NameVirtualHost” variables, e.g. in ports.conf, and usually you can simple remove these lines in the config files.
WP Plugin install and updates
When installing or updating plugins, WP could ask for SSH access or other user data. Usually, this dialog is displayed if there is a permission problem.
It seems like WP is looking here if both the /usr/share/wordpress and /var/lib/wordpress folder is owned by www-data. But only /var/lib/wordpress is necessary.
So if you don’t always want to refresh permissions after every upgrade or enter your user credentials for plugin updates, you can add this line to your /etc/wordpress config file:
define( ‘FS_METHOD’, ‘direct’ );
Now everything should be running.
Many websites suggest to convert multiple WP installations, like they are explained in the Ubuntu tutorial, to the WP MultiSite feature. IMHO it is a matter of taste, but basically it should be no problem any more after doing all the steps above. But converting could be a problem if you use multiple top-level domains. Anyway, the “old” method with multiple config files should also be working for the next few years.