Handy to know shizzle

Explore

Handy to know shizzle

Handy to know shizzle

WordPress knowledge capture

Author:

/u/kyle0r⁠

Published: 2024-04-26

I had to re-visit an old WordPress (WP) site I put together in 2016. Technology doesn’t stand still and the site had developed some rough edges and bugs.

This involved resolving some PHP “deprecated” usage issues and a simple JQuery syntax issue which had changed with a JQuery and/or JavaScript engine revision at some point.

As I was performing these fixes I realised other things were wrong with the WP site... so here are my notes for future me!

Hosting

The WP site is hosted on Debian using the Debian wordpress package[

1⁠

] which is implemented and deployed to support multi-sites.

Config is in the usual /etc/wordpress path which includes the multi-site specific configs and shared WP .htaccess file.

The main shared WP install is located in /usr/share/wordpress.

Hosted sites define WP_CONTENT_DIR in their wp-config file to specify site specific content path, for example /var/www/<site>/user/private/wp-content. This path includes some symlinks to /var/lib/wordpress/wp-content, which seems to mainly link back to /usr/share/wordpress/wp-content.

In summary this multi-site approach allows for an arbitrary number of WP sites up to the servers resource limits, sharing the same WP install but with the ability to have per site specific content, themes and plugins etc. Very efficient but also very brittle if you break something on the shared install. If you are running this kind of setup in production, it is a good practice to have a dev/staging environment to verify changes to the shared WP files, and use vm snapshots/backups to rollback if something goes wrong.

The apache2 server is running suexec-custom and libapache2-mod-fcgid. Each vhost has a dedicated Linux user and executes code with that user via FcgidWrapper and SuexecUserGroup. This allows for a relatively secure but still performant application server.

The database server is a vanilla MariaDB instance provided by Debian.

The WP site in question

A very vanilla deployment. No plugins, 1 theme.

Debug Bar plugin

The

Debug Bar⁠

plugin was helpful in showing some object cache stats, errors and notices etc. With this plugin it was easier to spot the WP API 404 error for example. An entry in the sites wp-config is needed define( 'WP_DEBUG', true );

Realisation about theme specific minified js|css

I had made the assumption that when a user enables minified css|js in a theme that WP default behaviour was to consolidate the required cs|js files respectively and then automatically minify/uglify/tersify the content and cache it.

This was incorrect. Without some kind of plugin it seems WP is not capable of such automatic minification and consolidation.

I came to realise that the option in the theme to serve minified content was a simply a toggle between unminified source files to static consolidated and minified files that the theme author had generated prior to publishing a given version of their theme.

This burnt some time, hence documenting it here for future me.

Realisation about the WP object cache

💡 This is related to the WP native object cache, which DOES NOT handle persistent caching OR minification OR consolidation of js|css OR caching of js|css files.

😲 I edited some theme js and fully expected that the change would immediately appear on the site. It didn’t... I realised minification was enabled on the theme. So, I went looking for the object cache stats thinking “OK something is getting cached” lets figure out how to flush the cache... turns out the minified js was static and not cached anywhere.

See the doc link herein, by default, the default/native WP object cache is non-persistent and lasts as long as the a given WP request to save on trips to the database. For more advanced caching... plugins are required. It looks like there are roughly two categories:

Plugins that handle/replace the native object cache and can offer cache persistence

Plugins that handle js and css minification and consolidation

There are probably some hybrid plugins that do both.

The WP json API was broken

To fix this I needed to add an /etc/hosts entry on the hosting server to override site domain name to the local RFC1918 ip address.

This solved the curl connection issue.

The server (kvm) is hosted on a hypervisor behind NAT and so WP curl calls to the sites WP API using the sites domain name were trying to connect to the public ip address (on the hypervisor) which means the WP curl connection was egressing the kvm to the hypervisor and then getting lost/stuck either due to NAT issues or because of the Hypervisor networking bridging setup. Hairpin NAT might of solved this BUT that would be a change on the hypervisor AND who knows what other consequences that might have OR if its even supported without issues with bridged networking. I know from first-hand experience that there are some shenanigans in the Linux kernel concerning NAT and bridging so I don’t want to go down that rabbit hole.

The next issue was the API requests were returning a 404 error...

The WP .htaccess file also needed to be *activated* which was skipped/overlooked in the past. I don’t know if Settings→Permalinks is a prerequisite to activating the WP .htaccess but I had done that as par for the course. That screen provided a copy+paste which needed to be added to the .htaccess. 💡 CAUTION: care is needed with the .htaccess file in general but even more so with this setup because its a shared WP multi-site deployment. 💡 The apache vhost needs to specify the following directive AllowOverride FileInfo to allow .htaccess files [

docs⁠

PHP cfg overrides

For best practice I added an override for PHP’s session.save_path directive in /var/www/<site>/php/conf.d/overrides.ini to a location that the vhost user could read/write. It doesn’t look like the site in question was trying to use sessions... nonetheless the path was invalid so I fixed that.

WP-CLI

This seems like a very handy tool for wp administrators to manage wp sites and potentially for automation of site creation and admin.

I found it while looking for a way to flush/clear WP object cache.

Here is an example invocation wp cache flush for the aforementioned multi-site deployment:

sudo -u www-data php ~/wp-cli.phar --path=/usr/share/wordpress --url='http://<site>' --user=<user> cache flush

Here are some links related to WP-CLI:

⁠

An Introductory Guide to Managing WordPress with WP-CLI — SitePoint⁠

⁠

How to Install WordPress Using WP-CLI on Debian 10⁠

⁠

Some useful commands of the WP-CLI:

wp cache flush [

doc⁠

]

wp help and wp help <command>

wp config list

wp shell interactive PHP shell within the WP site - write code, load code from files, execute functions etc

wp cron

wp rewrite flush flush rewrite rules (permalinks)

wp scaffold contains commands that create boilerplate or starting code for plugins, themes, child themes etc

wp user is for managing, updating, deleting and changing roles of users.

wp plugin makes it possible to list, install, activate, deactivate and delete plugins and some bulk operations

The WP-CLI also supports extension via packages. wp package controls this aspect of the tool. There are many other packages/commands maintained by the community. The full list can be found

here⁠

Database performance: socket vs. TCP

cite:

Do Unix Domain Sockets boost WordPress performance? - Kazimer Corp⁠

cite:

Connecting Wordpress to Database using Unix Domain Socket. - Pieter Bakker⁠

cite:

Need to Connect to a Local MySQL Server? Use Unix Domain Socket!⁠

⁠

Obtain the socket path from the db shell: mysql -e "select @@socket". Then update the wp-config as follows:

define('DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock');

Link dump

⁠

WP - Server Environment - PHP Extensions⁠

⁠

Common WordPress errors – Advanced Administration Handbook | Developer.WordPress.org⁠

⁠

wp-config.php – Common APIs Handbook | Developer.WordPress.org⁠

⁠

WP_Object_Cache – Class | Developer.WordPress.org⁠

⁠

The WordPress Object Cache is used to save on trips to the database. By default, the object cache is non-persistent. The Object Cache stores all of the cache data to memory and makes the cache contents available by using a key, which is used to name and later retrieve the cache contents.

The Object Cache can be replaced by other caching mechanisms by placing files in the wp-content folder which is looked at in wp-settings. If that file exists, then this file will not be included.

By default, the object cache is non-persistent. This means that data stored in the cache resides in memory only and only for the duration of the request. Cached data will not be stored persistently across page loads unless you install a
persistent caching⁠
plugin.

Use the
Transients API⁠
instead of these functions if you need to guarantee that your data will be cached.

⁠

2017:

Is define('WP_CACHE', true) needed for object caching?⁠

⁠

No, including this constant with a value of true loads advanced-cache.php. Object-cache.php is loaded and used automatically.

Potential WP caching plugins

⁠

WP Fastest Cache⁠

LiteSpeed Cache⁠

W3 Total Cache⁠

, [paid]

WP Rocket⁠

⁠

Future ideas

InfoSec: WordPress & fail2ban

In the past I had wanted to research this plugin. Still seems like it would be a good idea when I have time.

⁠

Loading wordpress.org⁠

⁠

https://wp-fail2ban.com/⁠

⁠

5.1. Event Log — WP fail2ban documentation⁠

⁠

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.