In yesterday’s post, I talked about fixing up old PHP code to be safer.
There’s another anti-pattern common in old PHP code, and that’s mixing the display logic with the output logic. While some of this is inevitable, nowadays, the rule is to use a templating system like Twig to separate out even small bits of HTML code from the logic.
WordPress does this on the front end via Underscore templates, but configured to use Handlebars-like syntax.
This is a PHP class that does the same thing with PHP. I wrote it so I could use the same, or similar, templates on both the client and server side.
Continue reading WP’s Backbone-like Templating Language
I needed to learn a little about the events triggered in the Customizer, and came up with a little script that prints events to the console log. This is specific to the Customizer’s event system.
Continue reading Observing the WordPress Customizer (wp.customize) Events
There are several good references about how to set up the Customizer to avoid refreshing the entire page with each change. There’s one here, and there’s some deeper explanation here. What’s not described much is how to map several settings to a single area of the page (called a Partial).
This tutorial will go into updating Partials that use several settings. I assume you have already done the other tutorials.
Continue reading WordPress Customizer, Selective Refresh and Partials for Multiple Settings
On the page where they explain how to create tables for your plugin, there’s a link to the register_activation_hook function, which is run when the plugin is activated. However, right in the first section, it says:
Note: Don’t use activation hooks (especially for multisite). Do this instead:
It’s far better to use an upgrade routine fired on admin_init, and handle that per-site, basing it on a stored option.
That links to another page, which repeats the information, but doesn’t tell you how to do this. Here’s one way. Continue reading WordPress Plugin Update and Install Functions
I’m shocked at how many businesses still have websites that don’t work in mobile. For the average person, reading web pages on a smartphone is the primary way they read content on the web.
Though I’m not 100% on board with “mobile first”, it should soon be the norm. To CSS hackers, “mobile first” just means implementing the mobile layout first, then making the wider-screen layout the exception.
Continue reading Responsive Design + Mobile First = Automated Layouts