Category: Code

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.

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.

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!

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:

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.

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.

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.

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!

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.

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.