It turned out to be simpler than I’d thought to add the ENUM-modifying feature to Tabulate’s schema editor, so I’ve done it and released version 2.9.0.
I’m trying to figure out if it’s worthwhile adding better support for enumerated fields in Tabulate. MySQL’s ENUM type is useful when one has an immutable list of options such as days of the week, seasons of the year, planets in the solar system, or suits in a deck of cards. It can also be good for making ternary options more distinct and communicable than a nullable boolean field.
But really, I’ve never used them! I mean, I have in one place (which is why this is coming up for me at all, because I’m trying to do some work with an ancient database that I’ve pulled into WordPress + Tabulate) but I’ve never used them in any situation that I couldn’t have more easily solved by adding a cross-reference to another table.
Reference tables are far easier to work with, and allow other metadata to be attached to the referenced values (such as colour, in the card-suit example).
However, ENUMs are already supported by Tabulate for the display of data, so I guess I should just do the little extra bit of work required to add support to the table-structure editing as well. Even if no one uses it.
(On a related note, I don’t think SET fields are going to get the same treatment!)
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… :-)
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
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
$autoloader = require __DIR__.'/../vendor/autoload.php'; $autoloader->unregister();
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
uninstall.php? No, I thought not.
That was easy.
I’ve just added a new feature to Tabulate, that allows for the exporting (to CSV) of the set of filter values (for multi-valued filters) that are not found in the data. It also now tells you, next to each multi-valued filter, how many values you’ve got in the search field.
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.
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.
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: