(Firefox asked me to rate it this morning, with a little picture of a broken heart and five stars to select from. I gave it five (’cause it’s brilliant) and then it sent me to a survey on mozilla.com titled “Heavy User V2”, which sounds like the name of an confused interplanetary supply ship.)
Today WikiCite17 begins. Three days of talking and hacking about the galaxy that comprises Wikipedia, Wikidata, Wikisource, citations, and all bibliographic data. There are lots of different ways into this topic, and I’m focusing not on Wikipedia citations (which is the main drive of the conference, I think), but on getting (English) Wikisource metadata a tiny bit further along (e.g. figure out how to display work details on a Wikisource edition page); and on a little side project of adding a Wikidata-backed citation system to WordPress.
The former is currently stalled on me not understanding the details of P629 ‘edition or translation of’ — specifically whether it should be allowed to have multiple values.
The latter is rolling on quite well, and I’ve got it searching and displaying and the beginnings of updating ‘book’ records on Wikidata. Soon it shall be able to make lists of items, and insert the lists (or individual citations of items on them) into blog posts and pages. I’m not sure what the state of the art is in PHP of packages for formatting citations, but I’m hoping there’s something good out there.
And here is a scary chicken I saw yesterday at the Naturhistorisches Museum:
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!)
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.
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… :-)
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:
git clone https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git
git clone https://github.com/squizlabs/PHP_CodeSniffer.git
Mostly you’ll be working from the PHP_CodeSniffer side of things. Change into that directory and set up its dependencies:
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
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.
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';
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.