Upgrading WordPress 3.2.1

So this is the journey to update WordPress 3.2.1 to 5.3

I’ve taken a copy of the site and set it up on a temporary URL and set the following within wp-config.php

define('WP_HOME','http://test.site.com');
define('WP_SITEURL','http://test.site.com');

I’ve also had to drop the PHP version to 5.6 to be able to run the site.

Step 1 – Getting to a wp-cli capable version 3.2.1 to 3.7

So I’d like to use wp-cli, and increment the installation a bit in the 3.x branch just to see how well it goes.

Grab wp-cli version 1.3.0 at https://github.com/wp-cli/wp-cli/releases/download/v1.3.0/wp-cli-1.3.0.phar

There is no available download on wordpress.org for 3.7, at least one that isn’t listed. So if you simply grab a download link for any older version from their release page you can change the version number in the file name.

Here’s WordPress 3.7 zip installer https://wordpress.org/wordpress-3.7.zip

Upgrade WordPress Manually using these instructions https://wordpress.org/support/article/updating-wordpress/#manual-update

Since I have SSH access I’m going to do it the following way. The below commands assume public_html is your directory root where your WordPress installation sits.

wget https://wordpress.org/wordpress-3.7.zip
mv public_html to public_html.old
unzip wordress-3.7.zip -d public_html
rm -rf public_html/wp-content
cp public_html.old/wp-config.php public_html
cp public_html.old/wp-content public_html

Go to your sites /wp-admin page and update the database.

Step 2 – Upgrade 3.7 to 4.0 because why not?

So I just choose 4.0 because it seems far enough ahead but not too far.

I’m going to first test my custom wp-cli and see if I can upgrade to 3.7.31

php5.6 /usr/local/bin/wp-cli-1.3.0.phar --allow-root core update --version=3.7.31
Updating to version 3.7.31 (en_US)...
Downloading update from https://wordpress.org/wordpress-3.7.31.zip...
Unpacking the update...
Cleaning up files...
No files found that need cleaned up.
Success: WordPress updated successfully.

Success, so now let’s bump the version up to 4.0

php5.6 /usr/local/bin/wp-cli-1.3.0.phar --allow-root core update --version=4.0
Updating to version 4.0 (en_US)…
Downloading update from https://wordpress.org/wordpress-4.0.zip…
Unpacking the update…
Cleaning up files…
No files found that need cleaned up.
Success: WordPress updated successfully.

You’ll need to login to your sites /wp-admin and run the database updates if there are any.

You’ll also want to confirm that your site is still displaying properly. You might find that your theme isn’t supported by WordPress 4.0

You might also need to upgrade PHP at some point, however WordPress supports 5.6 all the way up to WordPress 5.3

Step 3 – Upgrade to 5.3! Let’s do it!

So I don’t really need to use the old wp-cli v1.3.0 and can use the latest version since we got up to WordPress 4.0

wp --allow-root core update
Updating to version 5.3 (en_US)...
Downloading update from https://downloads.wordpress.org/release/wordpress-5.3-new-bundled.zip...
Unpacking the update...
Cleaning up files...
No files found that need cleaning up.
Success: WordPress updated successfully.

Luckily for me, there were no issues!

Deploying Ubuntu 18 Guest on Ubuntu 18 Host DomU

TLDR; Head to the bottom and you can update the shipped version of xen-tools 4.7 to 4.8 via the xen-tools GitHub repo. There’s a dpkg available under the releases tab.

Currently, the only available version of Ubuntu available to deploy using xen-create-image (xen-tools 4.7-1) on Ubuntu 18 is Ubuntu 16.04 (Zenial)

If you want to deploy Ubuntu 18.04 (Bionic) an error will occur using the following command

xen-create-image --hostname=server1 --vcpus=2 --size=150Gb --swap=2Gb --memory=8GB --arch=amd64 --ip=192.168.1.2 --pygrub --dist=bionic --gateway=192.168.1.1 --netmask=255.255.255.0 --lvm=vg0

You will get the following error

ERROR: 'bionic' argument takes a distribution name (see /usr/share/xen-tools for valid values).

You’ll need to edit /etc/xen-tools/distributions.conf and add in the following line under zesty

bionic        = ubuntu     pygrub

You will then also need to run the following to link the xen-tools hook directory for karmic to bionic. Reality ist hat karmic.d has nothing for the hooks, and we should really be creating the appropriate hooks to enable networking and etc. Here’s the xen FAQ that has more details http://xen-tools.org/software/xen-tools/faq.html

cd /usr/share/xen-tools
ln -vis karmic.d bionic.d

You should then be able to run your xen-create-image without issues. However, you’ll run into a new problem…networking.

So Ubuntu 18 shipped with xen-tools that didn’t have support for Ubuntu 18, and so there are no hooks for setting up networking. However, there is a thread on how to do all of this.

https://github.com/xen-tools/xen-tools/issues/51

It details the method above and has some of the hooks required.

You can also simply just install xen-tools 4.8 release from the xen-tools GitHub repo at https://github.com/xen-tools/xen-tools/releases/tag/release-4.8

wget https://github.com/xen-tools/xen-tools/releases/download/release-4.8/xen-tools_4.8-1_all.deb
dpkg -i xen-tools_4.8-1_all.deb

You should then be able to deploy Ubuntu 18.04 on Ubuntu 18.04 DomU

Windows 10, ZSH, Putty, Powerline Fonts and Screen

I recently was setting up my Windows 10 desktop machine with Putty so I could access some servers. I use the ZSH shell with OMZ and the Powerline9k theme. I use the following article to set up Putty and grab the appropriate fonts for Windows 10 that were patched.

http://mschulte.nl/posts/using-powerline-in-PuTTY.html

There were some additional options on the following blog article that were required.

Oh My ZSH! with PuTTY

Everything was working great until I was having issues with powerline font’s not showing correctly when using screen.

Running the powerline echo test below resulted in hashed blocks.

echo “\ue0b0 \u00b1 \ue0a0 \u27a6 \u2718 \u26a1 \u2699”

echo "\ue0b0 \u00b1 \ue0a0 \u27a6 \u2718 \u26a1 \u2699"

Turns out I didn’t have my locale set in my shell environment.

export LANG=”C.UTF-8″

export LANG="C.UTF-8"

Once I had the appropriate locale set, everything worked fine.

WP-CLI Cheat Sheet

WooCommerce

wp wc update – Updated WooCommerce database from command line.

LiteSpeed

wp lscache-purge all – Purge all cache.

Improve WordPress Comments Load time when using Akismet: Adding an index to wp_comments

A customer of mine was seeing a 15 second load time on their WordPress site when clicking on “Comments”.

I installed Query Monitor and saw that the Akismet plugin was running the following SQL command on each comment.

SELECT COUNT(*) FROM wp_comments WHERE user_id = 1820 AND comment_approved = 1;

This query was to show how many comments the user had previously had approved. The query was taking 0.5 seconds per comment listed when you visit the “Comments” page. The page was taking around 15 seconds to load at times. Now if you had this page set to load 100 comments per page, then you’re looking at 60 seconds.

I decided to run an explain on the query to figure out what was going on.

explain SELECT COUNT(*) FROM wp_comments WHERE user_id = 778 AND comment_approved = 1;

Which resulted in the following. (Sorry for the screenshot, copy/pasting and reformatting was not something I wanted to do. Also this references the wp_bspr_comments. This is due to the database having a wp_bspr for it’s table prefix.

MySQL Explain on wp_comments query not indexed

As you can see, the query is having to go through 19866 rows within the wp_comments table which is the total amount in the table. Since they’re using count(*) all rows are scanned.

So I decided to add an index for the user_id and comment_approved columns.

create index wp_comments_askismet ON wp_comments (user_id,comment_approved);

No when running an explain, there are only 9 rows scanned.

MySQL Explain on wp_comments with Aksimet after index

Load times were reduced dramatically. However, this can all be mitigated if you simply turn of the Akismet feature.

Akismet option to show number of approved comments beside each comment author.