Category: Hosting Insights

“What the heck is a cron?” I field this question at least once a month from non-developers. It’s a great question. I’m going to break it into two questions though.

“What is a CRON?”
“What is WP-CRON?”

What is a CRON?

At its heart, a cron is a “time-based scheduler”. It handles tasks that need to be done on a regular basis and at a specific time. As an example, if you want your WordPress blog to display the weather forecast in the header, then each morning you need to go get the weather forecast. Yes, you could hire someone to log in each morning, go get the forecast and paste it into a widget.

A better plan is to have a program that runs each morning and talks to an API to fetch the day’s forecast and update your database for you. The program that runs your weather fetching program is called a CRON. The name is derived from “chronological” which roughly translates into “in order of time”.

Most systems these days have some concept of a cron. Unix based systems (Unix, Linux, macOS, etc.) actually have a version of a traditional cron. While some might put a nice graphical interface on them, they all boil down to a program named cron and a file named crontab.

The program cron is always running in the background and every minute it looks at the crontab and figures out if something needs to be done. If not, it goes back to sleep.

The crontab file contains when a program should be run and which program should be run. Each line represents a different task. They look something like this.

1 0 * * * ~/fetchForcast.sh

While this may look cryptic, all it is telling cron is that at 12:01 AM every day, run a program called fetchForcast.sh. Note that time added in the Cron tool is in UTC by default. Here is an easy guide to reading a crontab.

# ┌───────────── minute (0 – 59)
# │ ┌───────────── hour (0 – 23)
# │ │ ┌───────────── day of the month (1 – 31)
# │ │ │ ┌───────────── month (1 – 12)
# │ │ │ │ ┌───────────── day of the week (0 – 6) (Sunday to Saturday;
# │ │ │ │ │ 7 is also Sunday on some systems)
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
1 0 * * * ~/fetchForcast.sh

Now that you have the key, it’s pretty easy, huh?

That really is all there is to a traditional cron. Most hosts like SiteGround allow you access to the cron for your system. Sometimes you have to edit the crontab manually, but many hosts have a much better interface for you to use. Either way, you have the ability to run programs at a specific time and on a regular basis.

What is WP-CRON

Like most things, WordPress does things just a little differently. Because many plugin authors needed to be able to schedule things to happen regularly, and because many WordPress site owners don’t know where their crontab is, much less how to edit it, WordPress re-invented the cron.

At its core, WP-CRON acts like a traditional cron in that a developer can “schedule” a task to be done on a regular basis. However, unlike a traditional cron, WordPress does not have a program that is always running in the background of your server. So to make this world, WP-CRON is a process that is called every time a page is viewed.

On busy sites, this works fine. However, if your site isn’t busy, a task scheduled for 2:00 AM might be run at 5:24 AM if nobody visits your site until then. Sometimes this is ok, other times this is a problem.

If the tasks you need to run are time-sensitive and have to be run at the time scheduled, WP-CRON is not the scheduler you want to use. If on the other hand, the tasks you need to be done can happen “around” the time you schedule them, then WP-CRON is fine. Again, a lot depends on how busy your site is.

What are the alternatives?

If you have tasks that are time-sensitive and your host does not allow you access to the system’s cron, you have 2 alternatives. First, you can switch to a host like SiteGround that gives you this access. If that’s not possible, then there are several services free or paid that are nothing more than cron services.

They run cron and you can set a job to run via a nice web interface. The job would use a program like curl or wget (think of them as headless browsers) that call URLs on your site to fire a specific task. Most plugins that require a cron will give you the URL to call if you want to use an external cron. All you have to do is paste the URL in, set the time for it to run and you are done.

CRON is a valuable tool and once you understand how to work with it, you will find more uses for it. If you have plugins, then I can almost guarantee that your site has wp-cron jobs running. If you are curious, go to the WordPress plugin repository and search for cron. There are plugins you can install that will show you all the WP-CRON activity on your site. Be very careful though. Plugins set these for a reason. If you decide you don’t like one and delete it, the plugin that depends on the job will stop working.

[subscribe_cta]

Is your agency spending a lot of time on busy work and repeating the same efforts time and time again, from one client to the next? Is the development team wasting a lot of their focus and mental energy on menial tasks and boilerplate work? What if you could free up some or all of these resources and invest them into the added value that the client will see and evaluate instead?

WP-CLI is a command-line tool that can help you accelerate the way you interact with WordPress websites. It is also a framework you can use to formalize and automate all of the processes that are shared amongst your clients if you’re a developer or an agency. Because of its versatility and simplicity of use, WP-CLI has been part of SiteGround’s preinstalled toolkit since 2013. SiteGround has also been one of the first sponsors of the project and continues to do so for the past 3 years, 2020 including.

One of the main reasons for SiteGround’s support is the fact that WP-CLI perfectly complements their mission to provide powerful, yet simple to use tools for WordPress processes automation and optimization. In fact, together with SiteGround, we released this awesome webinar for everyone who hasn’t had the opportunity yet to find out how useful WP-CLI can be:

As one of the main co-maintainers of the WP-CLI ecosystem, I was really glad to accept this new invitation from SiteGround’s and share some practical tips on how you can make use of WP-CLI to level up your workflows and have your clients get more bang for their buck!

Accelerating administrative efforts

WP-CLI is first and foremost a direct replacement to a WordPress site’s admin dashboard. Instead of providing a graphical web interface where you click through menus to get things done, it provides a text-driven command-line interface to perform these same tasks using written wp-cli commands. What at first sounds like added effort eventually turns out to be an infinitely more expressive way of letting the site know what you need to have done, and this makes it scale so much better for complex use cases.

As a result, while it is not necessarily faster to type a command to make a change to a post than it is to click the corresponding button on that same post, the difference becomes more apparent once you deal with multiple posts instead. While you might shudder at the thought of manually making a change on the admin backend to thousands of posts on a large site, all you need for doing so with WP-CLI still happens to be a fairly simple command, usually a one-liner. Granted, it will take a bit more time to execute than it would for a single post, but you can just leave it running in the background and focus on something else in the meantime.

To show an example of this effect, let’s imagine you have a huge multisite network with thousands of sites. An existing user has proven their worth in terms of helping moderate the entire network and is to be promoted to being an administrator on all the sites. How would you go about doing this via the graphical admin backend?

It turns out that this is quite easy to do via WP-CLI:

wp site list --field=url | xargs -n1 -I {} wp --url={} user set-role <user-to-promote> administrator

The above command will retrieve the list of all site URLs for the network, and for each of these sites, set the role of the user in question to that of “administrator”. And while this might take a few minutes to complete, it is a one-liner that does the work for you. Using the web-based admin backend would probably cost you hours to do the same, or require you to write a one-off plugin to do so in a more efficient way.

For an overview of all the bundled commands that come by default with WP-CLI, you can browse the command reference at https://developer.wordpress.org/cli/commands/.

Using agency-wide defaults

WP-CLI supports configuration files at the global level as well as at the project level.

The global configuration file is best used for defining a developer’s personal preferences. The project-specific configuration file however should best be managed centrally across the agency and treated as a part of the project, just like your composer.json file.

To use a project-specific configuration file, all you need to do is create a wp-cli.yml file within the site’s root folder. It will accept a few entries that are specific to configuration files, like providing an array of commands to disable for that specific site. But it will also accept default values for any of the available commands with a unified syntax.

Let’s look at an example configuration file for a hypothetical project:

# WordPress Core is installed in a subfolder.
path: wp-core/
# Load WP-CLI-specific init code before executing a command.
require: wp-cli-init.php

# Provide default flags for the config create command.
config create:
    dbuser: root
    dbpass: 
    extra-php: |
        define( 'WP_DEBUG', true );
        define( 'WP_POST_REVISIONS', 50 );

# '_' is a special value denoting options for this wp-cli.yml.
_:
    # Inherit configuration from an arbitrary YAML file.
    inherit: agency-defaults.yml
    # Merge subcommand defaults instead of overriding.
    merge: true

As you can see, it is pretty straight-forward to provide defaults for any known command. Also, you can load centralized YAML files within such a project-specific config file as well, if you need it.

You can read more about WP-CLI configuration files at https://make.wordpress.org/cli/handbook/references/config/.

Automating recurring tasks

After you’ve used the command-line for a while to deal with administrative site work, you might start to notice recurring patterns. Are you always installing the same set of plugins to get started? Are you deleting a set of options from the database every time you want to test the onboarding flow? Maybe you constantly need to reset a user’s meta values to trigger that one piece of logic in your member’s area that is constantly being changed?

Instead of needing to remember a list of multiple commands and hopefully typing them without spelling mistakes, you should take a minute and put these into a shell script to automate that work. After all, a shell script is nothing more than a “step-by-step replay” of doing something manually in the console.

As an example, here’s a script that will automate the installation of a new WordPress site:

#!/usr/bin/env bash

# Configure the script to exit immediately if any command fails.
set -e

# Download WordPress core files.
wp core download

# Create wp-config.php file.
echo "Please enter your database credentials:"
wp config create --prompt

# Install WordPress.
echo "Please enter your WordPress installation details:"
wp core install --prompt

# Install standard plugins.
echo "Installing plugins..."
wp plugin install query-monitor user-switching wordpress-seo

# Activate and configure a few plugins:
echo "Configuring plugins..."
wp plugin activate wordpress-seo
wp option patch update wpseo_titles metadesc-home-wpseo "My new website"

echo "Done!"

You can, of course, improve this script over time to add more bells & whistles or to give more precise feedback. Sharing it with all of the agency’s developers makes sure you only need to invest once into the automation part, for everyone to reap the benefits later.

Furthermore, a collection of such scripts makes for excellent onboarding help when new developers join your team.

Extending for custom use cases

With more complex projects come more complex administrative requirements. WP-CLI provides its framework to developers so they can easily create their own custom commands to solve very specific business needs in an efficient way.

Running bulk checks across the entire range of an online shop’s products? No need to build an extra user interface for that – just wrap the checking logic in a WP-CLI command and you’re good to go. Then, take it a step further and automate these checks by running that command at a recurring schedule via a cron job!

Note that you can either include these custom commands within a site’s plugin or theme, or you can publish them as a separate package that can be installed via WP-CLI’s built-in package manager:

wp package install awesome-company/manage-all-the-things

While the range of commands bundled with WP-CLI already covers quite a few use cases, the possibility to build your own custom commands removes any remaining limits and leaves it up to your imagination only as to what you can do.

Executing tasks on remote sites

WP-CLI can connect to remote sites directly via the –ssh flag, provided that the WP-CLI binary is also installed and accessible on the remote machine:

wp --ssh=admin_user@123.456.78.90/var/www/my_site config set WP_DEBUG --raw true

What’s more, you can define aliases to denote the individual machines:

wp cli alias add @staging --set-ssh=123.456.78.90 --set-path/var/www/my_site --set-user=admin_user
wp @staging config set WP_DEBUG --raw true

The most powerful property of this is yet to come: you can group these aliases, and run a command on a group of machines instead of only a single machine. The built-in group @all is added by default, running the command on all the machines for which the alias was defined. But you can add your own groups that define a custom subset of machines. Groups can overlap, of course, and groups can contain other groups as well, letting you create an entire hierarchy of site management goodness! With these groups in place, you’ll do things like update all plugins on all staging sites, or add a user to all of your multisite networks, etc…

Browse to this link to learn more about connecting remotely to your servers or development machines.

Reaching for the black belt

To truly reap the biggest benefits from WP-CLI, you’ll want to combine the use of script automation, shared configuration, custom commands, and site aliases to ensure you cannot only address all of your agency’s usual needs but also do so at the exact point they are needed in one fell swoop.

Keep in mind that most of that work can be shared by and to all the members of the team. The return on the time you invest in this form of tooling will be multiplied by the members on your team that make use of them – it’s therefore very hard not to get a substantial benefit out of this!

In the end, optimizing the time it requires to deal with menial tasks and streamlining your workflows is what regains this time so you can use it where it matters most – creating value for your clients and gaining a competitive edge in a crowded market!

Getting started

The best place to get started right now is to read the WP-CLI documentation at https://make.wordpress.org/cli/handbook/ or you can read SiteGround’s details tutorials on WP-CLI. If you hit blocking issues or just have the odd question, head on over to the make.wordpress.org Slack team via https://make.wordpress.org/chat/ and join the #cli channel!

[subscribe_cta]

It’s that time again! WordPress 5.5 will be out today if everything goes as planned. I feel quite excited about this new version. I had the chance to be part of the magic that happened behind the scenes of this WordPress release as a mentor and  I would love to share the most important WordPress 5.5 features and improvements that will soon come your way. Our customers will receive the new version shortly after its official release, as always depending on the individual settings in the WordPress auto-updater for each of their installations.

Security Improvements

Easy Control of Plugins and Themes Automatic updates

Since WordPress 3.7 users have been able to turn on/off WordPress native auto-update for their plugins and themes through their wp-config file. Now with WordPress 5.5 turning on/off plugin and themes, auto-updates can be done much easier by clicking a link in the admin interface. 

Plugin Auto-updates

Most of the massive attacks on WordPress websites happen through outdated vulnerable plugins. That is why making the option for plugin auto-update so accessible to all users in the interface has the potential to greatly improve WordPress security. 

To review the Plugins auto-update feature in WordPress 5.5 when it rolls out, go to “All Plugins”, and you will see a new column “Automatic Updates”. We highly recommend that you keep plugin auto-updates ON for all your plugins, as this is the easiest way to receive security updates as soon as possible and keep your site safe. 

The SiteGround auto-updater also provides an option for plugin updates in its interface. We check for new versions of your plugins when we do core WordPress auto-updates and we do automatic backups of your WP installation right before the upgrade begins to guarantee a safe failover in case anything goes wrong. Choosing which plugin auto-update option to use is up to you: if you want to get your plugins updated as soon as a new version gets out, make sure you enable the new WordPress feature. It will work fine, regardless of the plugin auto-update setting in our own auto-updater. If you feel you better wait and get a backup before any update, you may rely only on our system. 

Themes Auto-updates

Based on our experience, auto-updating themes can be a trickier process than auto-updating plugins. That is why we have not included such an option so far in SiteGround WordPress auto-updater. After all, changing something in the theme can change the outlook of your website and you may not want this to happen automatically without being pre-viewed by you. 

Still, we believe it is a good idea to keep your themes up-to-date from a security point of view. The best way is to create a staging copy of your site when there is a theme update, check how your site with the updated theme there, and if everything is OK, update the theme on your production installation. 

If you none-the-less want to switch on the themes auto-updates, you need to click on each theme you have installed and enable the option from the theme screen.

Speed Improvements

There are a lot of factors that determine the performance of your website. However, images are one of the main culprits when it comes to slow web pages. WordPress 5.5 introduces image Lazy loading as a default feature in the WordPress core. This is a great optimization that stops images from loading in bulk when you open a web page and load them gradually instead as you scroll through. 

At SiteGround we have been big fans of Lazy Load for a long time. It is a feature we provide to our users through of SiteGround Optimizer plugin since 2018. Since we initially launched the Lazy Loading optimization we have been actively developing it adding support for iframes, videos, WooCommerce products, shortcodes, and much more. At this point, Lazy load options in the SiteGround Optimizer are more advanced than what is introduced in the WordPress core. That is why, for people that have Lazy load enabled through the SiteGround Optimizer, we will disable the native Lazy load. 

SEO Improvements

Search engine optimization is always evolving and writing unique, useful content that responds to people’s search intents is still the main differentiator between websites that rank well and those that rank poorly. 

However, on top of meaningful copywriting, you should also help your SEO standing by using some more technical tools, like XML Sitemaps for example. XML sitemaps make it easier for search engines to crawl all content elements included in your site and more likely for them to be indexed and shown in searches.

Starting with WordPress 5.5 you will be able to get an XML sitemap generated directly from your WordPress installation without relying on third-party plugins to achieve this.

This native option is great if you want a map that will list:

• Pages
• Posts
• Categories
• Tags
• Users

If you want a more complex sitemap, that includes images, news, and videos, you’ll still need to rely on a third party plugin but I think this is definitely a great option for website owners that don’t want to add plugins.

If you want to dig deeper into more practical SEO tips, check out our series of articles from guest author and SEO expert Rebecca Gill.

Gutenberg UI and functionality

The block editor got a major UI overhaul, as well. Eleven versions of the Gutenberg plugin have been merged into WordPress 5.5, bringing with them new functionality, speed improvements, and a changed UI. 

New Block Editor UI

You will immediately notice how the modal bar that appears when you click into a block is bigger, with more contrast and more compact. The options are still there, and more!

New Block Patterns

You will be able to add block patterns, which are combinations of blocks commonly used together. Text and media, two or three buttons in a row, headers with text, you name it. This is a great way to save time when you write your blog posts and an encouragement to be more creative with your content design.

Inline Image Editing

During WordCamp Europe 2020 Online, Matt Mullenweg, co-founder of WordPress.org and Matias Ventura, one of the leading engineers of the Gutenberg project, gave a demo of this new feature. You can now zoom, crop, and rotate images directly into the block image. You can see it for yourself in the video recording of the conversation and think about how this can also speed up and improve your editorial workflow. 

And much more

With eleven versions of Gutenberg going into WordPress 5.5 as you can imagine there are a lot more exciting features included. To see them all in detail, you can check out the release posts in the Core blog.

Accessibility Changes

No WordPress major release would be complete without some Accessibility improvements and 5.5 is no different. In this release a number of changes were introduced, with these being the most notable:

• The first iteration of alternative view modes for list tables
• Link-list widgets can now be converted to HTML5 navigation blocks.
• Primary buttons actually look disabled when they are disabled
• Meta boxes can now be moved with the keyboard.

Pro Tips For Developers

There are a lot of changes under the hood as well, which will be especially interesting for our developer customers. Don’t forget to check the Field Guide with all the Dev Notes related to major changes. I would also recommend you sign up for the Core blog: it’s very active and it’s the best way to keep up to date with changes that might affect your code. The more time you have to test changes, the better… don’t wait for release day to discover that something broke.

Over to you

Have you tried some of the things mentioned above, maybe through the Beta Tester plugin or the Gutenberg plugin? Even if you haven’t tried anything yet, what are you excited and curious to try?

[subscribe_cta]