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
Namespaces aren’t used by WordPress programmers, but I’ve been using them, and like them. This short tutorial explains namespaces, and how they work together with class autoloaders to keep your code organized.
Continue reading PHP Namespaces, Autoloaders and WordPress
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
Everyone loves the parallax effect, and I’ve been swiping snippets of code to do it for a long time, but never really thinking about it too much. You load it, set some parameters, and that’s it. I was having a little glitch with one, and was tweaking it, and I started to wonder why the effect didn’t just start at one end of my image, and end at the other end.
After all, if I don’t show all the pixels, I’ve “wasted” all those network bytes to load the data, and all the memory to hold the data.
This parallax effect is stingy with network bytes.
Continue reading Yet Another Parallax Effect, but This One Wastes Fewer Pixels and Bytes.
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