Fixing background “bleed” on elements that use CSS3 border-radius property

It’s kind of funny that I never encountered this problem before… it must just be extra-noticeable because of the colors on this particular website I’m working on. Anyway, I found that the nice buttons I was creating with CSS3 border-radius were displaying an ugly “bleed” of the background dark blue color beyond the edges of the white border. No good.

before

A little googling led to Mike Harding’s solution, a simple background-clip property in the CSS. (Yet another of the preponderance of new properties in CSS3 that I’m finding it harder and harder to keep up with.) If w3schools.com is to be believed, the vendor prefix is unnecessary. Let’s just go with this:

background-clip: padding-box;

Ah, that’s better!

after

How not to update a WordPress plugin

The meaning of this post’s title is twofold: 1) how, as a WordPress user, to avoid having a plugin show up in the built-in updater; and 2) how, as a developer, you probably should not approach releasing a major update to your plugin that is incompatible with earlier versions.

The scapegoat here is Elliot Condon’s excellent Advanced Custom Fields, which has become one of my essential go-to plugins for building highly customized WordPress websites for my clients. I don’t mean to pick on Elliot Condon. He’s clearly a tremendously talented developer and I have a ton of respect for his work and what it has allowed me to do in my work.

But I do feel that he handled the 4.0 release of Advanced Custom Fields poorly. I’m not sure the fault is really his, however, as it is just as much or more the fault of how the built-in updater in WordPress works. (Especially since at least some of the changes he made in version 4 were done solely to conform to changes in the official WordPress plugin requirements.)

Here’s the problem: WordPress has a central Plugin Directory that makes it easy to install and update approved plugins. Perhaps too easy. Because if an update of a plugin is made available, and it’s newer than the version you have installed, it appears as an option in the updater. Yes, there are links to information about the update, which you really should read before doing anything else, but it’s all too easy with a few clicks to just run the update and move on.

Most of the time, it just works. Which can be dangerous. Because users — even “experts” like me — come to assume it will always “just work.”

As it happens, the version 4.0 release of Advanced Custom Fields was made available while I was on a weeklong vacation out west with my family, with only my iPad (and SLP’s MacBook Air) along for the ride. And, based on my own recommendations, a client with a relatively newly-launched website went ahead and ran the update. This particular site is heavily dependent on ACF, and the update broke it.

The official ACF website offers a migration guide that makes it (somewhat) easy to convert your existing version 3 implementation to work with version 4. But it’s not a “click-it-and-you’re-done” kind of process. It takes time, and you need to know what you’re doing. Which is nothing like the general experience of using the built-in WordPress updater.

I was able to temporarily solve the problem for this website by rolling back to an earlier version (which required some hunting to locate, given the limited Internet access I had with hotel WiFi). Which leads to my first tip:

How to prevent a WordPress plugin from updating

How does WordPress know when a plugin has an update available? Well, it’s easy for it to check the Plugin Directory to see what the latest version of any given plugin is. But how does it know which version you have installed? Also easy. Each plugin’s main PHP file includes a comment block at the top, with information WordPress parses both to display in the Plugins area of the admin interface and for added functionality (e.g. knowing when there’s an update available). For Advanced Custom Fields, the comment block looks like this:

/*
Plugin Name: Advanced Custom Fields
Plugin URI: http://www.advancedcustomfields.com/
Description: Fully customise WordPress edit screens with powerful fields. Boasting a professional interface and a powerfull API, it’s a must have for any web developer working with WordPress. Field types include: Wysiwyg, text, textarea, image, file, select, checkbox, page link, post object, date picker, color picker, repeater, flexible content, gallery and more!
Version: 3.5.8.2
Author: Elliot Condon
Author URI: http://www.elliotcondon.com/
License: GPL
Copyright: Elliot Condon
*/

This is essentially a set of key/value pairs. Version is what WordPress reads to see which version you’re running, and compares it against the master version in the Plugin Directory to see if updates are available.

So how do you keep it from running the update? Simple: Change the version number to something higher. I like to prepend it with “999” so I still know what the “real” version number is that I’m running, like this: 999.3.5.8.2. This way the WordPress updater thinks the major version is “999”, which is almost certainly higher than whatever the real current version is.

Simply change this version number, save the PHP file on your server, and you’re done. The updater will never trigger for this plugin (as long as its real version number is less than 999). You may also want to update Description with an explanation of what you’ve done.

Bear in mind this is a temporary solution. You really should do whatever you need to do to get your site compatible with the latest version, then restore the original version number and let the updater do its magic.

How, as a developer, not to create this mess for your users

I have submitted a few, very simple, plugins and themes to the official WordPress repositories, so I have a bit of experience with this, but I’m no expert on the process. However, what is clear to me is that if you submit changes to a plugin as an update, the built-in updater will pick it up and make it available to any users who have an older version installed. This is dangerous. If your new version includes such radical changes as to make it incompatible with earlier versions, you have to assume that most users will not read your notes, and will believe they can just run the updater with no problems… especially if you’ve made a habit of releasing frequent incremental updates to the plugin in the past that “just worked.”

The only real solution I see to this is to submit the new, incompatible version to the Plugin Directory as an altogether new plugin, instead of an update to the existing plugin. The risk here is that you lose visibility. Your download count and ratings/reviews reset to zero, and anyone who’s using an older version may never know about the new version. So, it’s bad for marketing.

But an incompatible update breaking sites for unsuspecting users is bad for marketing too. It’s going to cause your ratings to take a hit, cause a lot of bad publicity, and turn off your loyal users. The migration is going to be work for them anyway; making them do it after they clean up a mess created when they unsuspectingly ran the update is even worse.

A few specifics as pertains to Advanced Custom Fields

Again, I don’t mean to pick on Elliot Condon for his work with Advanced Custom Fields. I will continue to be a loyal (and, yes, paid) user of this plugin. It’s brilliant. Nonetheless, it’s created a hassle for me this week. After returning from my trip, the first work-related thing I did was go through every client site that’s running ACF and apply my “version 999” trick so those clients won’t run the updater until I have a chance to migrate their sites to version 4.

The biggest challenge I had in rolling back was simply getting my hands on the old version. Sure, I had it on some of my other sites, but I access almost every client site via SSH/SFTP, and the hotel I was staying at had port 22 blocked. Luckily the site I needed to fix was one of the few I access via regular FTP, and port 21 was open. But I still needed to get a copy of version 3.x to reinstall on that client’s site.

As I found along the way, the WordPress Plugin Directory hides old versions under the “Developers” tab, where every previous version can be downloaded as a ZIP file or checked out with Subversion. Previous versions of ACF are available here.

Where’s the option to change the “uploads” path in WordPress 3.5?

Thanks for nothing, WordPress.

It’s not often that I complain about anything in WordPress, much less get genuinely angry about something I think is downright stupid, but today it happened.

I build a lot of WordPress sites for clients, and I frequently post them in a staging area on my server. Rather than having dozens of separate installations of WordPress filling up my server’s disk space, I set up a single installation (but with a separate database for each site), with some simple customizations to the wp-config.php file that tell it which database to use based on the domain name.

Please don’t bother to mention that I should “probably” be running WordPress-MU (or MultiSite or whatever they call it now). Ultimately these sites are going to be hosted elsewhere as standalone WordPress sites so I need to keep their databases separate.

One key to making this arrangement work nicely has always been the simple setting in WordPress that allows you to define a special directory for uploads, instead of dumping them all in the main uploads directory. By setting this to a subdirectory under wp-content/uploads named to match the site’s theme folder name, it was easy to keep everything separate.

It’s been a while since I’ve set up a new site on the staging server, at least since before I updated to WordPress 3.5. But I was doing one today, and I had to do a sanity check as I scoured the settings to try to find where in the hell you set the custom uploads path. I was sure it was under Settings → Media but I couldn’t find it there.

Because they took it out.

Yes, they took it out. Why? Well, apparently there’s a rational explanation, but frankly no explanation would satisfy me because it seems incredibly disruptive to take something like this out, even if it was a bad idea to implement it as it was in the first place.

Fortunately, there’s still a way to do it. You just can’t do it in the admin interface anymore; you need to edit the wp-config.php file directly to add a constant. No problem, I’m already doing that anyway.

Here’s what you need:

define('UPLOADS', '/your/custom/path/under/wordpress/root');

If you’re just putting your uploads into a subdirectory under the main uploads directory, like I am, it would look like this:

define('UPLOADS', '/wp-content/uploads/yourdirectory');

Just remember, if you’re doing this because you’re running multiple sites from a single installation like I am, this constant should be set in the same conditional where you’re setting which database the site should use.

Easy. Not as easy as it was, nor as easy as I think it should be, but…

Microsoft Word’s formatting garbage, quantified

Anyone who’s spent any amount of time working on the web dreads it: content delivered in Microsoft Word format. Word adds tons of formatting garbage that results in bloated files and messes up the presentation when content gets brought into HTML.

When Microsoft released Office 2007, they touted switching to an XML-based document format for all of the apps. But all XML is not created equal.

Case in point: I am currently working on a project that is going to involve receiving content for a number of web pages in a tabular form, either in Word or Excel format. A spreadsheet, essentially (if not technically), with each page represented by a row, and its text content in a cell. I will be writing a PHP script to parse the spreadsheet data and generate a set of HTML files with the content loaded in them.

I’m currently trying to determine if Word or Excel would be the better format to receive the content in, which involves opening up .xlsx and .docx files in BBEdit and looking at the raw data stored within them. I’ve managed to identify the embedded XML files in each that hold the actual content. These files store the same actual text content, but their XML schemas vary based on the needs of Word and Excel.

So… how do they match up? The XML file I pulled out of Excel is 14 KB. The one from Word is 202 KB. For the mathematically inclined amongst you, that’s a little more than 14 times larger. Yes… another (perhaps more hyperbolic) way you could say it is that the Word document is exponentially larger.

That’s just ridiculous.

What makes up the difference? Well, the Excel file’s XML is nothing but basic tags. There are no attributes on any of the tags, as far as I can tell. It’s pure semantic structure. The Word XML, on the other hand, is almost nothing but attributes. And there’s nothing smart about them either. Most of them are assigning fonts to the text. The same font names, over and over and over again throughout the file.

That’s… beyond ridiculous.

Light, pollution, memory

Light pollution

I remember the first time I ever observed light pollution. I didn’t know what it was, and I’m not sure it even had a name back then.

It was 1993. I was in college, and I was home for Easter. In fact it was early Easter morning. My uncle was staying with us, in my room, which was in the process of becoming the guest room. He always stayed in my room when he stayed with us. Eventually I would stay in that room, as a guest room, not my room, once I was no longer a resident of the house, but a guest.

At the time, though, I was not yet a guest, though no longer quite a resident. Nonetheless, he was visiting, so he got my room and I was relegated to the couch in the family room. The family room, which had been added on in 1987, when I was 13, had two skylights. One was directly above the couch, so when I was lying on the couch I could look directly up at the sky.

When I was growing up, cities, at least the small town in which I grew up (which I always thought of as a city, despite its modest population of 26,210 — which was no longer the population, but had been the population in the 1970 census, and the city could not yet bring itself to acknowledge the loss of over 10% of its population in the subsequent decades, so it still appeared on the signs as you drove into town) had not yet switched over to sodium-based street lights. However this particular small town/city had made the switch in the brief time since I had gone off to college at an even smaller town — one small enough that even I could make no pretense as to its being a “city.”

I awoke in the middle of the night. Technically, the early morning, Easter morning. It was overcast, and as I now know well, in a city illuminated by sodium streetlights on an overcast night, it is never truly dark, never truly nighttime. Instead, the best you get is an eerie orange twilight, which is what I observed for the first time in my life, that early Easter morning in 1993, 20 years ago.

It was perhaps 2 AM, and as I awoke, then arose, and walked to the kitchen to get a better view, I beheld the city aglow in an unnatural orange luminescence, and… well… it freaked the shit out of me. I had never seen anything like it, and I didn’t understand what could be causing it. Being Easter morning, and being highly impressionable, especially to my own half-lucid, half-dreamlike fantasies, I was sure Armageddon, or… something… was nigh.

Of course, it was not. And eventually I made the connection between the reference to sodium lights I’d heard on Sting’s The Soul Cages album with the eerie orange light, which has since become commonplace in my mostly urban adult life, where I am usually far too busy or distracted or just simply tired to bother to look up into the sky at night and think the kinds of existential, philosophical, cosmic, spiritual, infinite thoughts I used to dwell on so much between the ages of 5 and 22.

But tonight, for a brief moment, I lingered at my back door in south Minneapolis, with a glass of scotch in one hand and my iPhone in the other. On that late night/early Easter morning 20 years ago, I’m not sure which of the two would have seemed more out-of-place in my hands. Surely both would be just as out-of-place as apocalyptic paranoia in my 2013 brain. But still, the connection to that moment half a lifetime ago was there, and I was transported back to a place where I can stare into the sky at night, silently, and wonder.