+44 0330 223 3428
Call Us
+44 0330 223 3428

Mark Jaquith: Tips for configuring WordPress environments

Mark Jaquith: Tips for configuring WordPress environments

Many WordPress hosts will give your site a “staging” environment. You can also use tools like Local by Flywheel, or MAMP Pro to run a local “dev” version of your site. These are great ways of testing code changes, playing with new plugins, or making theme tweaks, without risking breaking your live “production” site.

Here is my advice for working with different WordPress environments.

Handling Credentials

The live (“production”) version of your site should be opt-in. That is, your site’s Git repo should not store production credentials in wp-config.php. You don’t want something to happen like when this developer accidentally connected to the production database and destroyed all the company data on his first day.

Instead of keeping database credentials in wp-config.php, have wp-config.php look for a local-config.php file. Replace the section that defines the database credentials with something like this:

if ( file_exists( __DIR__ . '/local-config.php' ) ) {
    include( __DIR__ . '/local-config.php' );
} else {
    die( 'local-config.php not found' );
}

Make sure you add local-config.php to your .gitignore so that no one commits their local version to the repo.

On production, you’ll create a local-config.php with production credentials. On staging or development environments, you’ll create a local-config.php with the credentials for those environments.

Production is a Choice

Right after the section that calls out local-config.php, put something like this:

if ( ! defined( 'WP_ENVIRONMENT' ) ) {
    define( 'WP_ENVIRONMENT', 'development' );
}

The idea here is that there will always be a WP_ENVIRONMENT constant available to you that tells you what kind of environment your site is being run in. In production, you will put this in local-config.php along with the database credentials:

define( 'WP_ENVIRONMENT', 'production' );

Now, in your theme, or your custom plugins, or other code, you can do things like this:

if ( 'production' === WP_ENVIRONMENT ) {
    add_filter( 'option_gravityformsaddon_gravityformsstripe_settings', function( $stripe_settings ) {
        $stripe_settings['api_mode'] = 'live';
        return $stripe_settings;
    });
} else {
    add_filter( 'option_gravityformsaddon_gravityformsstripe_settings', function( $stripe_settings ) {
        $stripe_settings['api_mode'] = 'test';
        return $stripe_settings;
    });
}

This bit of code is for the Easy Digital Downloads Stripe gateway plugin. It makes sure that on the production environment, the payment gateway is always in live mode, and the anywhere else, it is always in test mode. This protects against two very bad situations: connecting to live services from a test environment (which could result in customers being charged for test transactions) and connecting to test services from a live environment (which could prevent customers from purchasing products on your site).

You can also use this pattern to do things like hide Google Analytics on your test sites, or make sure debug plugins are only active on development sites (more on that, in a future post!)

Don’t rely on complicated procedures (“step 34: make sure you go into the Stripe settings and switch the site to test mode on your local test site”) — make these things explicit in code. Make it impossible to screw it up, and working on your sites will become faster and less stressful.


Do you need WordPress services?

Mark runs Covered Web Services which specializes in custom WordPress solutions with focuses on security, speed optimization, plugin development and customization, and complex migrations.

Please reach out to start a conversation!

[contact-form]

Source: WordPress

Tagged

Mark Jaquith: Simple WordPress deploys using Git

Mark Jaquith: Simple WordPress deploys using Git

A few weeks back, Clifton Griffin asked me a question about deploying WordPress sites:

I do not use Capistrano for deployments anymore, for one simple reason: it was massive overkill for most of the sites I manage, and maintaining it was not worth the benefit.

My current deployment system for WordPress sites is simple: I use Git.

I’m already using Git for version control of the site’s code, so using Git for deployments is not that much more work. There are a few days to do this, but the simplest way is to just make your site root a Git checkout of your site files.

Then, if your server has read-access to your Git remote, you can run some Git commands to sync everything. Here are your options:

  1. git pull — Simple, but might fail if someone naughty has made code modifications on the server.
  2. git fetch && git reset –hard origin/master — The hard reset method will wipe any local modifications that someone has mistakenly made.

But wait. Before you implement this, it is very important that you ensure that your server’s .git directory is not readable, as it might be able to leak sensitive information about your site’s code. How you do this will depend on what web server you’re running. In Nginx, I do the following:

location ~ /.(ht[a-z]+|git|svn) {
deny all;
}

In Apache, you could put the following in your .htaccess file:

RedirectMatch 404 /.git

SSHing into your server every time is tedious, so let’s script that:

#!/bin/bash
ssh example.com 'cd /srv/www/example.com && git pull'

Save that to deploy.sh in your Git repo, run chmod +x deploy.sh, and commit it to the repo. Now when you’re ready to deploy the site, just type ./deploy.sh and the public site will pull down the latest changes from your main Git remote.

Bonus points if you make deploy.sh take an optional commit hash, so you can also use this tool to roll back to a previous hash, in case a commit goes wrong.

This method has served me well, for years, and has required no maintenance.

What methods are you using for WordPress code deploys?


Do you need WordPress services?

Mark runs Covered Web Services which specializes in custom WordPress solutions with focuses on security, speed optimization, plugin development and customization, and complex migrations.

Please reach out to start a conversation!

[contact-form]

Source: WordPress

Tagged

Mark Jaquith: How I fixed Yoast SEO sitemaps on a large WordPress site

Mark Jaquith: How I fixed Yoast SEO sitemaps on a large WordPress site

One of my Covered Web Services clients recently came to me with a problem: Yoast SEO sitemaps were broken on their largest, highest-traffic WordPress site. Yoast SEO breaks your sitemap up into chunks. On this site, the individual chunks were loading, but the sitemap index (its “table of contents”) would not load, and was giving a timeout error. This prevented search engines from finding the individual sitemap chunks.

Sitemaps are really helpful for providing information to search engines about the content on your site, so fixing this issue was a high priority to the client! They were frustrated, and confused, because this was working just fine on their other sites.

Given that this site has over a decade of content, I figured that Yoast SEO’s dynamic generation of the sitemap was simply taking too long, and the server was giving up.

So I increased the site’s various timeout settings to 120 seconds.

No good.

I increased the timeout settings to 300 seconds. Five whole minutes!

Still no good.

This illustrates one of the problems that WordPress sites can face when they accumulate a lot of content: dynamic processes start to take longer. A process that takes a reasonable 5 seconds with 5,000 posts might take 100 seconds with 500,000 posts. I could have eventually made the Yoast SEO sitemap index work if I increased the timeout high enough, but that wouldn’t have been a good solution.

  1. It would have meant increasing the timeout settings irresponsibly high, leaving the server potentially open to abuse.
  2. Even though it is search engines, not people, who are requesting the sitemap, it is unreasonable to expect them to wait over 5 minutes for it to load. They’re likely to give up. They might even penalize the site in their rankings for being slow.

I needed the sitemap to be reliably generated without making the search engines wait.

When something intensive needs to happen reliably on a site, look to the command line.

The Solution

Yoast SEO doesn’t have WP-CLI (WordPress command line interface) commands, but that doesn’t matter — you can just use wp eval to run arbitrary WordPress PHP code.

After a little digging through the Yoast SEO code, I determined that this WP-CLI command would output the index sitemap:

wp eval '
$sm = new WPSEO_Sitemaps;
$sm->build_root_map();
$sm->output();
'

That took a good while to run on the command line, but that doesn’t matter, because I just set a cron job to run it once a day and save its output to a static file.

0 3 * * * cd /srv/www/example.com && /usr/local/bin/wp eval '$sm = new WPSEO_Sitemaps;$sm->build_root_map();$sm->output();' > /srv/www/example.com/wp-content/uploads/sitemap_index.xml

The final step that was needed was to modify a rewrite in the site’s Nginx config that would make the /sitemap_index.xml path point to the cron-created static file, instead of resolving to Yoast SEO’s dynamic generation URL.

location ~ ([^/]*)sitemap(.*).x(m|s)l$ {
    rewrite ^/sitemap.xml$ /sitemap_index.xml permanent;
    rewrite ^/([a-z]+)?-?sitemap.xsl$ /index.php?xsl=$1 last;
    rewrite ^/sitemap_index.xml$ /wp-content/uploads/sitemap_index.xml last;
    rewrite ^/([^/]+?)-sitemap([0-9]+)?.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;
}

Now the sitemap index loads instantly (because it’s a static file), and is kept up-to-date with a reliable background process. The client is happy that they didn’t have to switch SEO plugins or install a separate sitemap plugin. Everything just works, thanks to a little bit of command line magic.

What other WordPress processes would benefit from this kind of approach?


Do you need WordPress services?

Mark runs Covered Web Services which specializes in custom WordPress solutions with focuses on security, speed optimization, plugin development and customization, and complex migrations.

Please reach out to start a conversation!

[contact-form]

Source: WordPress

Tagged