One of the goals the WordPress project holds is to maintain compatibility with older plugins and themes that may not have been updated to work with the latest version, which means, well, not changing things that would break old plugins. Or adding new functions and leaving the older, redundant ones behind to maintain compatibility. It’s that methodology that led the developers to bake the infamous Magic Quotes functionality into WordPress itself, when it has been deprecated and removed from newer versions of PHP, so as to not break plugins expecting that behavior. (Which means plugin developers have to unescape strings before passing them to prepared statements, like they should be doing.)

That’s just one example of something I find vexing about WordPress, and not really indicative of the deeper structural issues that others complain about.

Sadly, the core developers would never agree to just dump everything and rewrite from scratch. It would break everyone’s plugins and themes, and it would take forever for them to be rewritten. That thought lead me to an idea, though. There’s a similar parallel to this: Python.

Version three of the Python language was released several years ago, but Python 2.6/2.7 are still used more widely than the latest and greatest. Why? Because scripts written for Python 2.x have to be adjusted to work with the newer version, which doesn’t retain backwards-compatibility. Projects like the Django framework are currently straddling the two versions, offering support for both through a compatibility layer, while slowly phasing out the older. Their plans are to slowly drop support for previous point-releases in the 2.x line while targeting Python 3.

A similar roadmap could be used with WordPress. Let’s say that WordPress 4.0 should be a completely rewritten, modern PHP application with a minimum requirement of PHP 5.3. The developer team would basically create a new dev branch and get to work, while still maintaining the 3.x branch for awhile. As the new version progresses, developers of plugins and themes could follow along and incrementally make changes to support any differences in the API. This would make it possible to do a full rewrite, and give the creators of actively developed plugins and themes a chance to catch up. (It’s high time to axe antique plugins designed for Magic Quotes and other PHP4 crimes against humanity.)

Once the 4.0 branch reaches completion, and the timeline for third-party developers to update their stuff nears its end, the 3.x branch is ended. Sites that depend on ye olde software could still delay updating until their dependencies are patched.

For another parallel, look to Laravel. They have the old Laravel 3, which people looking for a stable framework stick with, and the subject-to-change development branch, Laravel 4. The latter is significantly different, and will one day replace Laravel 3, but the older version isn’t being dumped until the shiny new version is 100% complete.

Personally, I think this issue is going to need to be addressed soon. WordPress’s reputation of being a “bloated mess of spaghetti code” is surely exaggerated, but certainly not unfounded. It needs work. Yes, it will cause incompatibilities, but that’s a part of the life cycle for any major software product. Sometimes you just need to cut the legacy software loose and begin anew, like Apple did with the OS 9 to OS X transition.

So for the tenth anniversary, the Zen Garden is open for business once more. I’ve thrown the codebase on Github, given the dusty copy a refresh, started the conversion of the site to HTML5, and brought all of the existing designs kicking and screaming into the modern age. The work isn’t done yet, but it’s a darn sight closer to how we would build it these days. If you see an area that needs help, consider sending a patch. (Here’s the current list of issues to resolve, for example.)

10 Years [Mezzoblue]

If you’re someone like me, who doesn’t purchase every version, waiting years between upgrades, this is a very unpleasant development. (I just moved from CS1 to CS5 during the past year, and the impetus behind that decision was the lack of support for legacy PowerPC software on newer versions of OS X. I upgraded to a newer MacBook Pro, and had to pick up a newer version of Photoshop to go with it.)

The move shouldn’t make huge difference if you already upgrade annually, as you’re basically paying the $600 upgrade fee perpetually, but it’s not great if you prefer to skip versions or buy secondhand.

Existing users for Creative Suite 3 or higher can get a reduced rate of $30/month for their first year, but will have to pay full price thereafter.

For example, if you visit this URL, you’ll get a JSON file of results for Harry Potter films:

http://sg.media-imdb.com/suggests/h/harry.json

The “h” directory means the query starts with an “h,” as they group their result sets alphabetically, and the “harry” part is what was typed into the search box. So if you wanted results that would match Doctor Who, you could use /d/doct.json. (Spaces are replaced with underscores.)

They only seem to have result sets for 4-5 character inputs, though. So you can query “ince” but not “inception.” The latter will result in an error. I guess most searches common enough to be matched in the suggestion box are covered within that limitation.

It’s a clever implementation, and it has to save a lot of computing power on a site that large, in addition to being fast.

(Note that this is not a public API, and IMDB/Amazon probably wouldn’t be happy about you scraping it or anything like that. But it’s a nice thing to learn from.)

It’s important to note that this is not a WordPress security flaw, but rather an attempt to systematically guess passwords.

The attacks consist of simple POST requests to wp-login.php with a supplied username of admin and one of many simple, insecure passwords. I’ve noticed plenty in my logs, including rainydays, sophie1, and wordpress. The requests come from a rotation of IP addresses in the botnet, making it difficult to block them outright.

It’s easy enough to protect yourself from the attacks, providing you follow some simple best practices.

1. Get Rid of the Admin User

Historically, every WordPress installation would come with an administrative user named admin, which was created during the setup process. In more recent versions, the setup screen prompts you to choose your own username instead of providing a default. Check the Users screen in your WordPress backend to see if a user named admin exists. If it does, you should replace it with a profile that has a unique name, ensuring that the new account has administrative privileges.

Having a user account with that default name is a bad idea, because numerous attacks over the years have operated under the assumption that the operators of many WordPress sites will have been too lazy to change it. The current attack only tries passwords for a user named admin, as well, so ensuring that such a user does not exist will go a long way toward protecting your site.

2. Set a Strong Password

What’s the common theme among these passwords?

• sophie1
• rainydays
• roberts
• online
• onions

They’re all incredibly simple and insecure, and they’re all ones that were tried right here on Webmaster-Source recently. Obviously you want to avoid passwords like those if you want to avoid being compromised.

For a basic, reasonably strong password, your password should:

• Be at least eight characters long
• Have a mixture of upper and lower case letters
• Contain numbers and non-alphanumeric symbols

An easy way to create something secure and memorable is to pick a phrase that means something to you and use the first letter of each word, mixing up the case and adding some numbers and symbols. For example, “The Wheel of Time turns and Ages come and pass” would become TWoTtaAc&p13. Complex, yet still possible to remember.

Or you could go with the XKCD method and pick four random, unrelated words and use them as your passphrase. (e.g. “double pizza kitten book.”) As the comic explains, such a password can actually be more secure against a brute-force attack, and is far easier to remember than a conventional password.

3. Block the Bots

Install a plugin like Bad Behavior (which will also help cut down on spam comments) or Limit Login Attempts. Both plugins attempt to hinder bot activity, though through different means. Bad Behavior detects suspicious requests and blocks them, optionally using the Project Honeypot database to improve its effectiveness. Limit Login Attempts will block IP addresses if they continually make incorrect login attempts.

4. CloudFlare

CloudFlare is an interesting service that speeds up your site and mitigates security threats by sitting between the user and your server. You update your domain to point to their servers, and they act similarly to a CDN, caching your site and analyzing the incoming traffic. If you’re running off a cheap shared hosting plan, it could make a significant improvement to your loading speed. I don’t use their services personally, but they’ve been instrumental in mitigating DDoS attacks and traffic spikes for some high-profile sites, and they’re on top of the current WordPress threat.

Fast forwarding a bit to spare you the gritty details, I went looking for benchmarks to see how DigitalOcean stacks up against the major competitors. In doing so, I found a new Interesting Thing.

ServerBear provides “a no hassle all-in-one UnixBench, IO, IOPS & Network performance test for Linux Servers,” and compiles an index of benchmarks for the different price points offered by dozens of web hosts. You can look up a service, such as DigitalOcean in this case, and view benchmarks for each plan purveyed by the host.

They also rank the hosts with a “BearScore” that represents the performance and specs vs. the monetary cost. Of course, there’s more to choosing a host than just raw performance. Reliability, knowledgeable staff, and quality support when something goes wrong are also very important. Unfortunately, those things are harder to quantify statistically.

Looking at the statistics, this up-and-coming DigitalOcean seems pretty good. Their $10/month offering seems to outperform my two-node VM from VPS.net (which is currently priced at $38/month for new customers…) in most areas, except for network speed. DigitalOcean, according to other sources as well, seems to have slower internet connectivity than Linode and VPS.net. But at a fraction of the price, it’s a very attractive option.

ServerBear: Performance Benchmarking For Linux Servers [serverbear.com]

…there is now native support for Audio and Video in core! There has been great support for embeds by way of WP_Embed and oEmbed providers for a while, but, if you wanted to play an MP3 from your Media Library, you had to install a plugin. Supporting audio and video in core gives bands, podcasters, vloggers, et al the ability to easily and beautifully expresses themselves through sounds and moving pictures without using an external service.

This should go nicely with the coming changes to Post Formats—unless the plans have change, a UI based on the one by Crowd Favorite is going to be a part of the WordPress core, hopefully making post formats actually useful. (I’ve been using the Crowd Favorite plugin on my personal blog for awhile now, and it’s great.)

Another part I find interesting is the addition of embed handlers for common media files. You will be able to paste an URL to an AAC/MP3/etc. into a post and it will be seamlessly replaced by a media player, just like how oEmbed works.

Audio / Video support in Core [Make WordPress]

It features a chapter on logically marking up page structure with the new semantic tags (header, nav, section, article, etc.), which explains the contexts they should be used in with a hands-on example of restructuring a blog without excessive divs. A lot of online tutorials make the error of suggesting the aside element for a blog sidebar, which the book helpfully points out as wrong. The section element is the proper tag for the job, as it denotes an arbitrary section of the page, whereas aside is for broken-out sections of your article content, such as pullquotes or diagrams.

From there the author moves on to some CSS3 tricks using newly-added selectors. He shows some simple methods to add zebra-striping to tables with pseudo-classes and add visible URLs to links via a print stylesheet with :after. There’s a brief section demonstrating media queries, as well some on the new JavaScript APIs—localStorage and history pushState, for example. There’s even a bit on using cache manifests to set up offline access.

Oh, and the deprecations. HTML5 deprecates a good many tags and attributes. There is a section listing those, as well as some modern alternatives, such as opening links in new windows without the deprecated target attribute. It can be done cleanly and semantically by using JavaScript, without impacting the user’s ability to middle-click a link and open a new tab…which far too many sites still do today. If you do that, you need to read this book just for that reason.

Amazon, however, uses a more advanced trick, which cleverly solves the problem while enabling the menu to be snappy and delay-free. They track the cursor movement to determine the user’s intent. If it’s moving diagonally toward the submenu, the menu stays open. If it’s moving down the list, the submenu instantly changes. No delays making it seem sluggish, and no irritations from glitchy menus.

Ben Kamens, lead developer at Khan Academy, described this behavior in an interesting blog post and released a jQuery plugin that replicates it.

As it turns out, Apple has been using the same principle for their OS’s menus for a long time. At least since the early 1990s, perhaps earlier, though I’m not familiar enough with Apple’s history to pinpoint exactly when. It’s funny how often the wheel is reinvented…

Breaking down Amazon’s mega dropdown [Ben Kamens]