Returning (again) to WordPress

Every few years I try to move my blog away from WordPress. I tried again earlier this year, but here I am back in WordPress before even a month has gone by! Basically, nothing is as conducive to writing for the web.

I love MediaWiki (which is what I shifted to this time; last time around it was Dokuwiki and for a brief period last year it was a wrapper for Pandoc that I’m calling markdownsite; there have been other systems too) but wikis really are general-purpose co-writing platforms, best for multiple users working on text that needs to be revised forever. Not random mutterings of that no one will ever read, let alone particularly need to edit on an on-going basis.

So WordPress it is, and it’s leading me to consider the various ‘streams’ of words that I use daily: email, photography, journal, calendar, and blog (I’ll not get into the horrendous topic of chat platforms). In the context of those streams, WordPress excels. So I’ll try it again, I think.

Abandoned code projects

One of the sad things about open source software is the process of working on some code, feeling like it’s going somewhere good and is useful to people, but then at some point having to abandon it. Normally just because life moves on and the higher-priority code always has to be the stuff that earns an income, or just that there are only so many slots for projects in my brain.

I feel this way about Tabulate, the WordPress plugin I was working on until a year ago, and about a few Dokuwiki plugins that I used to maintain. All were good fun to work on, and served reasonably useful places in some people’s websites. But I don’t have time, especially as it takes even more time & concentration to switch between completely separate codebases and communities — the latter especially. So these projects just languish, usually until some wonderful person comes along on Github and asks to take over as maintainer.

I am going to try to keep up with Tabulate, however. It doesn’t need that much work, and the WordPress ecosystem is a world that I actually find quite rewarding to inhabit (I know lots of people wouldn’t agree with that, and certainly there’s a commercial side to it that I find a bit tiring).

Not this morning, though, but maybe later this week… :-)

Running tests on WordPress coding standards

The docs for WordPress-Coding-Standards assume that one is installing things globally, but I don’t like my hacking on phpcs to break my usage of it elsewhere, so I wanted to cordon things off in their own little dev area. This is how.

Clone the two required repositories to directories next to each other:

cd ~/public_html/wordpress/
git clone
git clone

Mostly you’ll be working from the PHP_CodeSniffer side of things. Change into that directory and set up its dependencies:

cd PHP_CodeSniffer
composer install

Set up phpcs so that it can find its tests and the WordPress coding standards:

cp phpunit.xml.dist phpunit.xml
./scripts/phpcs --config-set installed_paths ../WordPress-Coding-Standards/

And now you’re ready to run the tests (still from the PHP_CodeSniffer directory):

./vendor/bin/phpunit --filter WordPress

Spaces around dots

One of the first odd things that one finds when starting to work with WordPress code is the excessive use of spaces. Something like:

do_something('Words of '.$widget->noun($attrs['ish']));

becomes the the stretched out:

do_something( 'Words of ' . $widget->noun( $attrs['ish'] ) );

Which is fine, and actually now I’ve been using it for a decade I’m pretty comfortable reading it. But it’s uncommon in the PHP world. (And note the singular place in which spaces aren’t used: the array key, iff it’s a string.)

Not only that, but I just recently realised that the PHP CodeSniffer sniffs for WordPress don’t actually check for the spaces around the concatenation operator. I’ve filed an issue for that.

Uninstalling WordPress plugins in PHPunit

There’s a problem with uninstalling Tabulate.

Fatal error: Class 'WordPress\Tabulate\DB\Grants' not found
in C:\work\public_html\wp\stage\wp-content\plugins\tabulate\uninstall.php on line 8

The uninstall.php file shouldn’t know anything about the actual plugin. It shouldn’t use any classes or functions from the plugin itself.

This problem should have been caught before now, though, because the tests all run uninstall.php in their tearDown() function. The reason they don’t is that the Tabulate classes are still available at that point.

Perhaps it’s a matter of removing the autoloader? In the tearDown() function:

$autoloader = require __DIR__.'/../vendor/autoload.php';

But no, then the autoloader isn’t loaded for the next test. So can we re-enable it in setUp()? Yes, but that still doesn’t make it fail on the classes used in uninstall.php… I’m not sure why not.

Is there anything wrong with just including autoload.php in uninstall.php? No, I thought not.

That was easy.

Be careful with GET parameter names in WordPress

I’ve been getting confused about why an HTML form I’ve been building inside a WordPress shortcode has been getting redirected after submission. Turns out it was because I was using p as a name for a request variable, and that’s not allowed. It’s one of the names used by WordPress core; there are a few dozen of them.

I switched to prefixing my form’s input names with the name of the plugin, and all is well.

WordPress (not Laravel) as an app framework

Is it a good idea to develop full-blown applications as plugins inside WordPress (or an other CMS)? I sometimes feel like it’s a silly thing to do. Especially if the application is not really doing anything to extend or complement the standard functions of the CMS, and is just existing as a stand-alone creature within it.

In WordPress, for instance, lots of things can be done by creating new post types: a plugin for tracking books and authors could have two new post types for those entities, and we would attach whatever metadata is required. Or alternately, a few new database tables could be created, and the book-managing plugin could do things directly with them and completely ignore the standard post functionality. The latter would mean other common features of filtering and things wouldn’t apply, but then that’s often just as it should be when we need full control over how an application behaves.

Basically, I sometimes only really use WordPress as a framework for:

  1. user authentication and authorisation;
  2. installation and upgrade;
  3. a theming/skinning system;
  4. internationalisation;
  5. familiar UI for users;
  6. the front-end/back-end dicotomy.

And that’s it. Everything else is within the plugin. See how it feels a bit silly?

However, it means that a plugin-application does have the things listed above (for no effort on my part), and it also gets what it perhaps the most important reason that I go this route: the WordPress community.

So I’ll carry on being silly.

‘Reports’ in Tabulate

I’ve been working on a system for integrating custom queries and outputs into Tabulate. So far, it’s only been possible to use MySQL views to combine data from different tables, and the output has been just the same as for base tables. I keep wanting to be able to apply custom formatting to columns or to whole tables — the data is fine, it can almost always be derived with a single SQL statement.

Currently, I’m working on a system of ‘reports’, where one can define a template (using Twig) and a set of SQL queries whose data will be given to the template. Pretty simple, really. I thought about (actually, still wonder if it’s not a better way) making it possible to define custom formats/templates for individual columns and column types, but everything that that approach can do can be done with these ‘reports’, plus a whole lot more.

So, a report (a record in the $prefix_tabulate_reports table) has a title, description, and a Twig template. Then it has a set of SQL queries (in the $prefix_tabulate_report_queries table), each of which has a name (which is what the query is passed into the template as).

It’s hard to know if this is enough. It might even be too much — Tabulate is not meant to be anything more than a CRUD tool, and customisation above and beyond what it does can easily be handled with custom plugins. It does seem that it’s worth making Tabulate able to do some basic display-customisation though, so that site authors can more easily work with data without having to write any custom code.

Because that’s really the goal of Tabulate: it should provide simple ways to work with tabualar data within WordPress in much the same way that spreadsheet programes do on the desktop (well, that’s perhaps a bit of an overstatement, considering the crazy things that people do with spreadsheets). It should easily insert a list of statistics into a post; or add an always-up-to-date chart to a page; or invite submissions of data points from registered users; and generally make it easier (than spreadsheets do) to enforce referential integrity, proper data types, and other essential constraints.

Tabulate 1.0.0

I’ve just realeased version 1.0.0 of Tabulate, a WordPress plugin for working with data in a site’s MySQL database. I’ve been using it for a few months in production, and the shift from 0.* to 1.0 was fairly arbitrary — it just seemed stable enough now. The new feature that got included in this release is the ability to export to OpenStreetMap XML (not a great leap ahead of the KML export that was already done).

Any problems with Tabulate can be lodged on the issue tracker at Github, or on the normal WordPress support forum.

Here’s a suburb’s worth of power pole locations, exported from Tabulate and opened in JOSM:

Poles in Hamilton Hill