Tag archive: WordPress

Update on my plugins

I’ve been very busy with my work at The Bureau, and my plugins have been a little neglected of late.

I knew the release of WordPress 5 — with Gutenberg — would necessitate a bit of updating. In the sense of letting people know that there’s no immediate plans to support Gutenberg. All sites I work on are using the Classic Editor plugin for now to avoid Gutenberg.

I’ve been prompted into action just now because Developer’s Custom Fields was completely removed from the wordpress.org repository, without letting me know first. An over-enthusiastic check for no-longer-maintained plugins falsely flagged this one, and it took a little negotiation to get it back. It’s back with a ‘disabled’ status — I can release fixes but it’s closed to new installations.

Anyway, here’s a summary of where each of my plugins are at now.

Read more »

How to restrict a WordPress page template to one page

WordPress page templates (now applicable to any post type) are designed to be re-used for any number of pages. However, sometimes I want there to be a template that only gets used once. It is possible to tie a template to a specific page by using the page-{slug}.php or page-{id}.php template naming patterns, but slugs and IDs can sometimes be unstable (e.g. across different environments). How to use a template and make sure it only gets used once? As with most cats, there’s probably many ways to skin this one. But here’s one way.

Read more »

Yoda conditions

Because I usually work with WordPress, and because coding standards are a good way of avoiding endless personal decisions that then get in the way of collaborating, I tend to follow the WordPress coding standards. You should too.

Now, there’s something that I’ve noticed when looking at core WP code, which I’d always assumed was some idiosyncrasy that the WP had settled on arbitrarily. It’s where condition expressions are written with the value being tested first, then the variable against which it’s being tested:

if ( 'value' == $var ) { [do stuff...] }

I just thought that was weird, and in the interests of readability I’ve always been doing it the other way around.

Well it turns out there’s a very good reason for this style, and they call it Yoda conditions. The reason is something we’ve all done – typing a single ‘=’ instead of a double one (‘==’). What happens then (with $var = 'value') is that the value isĀ assigned to the variable, and the expression will return the assigned value. So the supposed ‘test’ will always return something equivalent to boolean false, or true, depending on the value (in this case, any string would mean the expression evaluated to true). This can be damnably hard to debug.

So, switching the order means that if you mistype the assignment operator, the mistake will result in an attempt to assign a variable to the value – which isn’t going to happen. So the error is thrown in the right place, and you don’t lose time searching for it.

The weirdness contains wisdom after all.

A little bizarre, it is, to read. Get used to it, you will.

(Credit to the guy from the WordCamp London after party last night! I forgot your name but the tip made it.)

WordPress plugin to help repair serialized arrays in custom fields

I just launched a project, and despite using a heavily tried-and-tested script for dealing with serialized data in migrating, we ended up with some custom field values that weren’t being output (in admin or on the front-end) because the serialized values had become corrupted. I think it must have been something strange to do with characters pasted in from Word, maybe in conjunction with the recent WP core upgrade to handling utf8mb4 data. I’m not sure.

In any case, I found a PHP script that repairs serialized data, and turned it into a plugin: Repair Meta.

Read more »

Custom post types, authors, and custom roles

When you create a custom post type in WordPress, you can set it to ‘support’ a number of things: a featured image, trackbacks, revisions… and author. You might want to use it in the way author is used for core posts, literally the credited author of a post. Or maybe you could use it to give a bit more granularity to user permissions. The ‘owner’ of a post, if you will. Great!

Well, that’s what I wanted to do. Turns out it’s a little more complicated…

Read more »

When a post is first published, but not when it’s re-published

I’ve just been looking into some WordPress code that needs to run only when a post is first published.

WordPress provides a number of hooks for post status transitions. You’d think the one to use would be post_publish. However, testing shows that this also fires when a post is updated. Also, consider the scenario where an editor sets a post back to draft, then re-publishes. Do you also want the code to run then?

Read more »

Hide recurring events in admin for The Events Calendar

I’m just getting going with Modern Tribe’s The Events Calendar plugin, and so far it’s very impressive.

As with any plugin, however good, it’s got its idiosyncracies and annoyances. I’ve just been looking into how to hide recurring instances of events in the admin list. It seems the plugin used to include admin list filter options, but they’ve recently been taken out of this plugin and shifted to their Advanced Post Manager plugin.

Now, I use Codepress’ Admin Columns, and I don’t have time for weighing these two up right now. Generally I’m very happy with what I’ve got. But I think loading both plugins at once might lead to messiness. Maybe I can just whip up a little bit of code for now to add this simple feature?

Read more »

Developer’s Custom Fields 2.0 – a rewrite

Together with Adrian Toll, I’m starting to plan a new, mostly rewritten version of the plugin Developer’s Custom Fields.

Despite the obvious power and sophistication of plugins such as Advanced Custom Fields, we both prefer the lighter, more developer-friendly style of our own plugin. And while the proposed metadata UI for core seemed promising for a while, it seems to have stalled for now, or at the very least slowed down considerably. So, we’ve decided to revamp to give this plugin a healthy lease of life until a rival solution does a better job for us.

Read more »

Letting go of Force Strong Passwords

For a while now, I’ve been using the Wordfence plugin to add extra security to my WordPress sites. Since this plugin includes (among other things) the ability to force users to choose strong passwords, I’ve stopped using my own plugin, Force Strong Passwords.

Because of this, I’ve decided to transfer it to someone else. Jason Cosper has kindly stepped up. Jason’s a senior engineer at WP Engine, who I gather use the plugin on their network. With this vested interest in the plugin, I trust it’s in good hands.

Complete archive

Main index