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

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.

‘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