Without further ado, I would like to introduce Solar, a theme I based upon the Solarized color palette. It includes stylesheets for both Solarized Dark and Solarized Light, since the colors are defined separately from the page structure. It’s responsive, all the way down to mobile size, and it’s built with link-blogging in mind.

You can view a demo of Solar here, and download it on GitHub. It’s licensed under the GPL, so feel free to fork it and go crazy.

History lesson aside, here’s what DigitalOcean has to offer: affordable VPS hosting with plenty of memory and fast solid-state drives. Their offerings are comparable to those of the venerable Linode, though cheaper. (The difference comes down to which is more important to you: CPU or price.)

Their cheapest plan gets you a VM with 512MB of RAM and 20GB of space for a mere five dollars per month (or $0.007/hour). That’s cheaper than a lot of shared hosting plans, for a speedy box with full root access. The plan I’m using is their $10/month option, which comes with one gigabyte of memory.

Backups and snapshots of VMs are priced reasonably, with backups costing 20% of the server’s price (e.g. $1 per month for a $5 per month server) and snapshots being $0.02 per gigabyte stored.

The service has been stable so far, and the one support ticket I opened was resolved in a timely manner. Performance-wise, there has been a definite improvement over my previous host. (It’s also nice having the server be in New York, which results in a much more favorable network latency from where I live.)

DigitalOcean has a freshly redesigned control panel, from which you can manage your servers, DNS, billing and other settings. It’s also the place where you can set up your API access if you want to manage things from a mobile app, command line utility, or even use a Vagrant provider.

I’ve been very happy with DigitalOcean since my big switch, and definitely recommend them if you’re in the market for a decent VPS provider. If you want to give them a try, here’s my affiliate link. If you enter the promo code SSDPOWER on the billing settings page, you’ll get $10 worth of free credit. You can spin up a VM, play around with it, and delete it when you’re done.

Need 960gs, Twitter Bootstrap, Backbone.js, TinyMCE or something else entirely? They probably have it. If they don’t, you can open a pull request on GitHub to add it!

And since it’s backed by CloudFlare, it should be reliable. They know what they’re doing.

CDNJS — The Missing CDN [CloudFlare]

git ls-files | xargs wc -l

It uses git ls-files to generate a list of files, which it then passes it to the wc command, which generates word and character count statistics (the “l” flag makes it count lines).

Obviously the line is a bit of a mouthful (handful?). So you can create an easier alias, like “gitlines” and put it in your .bashrc file.

alias gitlines="git ls-files | xargs wc -l"

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.