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.
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.
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.
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:
- user authentication and authorisation;
- installation and upgrade;
- a theming/skinning system;
- familiar UI for users;
- 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.
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:
I’ve just been tinkering with writing a new Dokuwiki plugin that I’ve wanted for a while: log404. It logs all not-found page hits (as in, HTTP status 404 Not Found), and gives an admin page for viewing (and deleting) them. Soon to come is a way to add a not-found page ID to the redirect plugin’s list of redirects. That’ll be about all the thing shall do. Oh, and keep a list of 404s to ignore. And have a nicer-looking admin page! That’s all…
I’ve not created a page on dokuwiki.org yet (https://dokuwiki.org/plugin:log404) because it’s not finished enough yet.
I have, however, added it to Travis CI—the first thing I’ve done that with. It’s jolly nice having a little green badge in the readme!
Right then. Friday arvo—time to get a beer.
I want to help to write plugins for things. Not these full-blow, stand-alone applications with requirements and scopes that change and change and are never finalised! Far nicer to work on a small part of a bigger application, with a particular goal in mind that can — with time and work — come closer and closer to being realised.
With other people, too. That’s the best part of it. There’s whole communities of users out there. Much nicer to work with.
[This post was about version 0.9, but I’ve sorted out a major bug, and added Gravatars, and because my daft consecutive version numbering system was up to it, I’ve had to release Version One twenty minutes after 0.9; I didn’t see the point of writing a whole new post.]
I’ve added support for the hCard microformat; if you want this to be a fun thing, I recommend getting the Operator addon for Firefox (you’re already using Firefox, aren’t you? You should be, it’s not pants (to quote S. Fry)).
If an addressbook contact has a gravatar, it will now be displayed in both address lists.
As always, get this version from the WordPress site, and give me any feedback in the comments to this post. Thanks!
I’ve just submitted a patch for Squirrelmail’s Variable Sent Folder plugin, fixing that plugin’s lack of respect for the user’s choice of folder-select-box display. It’s been annoying me for a while. Here’s the patched version (0.4sw).