MySQL 5.7 and Wordpress problem

If you upgrade to MySQL 5.7, you may encounter bugs with legacy software. Wordpress, which I also consider some kind of legacy software, does not handle this very well with its default settings.

You may encounter the "Submit for review" bug where you cannot add new posts. It may be related to permissions, auto_increment and other stuff, but here is another case: bad date formats and invalid data altogether.

In MySQL <= 5.6, by default, invalid values are coalesced into valid ones when needed. For example, attempting to set a field NULL on a non-null string will result in empty string. Starting with MySQL 5.7, this is not permitted.

Hence, if you want to upgrade to 5.7 and use all the goodies, you should consider putting it in a more compatible mode, adding this to your /etc/my.cnf:

[mysqld]
# Default:
# sql_mode = ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION 
sql_mode = ALLOW_INVALID_DATES,NO_ENGINE_SUBSTITUTION

See official documentation for complete information

GlusterFS performance on different frameworks

A couple months ago, I did a comparison of different distributed filesystems. It came out that GlusterFS was the easiest and most feature full, but it was slow. Since I would really like to use it, I decided to give another chance. Instead of doing raw benchmarks using sysbench, I decided to stress test a basic installation of the three PHP frameworks/CMS I use the most using siege.

My test environment:

• MacBook Pro (Late 2003, Retina, i7 2.66 Ghz)
• PCIe-based Flash Storage
• 2-4 virtuals machines using VMware Fusion 4, each with 2 GB of RAM.
• Ubuntu 13.10 server edition with PHP 5.5 and OPCache enabled
• GlusterFS running on all VMs with a volume in replica mode
• The volume was mounted using nodiratime,noatime using GlusterFS native driver (NFS was slower)

The test:

1. siege -c 20 -r 5 http://localhost/foo  # Cache warming
2. siege -c 20 -r 100 http://localhost/foo  # Actual test

I then compared the local filesystem (inside the VM) vs the Gluster volume using these setups:

• 2 nodes, 4 cores per node
• 2 nodes, 2 cores per node
• 4 nodes, 2 cores per node

The compared value is the total time to serve 20 x 100 requests in parallel.
All tests were ran 2-3 times while my computer was doing nothing and the results were very consistent.

		Symfony	Wordpress	Drupal	Average
2 nodes 4 cores	Local	2.91 s	9.92 s	5.39 s	6.07 s
	Gluster	10.84 s	23.94 s	7.81 s	14.20 s
2 nodes 2 cores	Local	5.41 s	19.14 s	9.67 s	11.41 s
	Gluster	25.05 s	31.91 s	15.17 s	24.04 s
4 nodes 2 cores	Local	5.57 s	19.6 s	9.79 s	11.65 s
	Gluster	30.56 s	35.92 s	18.36 s	28.28 s
Local vs Gluster	2 nodes, 4 cores	273 %	141 %	45 %	153 %
	2 nodes, 2 cores	363 %	67 %	57 %	162 %
	4 nodes, 2 cores	449 %	83 %	88 %	206 %
	Average	361 %	97 %	63 %	174 %
2 nodes vs 4 nodes	Local	3 %	2 %	1 %	2 %
	Gluster	22 %	13 %	21 %	19 %
4 cores vs 2 cores	Local	86 %	93 %	79 %	86 %
	Gluster	131 %	33 %	94 %	86 %

Google spreadsheet

Observations:

1. Red — Wordpress and Drupal have an acceptable loss in performance under Gluster, but Symfony is catastrophic.
2. Blue — The local tests are slightly slower when using 4 nodes vs 2 nodes. This is normal, my computer had 4 VMs running.
3. Green — The gluster tests are 20% slower on a 4 node setup because there is more communication between the nodes to keep them all in sync. 20% overhead for double the nodes isn’t that bad.
4. Purple — The local tests are 85% quicker using 4 cores vs 2 cores. A bit under 100% is normal, there is always some overhead to parallel processing.
5. Yellow — For the Gluster tests, Symfony and Drupal scale very well with the number of nodes, but Wordpress is stalling, I am not sure why.

I am still not sure why Symfony is so much slower on GlusterFS, but really, I can’t use it in production for the moment because I/O is already the weak point of my infrastructure. I am in the process of looking for a different hosting solution, maybe it will be better then.

Wordpress MU-Plugins subdirectory loader

Wordpress’s Must Use Plugins are an easy way to include quick pieces of code that will always be included.

While having my way with Composer and Composer Installers, I stumbled upon a Pull Request about adding support for mu-plugins. I already commented saying that I don’t how I works for them, because Wordpress does not load mu-plugins in subdirectories, they must be at the root of /wp-content/mu-plugins/.

After searching a bit, I found that someone had already thought of loading mu-plugins recursively but this solution was not enough for me :

1. Calling a scandir each request seems wrong (performance-wise), it seems better to cache the results.
2. It requires that each folder has a file named like "folder.php", which a lot of existing plugins don’t have.
3. It does not list the included plugins in the admin so it is completely invisible.

The solution below covers all this, any plugin may be simply dropped in mu-plugins and it will be required.

Except normal installation (manually or via Composer), the only other step is to copy or symlink a file in your mu-plugins directory.

https://github.com/wemakecustom/wp-mu-loader

bcrypt with ircmaxell and how to use it

It is common knowledge that md5 is not secure for password hashing. It is almost worst than plaintext because it may falsly induce the impression of security. People aware of this usually also consider sha1 insecure and straightly go to sha256. Some techniques exist to add further security like adding a salt or hashing multiple times but ultimately the flaw remains: those methods are too quick. If you can hash a password in a fraction of a second, a standard bruteforce can as well. That’s why strong password security involves slow algorithms.

I was aware of all those principles, but @ircmaxell, contributor to PHP, made a video on password hashing with a nice comparison of different hashing functions and it struck me how quickly even a sha512 is computed quickly. Before, I often considered bcrypt as a nice feature to add to a backend but I now realise it is a must.



And be sure to check his blog post with the slides and some other discussion (yes, we have the same blog template).

Now, this is all very cute, but Anthony talks about an easy API coming in PHP 5.5 so it will not be usable anytime soon.

Here are plugins/ways to integrate bcrypt into several platforms:

• Symfony2
• Wordpress
• Drupal

Two good libraries:

• PHPass
• PHP-PasswordLib (5.3+)

But really, it boils down to this:

PHP script to replace site url in Wordpress database dump, even with WPML

Wordpress has the nice habit of storing every URL with its full path in the database. You sure can hardcode the HOME_URL and SITE_URL in the wp-config.php but it won't change the references to your medias, serialized strings, encoded HTML, etc.

The only solution is really just to edit the database. At least, I haven't found a better solution.

Usage

wordpress-change-url.php http://old-domain.com https://new-domain.com < database.orig.sql > database.new.sql

Or

wordpress-change-url.php database.orig.sql https://new-domain.com > database.new.sql




Will output all remaining mentions of http://old-domain.com to stderr