I recently learned about a browser feature where, if you provide a special HTTP header, it will automatically post to a URL with a report of any non-HTTPS content. This would be a great thing to do when transitioning a site to HTTPS, for example, to root out any mixed content warnings. In this article, we'll implement this feature via a small WordPress plugin.
Of all the projects I've worked in the last few years, there's one that stands out as my favorite: I wrote a WordPress plugin called Great Eagle (Tolkien reference) that allows my team to install and update themes and plugins from our private Bitbucket repos, via the normal wp-admin updates UI.
This plugin has blasted our dev shop through the roof when it comes to development best practices, in ways we never expected or intended. It forces us to use proper version numbers because now we can't deploy without them. It forces us to store our work in Bitbucket because now we can't deploy without it. It forces us to use the command line en route to deploying our work (by which I simply mean,
git push origin master), which then led to us using phpUnit. Now we can't deploy unless our tests pass. We've arrived at the nirvana of test-driven development, all because we started with the unrelated step of deploying from git.
If this all sounds standard and obvious, great. I'd love a chance to learn from you. If this sounds like exotic rigmarole, guess what? This article is for you.
This is the third and final article in a series on "remote control WordPress". That's my nickname for this strategy of managing network settings on one "control" install, and then pulling those values into all your client installs. The advantage is that it saves staff members from having to toggle the same settings on the same network plugins, across many multisite installs.
This is the second article in a three-part series about using the WP API to achieve something I'm calling "Remote Control WordPress", a lifestyle where you'd manage network settings on a "control" install, and have other "client" installs pull their settings from the control. The advantage of this is that you could then manage the settings for many WordPress installs all in one place. The first article laid out how to register network settings as a custom endpoint in the WP API, but stopped short of demonstrating how to grab those settings when they are protected by a permissions callback, which they should be. This article picks up that thread, demonstrating how to pass OAuth credentials to the WP API.
At my day job, we have about 1,000 sites spread across 30 WordPress multisite installs. The installs all run many of the same plugins and settings, especially at the network level. This causes a lot of wasted time for our staff: They have to manually repeat the same settings across 30 installs. Because of this, we're moving to something I like to call "Remote Control WordPress".
At the agency I work for, we recently put all ~1,100 of our sites behind a CDN. It seems to be working. Unfortunately, I have no idea why or how we did this. Therefore, in the first part of this article, I force our CTO, Joshua Lynch, to explain the process to me. This has the unintended consequence of Josh suggesting I try this on my own website, a process I'll narrate for the second half of the article.
Let's say you have a client whose business is large enough to have several departments. Now let's say that this client wants each of their departments to have their own website on a dedicated domain. Each site is to have the same layout, but a different color scheme. This is a phenomenal use-case for the WordPress Customizer (aka the Theme Customization API), and I'd like to share a basic example of how to build it into a theme.
The following is a guest post by Scott Fennell. Scott is a WordPress theme & plugin developer in Anchorage, Alaska. Here, he customizes the default HTML output of WordPress' menu system to his liking, without damaging the useful things it already does.
There are many things about the WordPress nav menu system that I like, and a handful of things I really dislike. The things I dislike happen to trigger my pet peeves: Markup-bloat and non-SMACCS-ish class names. To me, it's worth a deep dive to correct this situation. However, I don't want to lose integration with the admin UI, and I don't want to lose the dynamic class names that core gives us, such as
current-menu-ancestor. Therefore, I'm not going to replace anything: I'm going to extend the PHP class that draws the nav menus: The
In this article we dig into an important type of caching that is available to you in WordPress: transients. Like any cache, you use transients to store any kind of data that takes a long time to get, so the next time you need it, it returns super fast. The beauty of transients is they clean up after themselves, as long as you watch out for the pitfalls described here!