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.

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.

…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]

The process required to add the new uploader is a bit different, but not too much more difficult. I was able to adapt the old tutorial a little, so it shouldn’t be too hard to replace some code in an existing project and get the new uploader instead of the old.

For the sake of simplicity, let’s start with the same HTML snippet as in the old tutorial. This goes along with the rest of the HTML for your admin page, or wherever in the admin you’re trying to add an upload field.

<label for="upload_image">
	<input id="upload_image" type="text" size="36" name="ad_image" value="http://" /> 
	<input id="upload_image_button" class="button" type="button" value="Upload Image" />
	<br />Enter a URL or upload an image
</label>

Now we need to load up the necessary JavaScript files.

add_action('admin_enqueue_scripts', 'my_admin_scripts');

function my_admin_scripts() {
	if (isset($_GET['page']) && $_GET['page'] == 'my_plugin_page') {
		wp_enqueue_media();
		wp_register_script('my-admin-js', WP_PLUGIN_URL.'/my-plugin/my-admin.js', array('jquery'));
		wp_enqueue_script('my-admin-js');
	}
}

We bind the my_admin_scripts() function to the admin_enqueue_scripts hook, and enqueue both the media scripts and our own JavaScript file. Also, the scripts will only be loaded if the current page is equal to “my_plugin_page,” which you would of course replace with the slug your admin menu has.

Now for the complicated part: the script that hooks into the uploader. Continuing with the above example, it would be named my-admin.js.

jQuery(document).ready(function($){


	var custom_uploader;


	$('#upload_image_button').click(function(e) {

		e.preventDefault();

		//If the uploader object has already been created, reopen the dialog
		if (custom_uploader) {
			custom_uploader.open();
			return;
		}

		//Extend the wp.media object
		custom_uploader = wp.media.frames.file_frame = wp.media({
			title: 'Choose Image',
			button: {
				text: 'Choose Image'
			},
			multiple: false
		});

		//When a file is selected, grab the URL and set it as the text field's value
		custom_uploader.on('select', function() {
			attachment = custom_uploader.state().get('selection').first().toJSON();
			$('#upload_image').val(attachment.url);
		});

		//Open the uploader dialog
		custom_uploader.open();

	});


});

When the button is clicked, it creates a new instance of the wp.media object and configures it to only accept a single file, since the text field can only hold one file URL. Then it binds a function to the selection action, which gets the file attributes when an image is chosen and sets the #upload_image text field value to the file’s URL.

Providing everything went as expected, you should have a form field that will accept an arbitrary URL, or allow the user to upload one.

Frank is built atop the responsive Foundation grid framework, and features a layout customization tool that lets you adjust how the homepage is displayed.

Frank: A Free WordPress Theme Designed For Speed [Smashing Magazine]

Core Control is a plugin that lets you monitor and adjust several parts of WordPress for diagnostic and development purposes. It makes it easy to view registered WP-Cron events, and trigger them with a click. It can also force WordPress to check for ore, plugin or theme updates, log any HTTP requests WordPress makes to external servers and determine which filesystem access method WordPress is using.

I decided to try it out again now that it hit the big two-point-oh, and was surprised now only by the amount of functionality it offers, but by how many other plugins it can conceivably replace. The Publicize module, for instance, will automatically post links to new posts on Twitter, Facebook and other popular social networks, so you don’t need another plugin for that if you run Jetpack. I also found the Mobile Push Notifications and JSON API modules to be intriguing. The former sends push notifications to your iPhone/iPad when new comments are posted, and lets you jump right over to the WordPress iOS app to manage them, and the latter is primarily of interest to developers looking to integrate a WordPress blog into another web site or application. (Previously I used this plugin, but Jetpack looks roughly equivalent.)

The big new feature in this version is a free service called Photon, an “image acceleration and editing service” which acts as a CDN for your images. It mirrors images it finds in your posts (or ones a theme or plugin developer specifies via an API) on WordPress.com’s servers, which enables them to be served faster and takes load off your server. This would be excellent for blogs hosted on cheap shared hosting, especially if coupled with a static caching plugin like WP Super Cache or W3 Total Cache.

I like the new look, with its flat colors and additional negative space. It seems more current, as excessive gradients seem to be falling out of style in web design lately—just as browser support for them is starting to catch up. It’s definitely easier to find what you’re looking for on the new site, so the new navigational structure is a success.

The design looks great, but I find the switch to WooCommerce to be the most interesting. Not only is WooThemes “eating their own dog food,” but the fact that the largest and most known supplier of commercial WordPress themes is using it is good to know for anyone looking into e-commerce solutions.

We’ve re-designed. Everything. [WooThemes]

Lorelle VanFossen goes into considerable detail on the issue, with a few migration routes, including using custom menus.

Personally, I have mixed feelings about blogrolls. On on one hand, they’re a convenient way to recommend some of your favorite blogs in a persistent manner. Certainly good for a personal blog. On the other hand, they’re of more limited benefit for more topical sites. It’s probably a good thing that it’s being removed from the WordPress core, since blogrolls aren’t as popular as they were ten years ago.

If not, here’s a brief history lesson. In order to help newbies write functioning MySQL queries, they thought it would be a great idea to automatically escape input data with slashes, overwriting the $_POST, $_GET and $_REQUEST globals. So if someone submitted hello, I'm Steve through a form, it would be immediately converted to hello, I\'m Steve so the apostrophe wouldn’t cause issue if a naive user tried inserting it into a database.

But what if you weren’t going to dump the data into a MySQL database? Too bad, it’s now full of slashes and you have to use stripslashes() on the variable. Also, you could conceivably end up with something like hello, I\\\'m Steve if you try escaping the data yourself before inserting the data into a database. It was a massive headache, and the normal practice ended up being “check to see if magic quotes are enabled at the top of your script, and strip the slashes out if the feature is activated. Then handle database queries with prepared statements or by properly escaping the data.”

Fortunately, the PHP project eventually came to their senses and deprecated magic quotes, finally removing the feature entirely with the new PHP 5.4.

Now…back to WordPress.

I was investigating an issue with a plugin where extraneous slashes were appearing in strings processed by $wpdb->insert() when I found this gem in wp-includes/load.php:

/**
 * Add magic quotes to $_GET, $_POST, $_COOKIE, and $_SERVER.
 *
 * Also forces $_REQUEST to be $_GET + $_POST. If $_SERVER, $_COOKIE,
 * or $_ENV are needed, use those superglobals directly.
 *
 * @access private
 * @since 3.0.0
 */
function wp_magic_quotes() {
	// If already slashed, strip.
	if ( get_magic_quotes_gpc() ) {
	        $_GET    = stripslashes_deep( $_GET    );
	        $_POST   = stripslashes_deep( $_POST   );
	        $_COOKIE = stripslashes_deep( $_COOKIE );
	}

	// Escape with wpdb.
	$_GET    = add_magic_quotes( $_GET    );
	$_POST   = add_magic_quotes( $_POST   );
	$_COOKIE = add_magic_quotes( $_COOKIE );
	$_SERVER = add_magic_quotes( $_SERVER );

	// Force REQUEST to be GET + POST.
	$_REQUEST = array_merge( $_GET, $_POST );
}

It checks to see if the server has Magic Quotes enabled. But instead of stripping the slashes when the feature is active, which is the standard practice, it adds slashes when it’s disabled. If I were working at a desk when I saw that, I would have hit my head on it.

Purportedly, it’s for backwards-compatibility with older, poorly-coded themes and plugins. While I understand the predicament, it’s a backwards solution. It encourages poor development practices, and creates obstacles for those trying to do things properly.

I hope they end up phasing this out sometime, but for now, we’ll just have to make do with this solution:

$post = array_map('stripslashes_deep', $_POST);
$get = array_map('stripslashes_deep', $_GET);
$request = array_map('stripslashes_deep', $_REQUEST);