Following on from yesterdays post – Adding HTTP Authentication to a WordPress site, I’ve put together a couple examples of how WordPress filters can be used to change the credentials and environments that can be set for authentication.
A quick way to set variables for testing, or in an environment such as local development, where it may be difficult, impossible or simply impractical to set environment variables for use here is to add them to your
// Set the environment you're in
$_SERVER['environment' ] = 'testing';
// Set the usernames / passwords that are valid
// Note the format is username:password - multiple users can be added by comma separating (no spaces)
// In this example, "demo" is the username, "user" is the password
$_SERVER['http_authentication_credentials' ] = 'demo:user,other:user';
// Set the restricted environments, these should be comma separated (no spaces)
$_SERVER['http_authentication_environments' ] = 'testing,development';
Continue reading Filtering the environments and credentials in the WP Basic HTTP Authentication plugin
When you’re working on multiple environments, particularly when you have a publicly accessible testing or staging environment, often you need to keep these environments protected.
One option in WordPress is to restrict access to users who aren’t logged in to WordPress; i.e. make them login first. But that makes it hard to test the site for users who aren’t logged in – for example, how does your custom login page look and does it work?
Another option is restricting IP’s to only a handful you need. But IP’s change, unless you opt for a static one. And even when this is an option for you and your development team, when you need to demo the site to a client, it can make life rather difficult.
My preferred option is Basic HTTP Authentication; it’s simple and effective and there are several ways to set this up.
If you’re using Apache, you could use your .htaccess file – but this can lead to complications when the same codebase (inc. the .htaccess file) needs to be pushed to the live environment (you’d need to set the .htaccess file to only trigger the HTTP Authentication where certain conditions are / are not met); or if you’re using Nginx configuration you’d add this to the testing / staging environment configurations – much more straight forward to keep control over things.
However, the Apache and Nginx options have one crucial drawback.. updating user credentials can be cumbersome and usually requires a developer to make changes – not something your typical client would be able to do.
Sometimes, there are times where you only have control of the codebase, but not the infrastructure. Client hosting and some platform as a service (PAAS) offerings limit what you can do. For example, a provider using Nginx doesn’t give you an option directly to add this, the better ones tend to though.
Continue reading Adding HTTP Authentication to a WordPress site
It’s a common mistake to make…
You’re working on some code and after making changes realise you’re working on the wrong Git branch…
More often than not, it’s a quick change to the right branch, otherwise you might have to unpick changes before you can do anything else which can be a time consuming and difficult exercise.
Continue reading Display your current Git branch in the admin bar
I’ve worked with some large multisite installs; one common issue I run into is identifying the ID for the site I’m looking at.
There are a couple of ways to lookup the ID of the current site:
- Go to Network Admin and look for the site you’re on
- Look in the
wp_blogs table and search for the URL for the site you’re on
Both of these methods work, but take time and are clunky and take a little time to complete.
Continue reading WordPress Multisite: Adding the current site ID to the admin bar
There are times where you have a multisite and need to have a plugin active on all but one (or a couple) of sites. One option here would be to activate the plugin on all the sites except the one that you need; but depending on the number of sites in the network this could take quite a while.
An alternative is to network activate the plugin, and specifically disable it on the site(s) that we don’t need it on. This can be achieved by hooking into the site_option_active_sitewide_plugins filter and removing the plugin(s) for the site(s) in question.
Continue reading WordPress Multisite: Disabling a network active plugin on a specific site