Update Check: Get notified of WordPress updates automatically

One of the simplest ways to keep your WordPress site secure is to stay on top of regular updates. Developers are constantly releasing bugfixes to help close security hole, and as good users of open-source software it’s our duty to stay up-to-date.

For many WordPress sites, it’s immediately obvious when updates are available: you log into WordPress, and it says “hey, there are updates! Click here to install them!”. Unfortunately, that ability compromises site security for ease-of-use; WordPress should not be able to edit its own files on the web server.

Reinitialize Slick Carousel after “unslick”

Slick: the last carousel you'll ever need

The popular Slick Carousel jQuery plugin promotes itself as “the last carousel you’ll ever need,” and it is quite a powerful library. Slick Carousel enables us to have responsive, swipe-enabled carousels on Growella that are both easy to use and to implement.

If there’s one major drawback to Slick Carousel, however, it’s that the plugin doesn’t let you easily disable the carousel at a certain breakpoint, then re-enable it if the user resizes his/her screen again. Fortunately, with a little bit of JavaScript, we have a pattern that works.

How to register custom field settings in Gravity Forms

Gravity Forms field configuration with custom field settings

We’re big fans of Gravity Forms here at Growella; it’s easy enough to use that our editorial team can build forms without developer intervention, yet powerful enough that we can process the data any way we need to.

One frustrating aspect of Gravity Forms, however, is adding our own custom field settings to Gravity Forms’ fields. There doesn’t seem to be an easy-to-follow resource for adding these things, so we decided to write one ourselves.

If you’ve ever wanted to add your own custom field settings to Gravity Forms, read on!

One-time callbacks with the WordPress Plugin API

The WordPress Plugin API is a fantastic way for third-party scripts to be able to inject themselves into the WordPress lifecycle; want to change the output of the post content? Simply attach a callback to the the_content filter:

/**
 * Inject a cat emoji at the end of the post content.
 *
 * @param string $content The post content.
 * @return string The filtered post content.
 */
function inject_cat_emoji( $content ) {
  return $content .= ' ?';
}
add_filter( 'the_content', 'inject_cat_emoji' );

Now, whenever content is run through the the_content filter, our “?” will be appended.

Simplify WordPress plugin audits

One of the great strengths of WordPress is the sheer size of its community; today, just over 27% of the web is running on WordPress, which makes it the single largest Content Management System (CMS) in the world.

Meanwhile, the WordPress.org plugin repository is home to nearly 50,000 freely-available plugins that cover everything from simple, custom sidebar widgets to full-fledged eCommerce and social network platforms.

While it’s great that there’s so much code readily available, using this code without thoroughly vetting it puts your site’s security at risk. That’s a big reason why it’s very common for professionals — both agency-side and internal — to perform plugin audits before rolling code out to production.

Tracking server-side HTTP Redirects with Google Analytics

When you need to be able to create HTTP redirects within WordPress, it’s hard to beat the Taylor Lovett’s Safe Redirect Manager.

Safe Redirect Manager creates a WordPress interface for managing HTTP redirects. Did you accidentally share the wrong URL with your customers? Fix the link, then simply create a redirect to ensure the user reaches their destination.

Here at Growella, we’re using Safe Redirect Manager for branded affiliate links; instead of sending users to <some-partner-url>/<some-long-affiliate-string>, we’re able to create URLs like https://growella.com/r/<partner-name>. Should the partner URL ever change, we’ll be able to update the target in a single place: within Safe Redirect Manager.

Being the bunch of data nerds that we are, we wanted to make sure we’re able to keep track of how often people are using our redirect links (a feature Safe Redirect Manager doesn’t offer out of the box). The HTTP redirects should show up in our Nginx logs, but we wanted something more readable: namely, Google Analytics.

Using Jetpack Popular Posts in WP_Query

Jetpack, Automattic's fremium, all-in-one utility belt for self-hosted WordPress sites, has a number of extremely useful tools for sites of all sizes. Whether you're using Protect (formerly BruteProtect) to limit malicious login attempts, Akismet to block spam, or Related Posts to cross-link content, Jetpack has at least one or two modules for pretty much anyone.

Of course, Jetpack is meant to be a “one size fits all” approach to WordPress; its engineers have designed Jetpack to be as simple as possible for people to start using, but often professional sites need professionally-customized features. Fortunately, Jetpack's source is pretty-well documented, and we're able to build on top of existing functionality.

Today, we're going to use Jetpack's stats_get_csv() function — normally used to populate the “Top Posts” widget — to create a WP_Query object that we can use like we would any other.

Show or hide meta boxes when changing the WordPress page template

WordPress has had the concept of page templates for a long time, but it was only in the last major release (4.7) that this feature was extended to support all post types. The timing couldn’t have been better, as Growella makes use of custom, named page templates for different types of content (regular articles, “Your Job is Whaat?!?” episodes, and more).

Being able to change the page template being used is great, but often a specialized template requires some specialized post meta to go with it. How can we show or hide different custom meta boxes based on the current template? I’m glad you asked!

Speed up deployments using gulp-changed

Growella uses DeployBot to handle deployments, but we're also using Gulp to run webpack, Sass, and other compilation tasks, then building a dist/ directory that acts as the root of our deployment. This ensures we're only deploying the files we need on production, while leaving out development assets.

We're also building Growella as a twelve-factor application, so we're using Composer and WPackagist to pull in our dependencies, which is super easy to do with DeployBot. We're even able to cache the composer install, ensuring it's only run when something has changed in composer.json (for instance, installing/upgrading a plugin).

On paper, this looks great: we're only running Composer when we need to, and we're able to prepare a nice, packaged version of the site for delivery to the target server, which is taking advantage of DeployBot's atomic deployment pattern.

Here's the rub: it was slow. Unacceptably slow, taking 10-15min to deploy a WordPress site.

Dynamic Asset Versioning

We're proud to announce that we've published our first plugin to the WordPress.org repository: Dynamic Asset Versioning.

Dynamic Asset Versioning was designed with one goal: prevent stale CSS and JavaScript from being served in a heavily-cached production environment. It accomplishes this by detecting when a script or style (registered and enqueued using wp_enqueue_script() or wp_enqueue_style(), respectively) is missing an explicit version number and, when such an asset is found, a version number is created dynamically.