Menu

richardtape.com

A WordPress Guy

Namespaces in WordPress development

As more and more developers come into the WordPress space (a truly wonderful thing) — many of whom transition from other ecosystems — I often hear or read about how antiquated those developers find WordPress coding practices. You don’t have autoloading? Or dependency management? Or… you get the idea. “Wait… you can’t even use Namespaces in WordPress development? How adorable.”

One of the key reasons – I believe – WordPress has become so incredibly popular is its continuing commitment to backwards compatibility. The changes they make to the core of WordPress very, very rarely cause issues for those upgrading. In fact, one of the finest pieces of coding in WordPress core is the automatic updater. It covers practically everything and is an absolute triumph. You simply can’t do that if you’re worried about breaking things.

I’ll talk more about why that applies in this case especially in a short while, but let’s ensure we’re all on the same page. Whilst this topic can be a little dry, I’m going to explain by example.

(more…)

From PHP-FPM to HHVM on Ubuntu

As a developer I enjoy using the latest and greatest…things. And, as a WordPress developer, I enjoy seeing how I can use the latest and greatest with the content management system I use on a day-to-day basis. Today I moved this very site from using PHP to HHVM. Here’s how.

(more…)

Setting up WordPress on HHVM on Digital Ocean

Note: This is a long tutorial (Over 4500 words) on how to set up WordPress on HHVM deployed with Capistrano and Composer. The actual process took me about an hour from start to finish. I’ve tried to be as complete as I could, but please leave comments if you see anything wrong or things that can be improved.

Also, I have absolutely no idea who my audience is for this post, so I apologise in advance if the level of verbosity isn’t quite for you. That being said, you will need to be at least relatively comfortable on the command line and have a basic understanding of how WordPress works – especially the wp-config.php file.

First up, let’s start with a few cautionary notes. HHVM is not finished. It still doesn’t support absolutely everything that native PHP does (it supports pretty much most of the stuff you should be using, though). If you use some crazy-ass WordPress plugins or some bonkers theme, it may well not be supported. It’s unlikely, but possible.

Second, let me make this absolutely clear; I am not an expert at this sort of stuff. I’m not a sysadmin. I’m not a devops overlord. I’m not a low-level engineer of any kind. I am, however, a guy who enjoys playing with the latest stuff and, after playing with this, I was so blown away by how fast it was, I thought I’d share my experience.

Third, this website – richardtape.com – doesn’t run on this stack just yet. I will be migrating to it fairly soon. Update: This site now runs on this stack. You can read the post about how I migrated from PHP to HHVM. I’ve set up several sites on this stack however, just not this one. I’ll probably write up a separate tutorial for switching from PHP-FPM and nginx to hhvm and nginx in the future.

(more…)

Memcached for WordPress on Ubuntu 14.04

If you’re unsure of what an object cache is, or what memcached is, your first port of call should be Scotty’s article on the subject.

WordPress has built-in support for a PHP object cache. However, it only exists temporarily – for a single page load. The best way to explain this is to think about options. When a page loads, WP loads all options from the database (technically all ‘autoloaded’ options, which is the default). Any later request for get_option() will call from the in-built object cache meaning no more hits to the database.

However, if you want this to be more persistent, you need to set up one of several solutions. One is setting up a memcached server. Sounds complicated. It kinda is…but, thanks to people who are much, much smarter than I am, the process of setting up memcached for WordPress is now simple. In order to get this working, you need to do two or three things;

  1. Install memcached on your server
  2. Place a config file in the correct location
  3. (sometimes) Adjust your wp-config.php file

(more…)

Composer packages and WPMU Plugins

I am by no means a composer expert. In fact it was something that Ale at Briteweb introduced me to a little over 9 months ago. So whilst the method that I’m describing below most definitely works – and is stable and solid – it is by no means the only, or indeed possibly best way to accomplish this task.

Composer packages, by default, are placed into their own directory, within the ‘install path’ that you specify. If you use the wpackagist repository then you have access to the wordpress-muplugin type. Unfortunately, WordPress Must Use (MU) plugins – by default – must be in the root of the mu-plugins directory (which by default is mu-plugins in your wp-content directory, but can be defined using WPMU_PLUGIN_DIR and WPMU_PLUGIN_URL ). This means that, without any modification, any composer package that is installed into the mu-plugins directory simply won’t work. Bummer.

(more…)