What I wanted was some way of mapping a file hash to a colour, or something strongly visual. Which is when it occurred to me; Gravatar could do this!

So I pretended all my filehashes were the local portion of email addresses, e.g. dbe0256fe35b88ebd4e4e433604b7487@example.com, and Gravatar auto-generates lovely identicon images for each, and there’s my visual differentiation. Here’s what I ended up with:

The Gravatar identicon API is really nice and easy to use; you just add an HTML IMG tag to the page and craft a special URL. Here’s an example:

<img alt="" src="http://www.gravatar.com/avatar/<?php echo md5( "{$hash}@example.com" );" />?d=identicon&s=30" class="file-identicon" />

The d URL parameter specifies identicon, as you can see, and the s parameter specifies a size of 30 pixels square.

After a few weeks of getting increasingly annoyed with Apple Mail, the problem, as usual, turned out to be elsewhere. Both the old and the new email addresses are part of separate Google Apps setups. When I configured my mail accounts in Apple Mail, I hadn’t been careful when choosing my Outgoing Mail server… both of them were set to the old email account, and Google was silently switching my sender address inside the outgoing mail server.

To fix this, go to: Preferences > Accounts and then pick an account. In the drop down for Outgoing Mail Server (SMTP) choose Edit SMTP Server List…. Make sure that all your SMTP servers are named clearly and have the right credentials in them, you should have one SMTP for each of your Google Apps accounts. Then Click OK to close this dialog. You are now back on the Accounts preferences screen, now make sure the right outgoing server is selected in each of your accounts.

The red light indicates a fault, which is why I’ve finally confronted my inability to remove it (hopefully your smoke alarm fault-free).

I’ve found the Kidde instructions on this to be infuriatingly vague on how you actually detach the unit from the base, so as I had to go through a lot of swearing to work it out, I figured some other people might have the same problem. Why are instruction manuals often so badly written?

The side of the alarm has the arrows to twist clockwise for “off” and anti-clockwise for “on”, but there is a small lug which prevents the unit from twisting. Here’s the lug:

Use a small screwdriver, or other poking device, to push this lug towards the base of the smoke alarm, like so, and you will be able to twist the unit free of the base:

The unit will still be attached to the base by the power plug. The plug has two catches on either site, like this, squeeze them together:

You can see the catches in this photo:

The end. Remember to only remove your smoke alarms temporarily, and refit them as soon as possible!

(N.B: I believe this alarm is discontinued by Kidde.)

We’ve recently had a couple of projects hosted on WPEngine where we need to have a staging site protected by Basic Authentication so only authorised users can access it. Normally I would configure Basic Authentication in the Apache VirtualHost, but on WP Engine (for example) they handle all the server configuration for us, meaning we don’t have access to the Apache configuration. WPEngine also provide a Git push to deploy facility, which we tend to take advantage of because Version Control Rools, OK? Because all the web files are within Git version control, we are using the same .htaccess file for the developer, staging and live sites. (We could Git ignore the .htacess file, but I prefer to version control more, rather than less.)

The approach we’ve taken is to put the code into the .htaccess file and to detect the domain of the staging site, and require them to enter the Basic Authentication username and password before proceeding. Let’s look at both stages of that process.

First we need to detect the domain we want to require authentication for, we do this using the SetEnvIf directive from Apache’s mod_setenvif module to examine the Host using a regex. If the Host matches the regex, then we set an Apache Environment Variable, which acts as a flag for a later conditional check. Here’s that directive:

# Detect the domain host and set a variable telling us to use auth
SetEnvIf Host staging.wpengine.com$ CFTP_USE_AUTH

Now we’ve set the flag we can check for it, using mod_access_compat, and issue a Deny Directive for all visitors with the Environment Variable flag set. Because we have initially set the Order to deny,allow, this Deny means nobody with this Environment Variable set is allowed to visit the site… we’ll take care of that later down the code. Here’s the conditional Deny directive:

# Detect the variable telling us to use auth and deny
Deny from env=CFTP_USE_AUTH

The next line uses the Satisfy directive to allow any visitors which pass one or other of the access requirements; in this case either they do not have the CFTP_USE_AUTH Environment Variable set (because the host does not match), or they have entered valid authentication details.

Satisfy any

Then there’s the Basic Authentication rules, which are fairly standard:

# Basic authentication
AuthType Basic
AuthName "Nothing to see here. Move along, please"
Require valid-user

…until you get the the location of the AuthUserFile, which is only worthy of mention in that you need to provide a path to it. I decided to generate the .htpasswd file on my development server and keep it in the document root, which is under version control, because Version Control Rools, OK? We do some jiggery pokery later to ensure that nobody can view the .htpasswd file over HTTP or HTTPS.

# N.B. This path will be specific to your server setup
AuthUserFile /the/path/to/the/document/root/.htpasswd

We use a Files directive to Deny access to any files called .htpasswd to anyone and everyone (note the Satisfy All, that’s important):

# Don't allow the .htpassword file to be shown to web users
<Files .htpasswd>
   Order allow,deny
   Deny from all
   Satisfy All 
</Files> 

The complete rules are below…

Order deny,allow

# Detect the domain host and set a variable telling us to use auth
SetEnvIf Host staging.wpengine.com$ CFTP_USE_AUTH

# Detect the variable telling us to use auth and deny
Deny from env=CFTP_USE_AUTH

Satisfy any

# Basic authentication
AuthType Basic
AuthName "Nothing to see here. Move along, please"
Require valid-user

# N.B. This path will be specific to your server setup
AuthUserFile /the/path/to/the/document/root/.htpasswd

# Don't allow the .htpassword file to be shown to web users
<Files .htpasswd>
   Order allow,deny
   Deny from all
   Satisfy All 
</Files> 

Just one more thing… what if you want to allow unrestricted access to some URLs in the site? To accomplish this you can identify them with more SetEnvIf directives, and set a different flag which allows the authentication to be bypassed. Here’s a set of rules which shows this in action:

Order deny,allow

# Detect the domain host and set a variable telling us to use auth
SetEnvIf Host staging.wpengine.com$ CFTP_USE_AUTH

# Detect some link structure and set a bypass variable
SetEnvIf Request_URI ^/whatever/[0-9]+/?$ CFTP_BYPASS_AUTH

# Detect the variable telling us to use auth and deny
Deny from env=CFTP_USE_AUTH

# Allow the redirects we've detected
Allow from env=CFTP_BYPASS_AUTH

Satisfy any

# Basic authentication
AuthType Basic
AuthName "Nothing to see here. Move along, please"
Require valid-user

# N.B. This path will be specific to your server setup
AuthUserFile /the/path/to/the/document/root/.htpasswd

# Don't allow the .htpassword file to be shown to web users
<Files .htpasswd>
   Order allow,deny
   Deny from all
   Satisfy All 
</Files> 

What is Varnish caching? Well, “Varnish is a reverse proxy cache” …but what is a reverse proxy cache, you say? A reverse proxy cache sits between your website and the broader internet (where all the people and things that want to see your site are) and, according to a set of rules, caches responses somehow and serves them back super quick to the requests for URLs at your site. So your site generates a response, which might take some time due to database queries, requests to Twitter for the latest tweets, etc, etc, then the reverse proxy cache (Varnish, in this case) saves the response and returns it for requests without bothering the site to create the response from scratch… hey presto, much faster responses!

WP Engine have their Varnish configured to cache responses for 24 hours for non-200 responses. What are “non-200 responses”, you say? Every response to a request for a URL is assigned a response code, you can read them all over at the W3C (or you can read the much more amusing HTTP $tatu$ Rapper$). The main response codes we’re concerned with are 200 (“OK” – the request has succeeded) and 404 (“not found” – the requested resource has, errrr, not been found), there’s also various redirection codes 301 or 302.

The upshot of all this is that once a 404, 301 or 302 response is issued by a website on WP Engine, it remains in use for 24 hours unless something clears it deliberately. The major scenario of having a 404 response and then publishing something at that URL is covered, as you’d expect the cache gets automatically cleared, however there are the odd situations where I’ve needed to clear a cache for whatever reason (perhaps to replace a 404 with a redirect of some kind) and then I’ve been stuck staring at the 24 hour cached response and grinding my teeth.

Enter the WP Engine Cache Sniper plugin (actually I’ve called it “WPEngine Clear URL Cache”, which is quite a bit more boring). This plugin provides a simple “Clear URL Cache” link under the “Tools” menu in the admin area, here you can enter a URL and have the cache cleared on that URL. Problem solved.

Caveats: The plugin is specific to WP Engine, and won’t work on other services. If you try and install it on a non-WP Engine hosting service it will put a whinging notice throughout the admin, advising you to uninstall. If you try to use it on a non-WP Engine hosting service then it will kill a kitten, you may not see the kitten die and it may not be your kitten… but really, do you want that on your conscience? Oh and you might trigger an error in your site, who knows.

If you want to learn more about what’s going on, you can see the summaries posted on the day for the morning and the afternoon, and watch the “notes” category archive as the session notes are going up now.

Why do I want to do this? Well, pretty often the client is keen to see how some new, embargoed, content is going to fit together, whether that’s a group of new pages or a new masthead, etc. I don’t want just anyone guessing my staging site URL and wandering around getting information they shouldn’t!

The key, as is often the case, was in a Stack Overflow post. Let me walk you through the specifics:

# Detect the domain host and set an environment var for staging
SetEnvIf Host staging\.somewhere\.com$ TRS_IS_STAGING
Order deny,allow
# Detect the staging environment var
Deny from env=TRS_IS_STAGING
Satisfy any
AuthType Basic
AuthName "Nothing to see here. Move along, please"
# We rely on this rule only being applied on staging,
# as it will break everywhere else
AuthUserFile /nas/wp/www/staging/promotone/.htpasswd
Require valid-user

# Hide the htpasswd file
<Files .htpasswd>
	Order allow,deny
	Deny from all
	Satisfy All
</Files>

The first block of the file uses a simple regex to check if the Host environment variable ends with staging.somewhere.com, and if it does it sets a further environment variable called TRS_IS_STAGING. The config is then set to Deny any request where the TRS_IS_STAGING environment variable is set. Because Satisfy any is present, Apache will then attempt to use the Basic Authentication set in the next few lines with AuthType, AuthName, AuthUserFile.

Note that the AuthUserFile directive needs a filepath which is either absolute or relative to the ServerRoot, either way it’s pretty specific to the server setup. That’s fine in this case, but you would need to differentiate between each server setup and the path for it if you wanted to add authentication to more than one server.

Lastly, I’m hiding the .htpasswd; it’s not ideal that it’s web available (i.e. in the DocumentRoot) but that’s the limitations of the hosting environment I’m dealing with.

“Cooperate on a technical level and compete on a business level.”
Jeffrey McGuire, Acquia

Seen on a slide at PHPNW12, I like this summary of how companies interrelate in open source.

So, can logging be cool?

Why log? Patterns and trends, information after the fact.

tail -f FTW

About the Skybet application log:

• Signposts everything when it happens. Good way to learn the path through the layers.
• Good visible errors.
• Logs the start and end of request, including memory consumed, so you can spot waiting and memory trends.

Moving on to methods of logging

error_log. (Can be sent to stdout for situations when running in the CLI):
Pros: native
Cons: ini can be overwritten

Various logging libraries, ZendLog and monolog. Prefer: Monolog. Well maintained, good feature set.

Fingers crossed handler: logs to memory, but only to disk if condition X occurs.

Allows different levels of logging: error, notice, info, etc.
Different log writers: file, email, firebug, etc, etc, can write your own.

Your application logger

Handy to set a unique request ID. Can spot an issue, and grep the log for all activity on that request.

Logger is passed MLogger on construction.

Different logs: application log and security log. Different information logged (cleary).

Event logging

Things which happen (in your system) get logged.

Graphite + statsd – Statsd has buckets which periodically get sent to Graphite. Your application logger can have a method to increment statsd, statsd sometimes sends to Graphite and graphs appear magically.

Can get more efficient than sending data from your app.

Strategy

• Choose a consistent logging style
• Centrally deal with formatting
• Consistency, consistency, consistency

Log:

• Request start and end
• Transitions between layers
• DB queries
• Biz events (separate log)
• Message queue activity
• Errors and notices from PHP

Avoid leaving crazy debug lines in that others have to filter out. Make sure content is greppable.

Log aggregation: rsyslog, logstash.net (really handy, can also send to statsd lots of inputs, filters, outputs).

Hosted: splunk, loggly, new relic.

The only question: Is an event based logger a good plan? Yes, avoids dependencies on classes.