Tag: WordPress

A Tuesday morning

The internet seems to be full of bad news at the moment, so I’m ignoring it and focussing on some nice little code projects that are calming and friendly and only slightly maniacally frustrating.

SVG Translate tickets are petering out; version 0.10.3 is just out with some login fixes and language updates.

This morning I’m working on adding a ‘messages exist’ notification icon to the PageTriage toolbar.

And I think I’ve cracked the search-debouncing for my Embed Wikimedia plugin, so might be able to move on with the metadata- and appearance-improving stuff that I’ve been trying to do for weeks.

Building WordPress assets

Today I was just finally getting around to (maybe) updating my WordPress theme, and couldn’t for the life of me remember what the deal was with the new Node-based build system. So I went looking, only to find this posted on the Core blog today:

In May 2018 we’ve introduced a build step to WordPress core development as preparation to WordPress 5.0. While these changes never ended up in 5.0, the idea was to reorganize the way the JavaScript in WordPress is managed and structured so that it would be easier to include Gutenberg.

Since then, it was no longer possible to run WordPress from the src folder. This gave some issues, especially with developing WordPress core PHP. Today, @atimmer committed a patch which allows developers to build into src again.

So I do still have to build the assets, but it seems that PHP development can once again happen from the normal directory.

Maybe it’s a good thing that I’ve neglected WP development this last year or so?

Embedding Wikimedia URLs in WordPress

I’ve had a stab at a WordPress plugin for embedding Wikimedia URLs: https://github.com/samwilson/embed-wikimedia

It’s of course just a draft and proof-of-concept and beta and rough at the moment. It only supports Wikipedia and Wikimedia Commons; I’m going to add Wikidata next, I think, and then Wikisource (although that will mostly be a reformatted version of the Wikidata one, because all relevant metadata about Wikisource items is in Wikidata).

I have no idea if it’s very useful. I mainly want it for Commons photos, and Wikisource books.

Embed Piwigo 0.3.0

Embed Piwigo now has a home on WordPress.org, and I’ve announced it on the Piwigo forum. And you’ll notice it’s got a new name! It seems that WordPress plugins aren’t allowed to begin with a trademark, so piwigo-embeds was pooh-poohed and embed-piwigo suggested instead.

Now I want to make sure the caching is okay, and figure out what the captions should contain. There might be other problems too.

Piwigo Embeds (for WordPress)

Here’s my first draft at making Piwigo sites embeddable in WordPress: github.com/samwilson/piwigo-embeds

‘Embed’ here is what WordPress calls the ability to add a URL of a site on its own line in a post or page, and for a nice rendering of the site at that URL to be provided automatically. It works with core WordPress with sites like Youtube and Flickr, and somewhat for random other sites if they provide the right metadata. Piwigo does not yet provide particularly rich metadata (there are some ideas to do so, though), but anyway it’s nicer to be able to do something more complicated that uses the Piwigo API.

As a first hack at this, my plugin just shows the medium-sized image, with title below and description as the tooltip, and the image linked to the page on the Piwigo site. I plan on introducing caching, and perhaps some nicer display (dates, comment count, etc.). Ideas welcome!

Tabulate 2.10.3

I fixed a bug in Tabulate last night, and released version 2.10.3. I’ve rather been neglecting this project for a while, so it’s been nice to come back to it. There are a few things that I might try to get done on it in the next few days or weeks (starting with more documentation).

The bug was to do with the change in WordPress’ default database character set and how that affected the reports ‘title’ column. Previously, a key length on this column of 200 was okay as it was under MySQL’s maximum of 767 (i.e. 767 bytes / 3 bytes for utf8 = max. 255 characters), but now the default is utf8mb4 each character can use up to 4 bytes instead of 3, and so the length must be reduced to 191 (i.e. 767 bytes / 4 bytes for utf8mb4 = max. 191 characters). WordPress core only does this for sites running on MySQL 5.5 and above, but it seemed easier just to reduce the key length for all Tabulate installations; it doesn’t seem likely to be an annoyance to anyone.

Tabulate updated to not require REST API plugin

I’ve removed Tabulate’s dependency on the REST API plugin, because that’s now been moved in to core WordPress. (Actually, that happened rather a while ago, but I’m slack and haven’t been paying enough attention to Tabulate this year; other things going on!)

I hope to get back to adding file-field support to Tabulate sometime soon. That’d be a useful addition for me. Also, the whole situation with Reports needs sorting out: better documentation, easier to use, support for embedding in posts and as sidebar wigets, that sort of thing.

WikiCite 2017

(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:

Scary chicken (Deinonychus antirrhopus)

Should Tabulate support ENUM columns?

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