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…)

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…)