For several months now I have watched the discussion on the Wordpress.org support forums – especially about the much maligned admin back-end changes, run a security "back-porting" experiment to keep my heavily customized version of 2.3.3 viable, and put 2.5.x through its paces to see what it does and doesn’t do.

All along, I’ve been taking copious screen-caps to help build my case. And at least for me, the verdict is in: Wordpress 2.5.x has been largely a mistake. Here’s why:

1. The layout and design changes to the admin backend have done preciously little to solve the problem of wasted vertical screen "real-estate", even though a supposedly top-notch design firm was hired in the redesign. Not sure what they were thinking, but even though the menus were made a little more sane, I still find no real consistency in what was done.
2. Several things that actually worked well for people (and especially power-users) were taken away for no apparent reason, with sometimes additional complications being caused. Yes, I’m talking about the "Widgets" screen, as well as the needless moving around of the "post controls" away from the right hand of the write screen (wasting, surprise, surprise, even more vertical screen real-estate).
3. It doesn’t truly address several of the long-standing issues with the WYSIWIG editor and the "wpautop" function that is at the root of these (which also happens to make Wordpress slower than it needs to be). Sorry for the arcane tech reference, but it’s necessary to remind people that Wordpress overly messing with people’s HTML has gone on far too long. The current "HTML" view in the write screen is now a very strange hybrid.
4. And as I’ve argued in great detail in the posts on the security back-porting experiment, none of these rather extensive design changes needed to be rolled into the same update with the much needed security updates. They could have been kept separate, allowing users to continue using 2.3.3 for the time being. If Apache is able to do this, so should Wordpress… Stop using security fears as leverage to push your feature "upgrades".
5. Just for fun, along the way one of the more testy threads on the Wordpress.org forum was closed by Mr. Wordpress Matt Mullenweg himself, even though there were MANY, MANY complaining about issues with the 2.5 admin back-end design. Listen to your power-user base every once in a while, they are the one’s evangelizing your product for you (go read some Guy Kawasaki on this issue). They are the ones that might have to live through dozens of upgrades for clients, and their often painful aftermath.

OK, so let’s get into the details. Here is what my own customized Write Screen looks like, using the FCKEditor plugin and changes to the admin stylesheets and /wp-admin/menu.php.

(click image to enlarge in a new tab)

You can see for yourself that the vertical screen real-estate is handled with "respect". On a standard 15" laptop screen there is no scrolling necessary for me, even though the editor textarea is a good writing size.

It starts with moving the Blog Name and "User Account" info off to the right, saving tons of space at the top. Presumably as the author, we know what our blog is called… (open-to-all user registration is a security risk that should be turned off, unless you are e.g. trying to use Wordpress as some sort of membership site hack).

I do have my Firefox browser optimized not to waste too much at the top with toolbars either (it’s held to about 1" including tabs by customizing/decluttering/combining the toolbars), and my Windows bar is actually dragged over to the right edge of the screen.

But even without this one would still have a good sized editor textarea, maybe the "Tags" text-field would no longer be visible as it is now. The toolbars for the FCKEditor are also condensed down to the most important items BTW.

The point is, I can start typing without scrolling, the key controls are all within reach on the right side or at the top, and the Wordpress menu options are still within reach without scrolling as well.

(Notice also that I moved the "Publish" button away from the "Save" buttons to avoid accidental publishing, after all with your ping list, you really can’t take that back very well. Also, I added a "Duplicate" function that is the equivalent of a "Save As". Comes in handy if you write posts that belong to a series with mostly the same tags, or to break up over-long drafts into two or more posts. Also handy for duplicating pages where you e.g. want to split-test elements of your sales copy, etc. etc. "Save & Close" reliably takes you back to the "posts management" screen.)

I think since 15" screens are the de facto standard in portable (enough) laptops, it’s really useful to build screens for decent display on those. Yes, some people have much larger desktop screens, but one shouldn’t assume that.

Another issue is that text becomes harder and harder to read the wider the column size (your eyes have to move/fixate more horizontally), so going wider with the editor textarea is not helpful. I have set mine to display in roughly the same width as my posts are displayed on the blog itself.

Now compare the Wordpress 2.5.x write screen, I have put some free-hand notes in there to highlight the issues:

(click image to enlarge in a new tab)

It’s really quite a sight. In fact, the first thing that pops into my head whenever I see the 2.5 write screen is how empty it is: There is almost nothing in the top half of the screen! Also noticeable is that part of the menu/sub-menu was arbitrarily moved off to the right (not visible in my screen cap).

Settings, Plugins, and Users are now separated from the rest, even though Themes and Widgets are still under "Design" on the left. If that is supposed to be intuitive, good luck. First off, changing Themes should be the rarest of operations, so if anything IT should be moved out of sight. Second, aren’t Plugins part of the design in a way? Widgets and Plugins may get changed quite a bit more often for some, so if anything they should be closer at hand.

I am including a few other screen-caps of my set-up, just to show what the menu and some of the screens COULD be like. Obviously everyone is likely to have slightly different priorities and preferences. Which is exactly my point: If Wordpress wants most of its users to be happy, it might be worth considering drag-drop customizable menus.

I did my changes in /wp-admin/menu.php manually to get greater sanity. Dropped a few of those items I never use, and otherwise rearranged and renamed things as much as was quickly possible.

Also notice that I rearranged the posts table to sort by status first and then by "Modified" so that my drafts would be at the top. It’s like a post to-do list and brainstorm. (Don’t ask me what hoops I had to jump through to get the list to sort by BOTH "Status" descending AND by "Date Modified" descending combined.)

(click image to enlarge in a new tab)

To show how the old Widget screen could have been updated only slightly to make it more usable, look at this next screen-shot. None of the much-criticized new Widget screen functionality needed to be invented, it works great like this:

Tightened up the font-sizes/margins/padding on everything a bit, moved the Widget "tray" to the top, and thereby created space for easily handling up to 5 sidebars – I use different ones for the index.php, single.php, and page.php views.

(click image to enlarge in a new tab)

There are a few other design issues with 2.5, such as the "Manage Posts" view that will now delete posts without a pop-up warning, and a few others. But so far most of the criticism has come in response to the write/edit screen and the new Widget management screen. And frankly, I believe for good reason.

Until they do something to blow me away with in terms of new functionality, I am sticking to my custom "2.3.3 Renegade" version… can you blame me?

First, I want to emphasize that I did this largely to show that it was possible, and that Wordpress (Automattic) should consider rolling out such security fixes for older versions as patches rather than forcing "upgrades" to entirely new iterations of Wordpress with many feature changes mixed in with such fixes.

First, I did move the "Retro-fit" to this production blog of mine that is running a customized version of 2.3.3, and things have been going fine, for the most part.

Here is a screen-shot of the "no frills" login screen that is now missing the formatting that changed with 2.5.1 (as mentioned in the prior post). Since I have the user registration turned off, this is a non-issue for me, I can easily deal with not having a "pretty" login screen.

The only other thing that I found to not work was the AJAXed post/page/comment deletion sequence. There must be a part on the JavaScript of the sequence that blocks the "delete" action, returning

"You don't have permission to do that."

OK, no problem. I tracked down the JavaScript function that throws the error in a few admin files that have delete links on their screens,

onclick='return deleteSomething(... );'

but the AJAX code that it calls is too labyrinthine to mess with, so I left it alone. Instead I replaced it with a simple

onClick='return(confirm("Really Delete?"));'

which fixed it, but also turned off the AJAX effect of the red-then-disappearing post/page/comment. In case you’re "married" to that one, this wouldn’t be for you. Personally, I can easily live without it, since the only thing that might get deleted regularly are spammy comments.

The files that needed this change were

/wp-admin/edit.php
/wp-admin/edit-post-rows.php
/wp-admin/edit-pages.php
/wp-admin/edit-comments.php
/wp-admin/includes/template.php

Now, again, I want you to keep in mind that I embarked on this adventure mostly to prove a point about the possibility of having targeted security patches for past versions supplied by Wordpress.org (even though I also did get a nice security upgrade for my highly customized 2.3.3 install out of it). Obviously if they were to supply it, it should be safer/more targeted, and a hick-up such as the delete function thing would be avoided as part of the patch.

Whoever their AJAX specialist is could have likely changed just 1 or 2 lines in the AJAX code itself and solved the problem for all files/screens calling it. I simply don’t have enough experience with AJAX or the overall application logic in this case to know what to change to work the improved user authentication security from 2.5.x into it.

Incidentally, I was playing with a 2.5.1 install to collect and make more specific my thoughts on what I feel are things wrong with 2.5.x. More on that in the next post. But what I did find is that 2.5.x abandoned the delete confirmation pop-up entirely in the new admin interface, so that once you click the delete button at the top, if any posts/pages/comments have their checkbox checked, there is no going back!

Not what I consider a safe design. In all likelihood, you can add the above simple "onClick" JavaScript I devised to the button input element, though I haven’t tried it yet. I am simply unsure what their design goals were with this new admin interface. Now we have something against a pop-up preventing a possibly unwanted deletion?

Given that the post list might display well below the fold, it is in theory possible that someone accidentally checks one of these posts along with another desired check, then hits ‘Delete’ with a post that wasn’t even "in sight" now being deleted. Not good.

UPDATE:

I found one more issue that was created by the back-porting, and this one was actually a bit more of a problem: The whole-sale updating of

/wp-includes/functions.php

to the 2.5.x version actually caused the blog’s feed to fail. Took me a few days to figure this out, actually found it while adding a feed button in my categories.php and search.php templates.

The do_feed() call in the funtions.php file in 2.5.x actually calls a whole new function

get_default_feed()

that wasn’t there in 2.3.3 and throws the error. I first tried to update all of the feed[...].php files in /wp-includes, but that just produced more errors. Instead, the solution was to replace the 6 feed related functions

do_feed_...()

in /wp-includes/functions.php with the 2.3.3 versions. Then things were back to normal.

By now you are probably getting the idea that this back-porting business is NOT for the casual user of Wordpress. It should be noted however that I could have been more careful in porting only those exact changes from 2.5 that had to do with the security fixes, rather than replacing whole files and hoping for the best.

As it turned out, it mostly worked out OK, except for the issues addressed above.

And of course, it still proves that it should be easy for Wordpress.org to make the security fixes ONLY available as a small patch file package, a "Service Pack" of sorts to keep the older versions running as far as security.

Notice that this is the option chosen by many Open Source projects such as the venerable Apache server that powers most of the world’s Web servers. They still support version 1.7 with critical security updates, even though they are up to version 2.2 by now.

Why? Because they understand that there can be significant pain associated with a forced upgrades due to security issues, especially for admins that are dealing with a large installed base.

Maybe Wordpress/Automattic could choose to see this as well, and head in this direction. What’s considered reasonable at Apache.org might be worth considering for them too. We don’t necessarily always need the latest "code poetry"… but we do need critical security.

Food for thought.

You may have heard any number of things in recent weeks and months about the need to upgrade to Wordpress 2.5.x because of security issues with the older versions. In fact, it can almost sound as if some people wanted to scare you into upgrading.

Now there have been for a long time issues with the fact that each Wordpress "update" tends to be far from a smooth/pain-free operation for many people, breaking relied-upon plugins, creating issues with your (possibly custom) themes, and requiring the re-edit of any personal hacks you may have had reason to place directly into the Wordpress core distribution because some things don’t work quite right in there, and pleas to fix them are often ignored.

In this case however, there have also been a large number of changes to the Wordpress admin back-end, the usefulness of some of which has been judged to be questionable, or that have caused actual problems (2.5 could delete your text widgets among other things). One look at the Wordpress support forum tells the story. I am not going to get into all of the reasons right now why I am not upgrading to 2.5.x for the foreseeable future. That is for a different post.

Suffice it to say that many top bloggers with an understanding of the tech issues have said they won’t upgrade for a while.

What is important though is that the security fixes that came with 2.5 should in reality be made available as small, "single file copy" patches for anyone deciding to stay with the older version(s) for now. I have said as much on the support forum in several places, most recently on a very active "2.5 backend issues" thread that actually got shut down my "Mr. Wordpress" Matt Mullenweg himself.

Since they currently seem rather unconcerned with making these fixes available without a wholesale upgrade, I decided to take it upon myself to do so.

Here are the results:

After studying the ticket records for Wordpress 2.5 and 2.5.1 (the very rapid release of yet another "update" so close to the first one should tell you that 2.5 wasn’t quite as ready for prime-time as they might have wanted you to believe), it appears obvious that the biggest security issues come from WP user registration and the way it handles passwords.

As for registration, I recommend for both 2.3.3 and even the later versions that you turn it OFF in your Admin panel under "Options > General > Anyone can register" (uncheck the check-box). Unless you are using Wordpress as a sort of membership site, there is really no reason that I can see for yet another registration. Just require name and email in your comment form, those get auto-filled after the first comment for most themes and in most browsers.

If you have multiple WP authors, Admin can add those manually in a controlled way. Else, what are those users for? Since WP isn’t designed to be e.g. an auto-responder by default, those Email addresses from registration aren’t really all that useful to you. Better to use Feedburner or other means of opt-in.

By the way, even 2.5 still had an issue with their user roles security, potentially allowing "less than admin" type users to add other users. Ooops. (Aside: The role system in Wordpress is a bit labyrinthine because the application logic for it is spread all over the place in the code.)

So turning this off is a good idea (if possible for your purposes). So then the only major security issue that still needs fixing is the way that passwords (for Admin, etc.) are handled in Wordpress, both in the password database and as cookies in your browser once you are logged into your Wordpress back-end. If you are interested in the deeper technical issue of this, go here and here and enjoy…

From studying these, I simply extracted the files that were changed for 2.5, and then proceeded to copy those, one by one, into a 2.3.3 test install. To not keep you in suspense any longer, this security retro-fit for 2.3.3 works and here are the files to update:

(all files can just be overwritten with the 2.5 version, any totally new 2.5 files are marked)

/wp-includes/class-phpass.php (new file)
/wp-includes/compat.php
/wp-includes/functions.php
/wp-includes/media.php (new file)
/wp-includes/pluggable.php
/wp-includes/registration.php
/wp-includes/shortcodes.php (new file)
/wp-includes/user.php
/wp-includes/wp-db.php

/wp-admin/includes/misc.php
/wp-login.php
/wp-settings.php

The there are two files that you each have to add one line each to. In

/wp-includes/deprecated.php

add the line

function gzip_compression() { return false; }

at the top inside of the ‘<?php’ open tag. The reason we can’t just overwrite the whole file with the 2.5 version is that it actually would try to re-declare many more functions that were deprecated in 2.5 and placed into this file.

Last but not least, we need to place our own "secret key" generation phrase into your

/wp-config.php

with this line:

define('SECRET_KEY', 'put your secret key phrase here');

Note that the comment above this new code reads:

// Change SECRET_KEY to a unique phrase.  You won't have to remember it later,
// so make it long and complicated.

So that’s what you want to do.

Again, so far I have found this to work after having put my 2.3.3 test-bed blog through the paces. I run about a dozen or so standard plugins in this installation, and there APPEAR to be no adverse effects from these changes. Security should have been enhanced, which was the goal in the first place.

So far the only adverse effect has been that the "blue shield" formatting of the login screen form has gone bye-bye, likely because 2.5 wants to use it’s changed CSS to format. But since we said to turn off the user registration (and thereby login) for all but Admins and maybe collaborating authors, this shouldn’t be a concern. I might post a visuals fix for this at some later point, but right now that’s way down my listy of priorities…

Here again is the predictable WARNING/DISCLAIMER to only attempt this in a test install of your own first (with all of your plugins in it), OR if done to a live install, to do it during off hours and with back-ups of your old 2.3.3 files at the ready in case there are any problems.

Hope this has been useful to you, and that you’ll sleep better at night. If these explanations seemed too complicated many paragraphs up, PLEASE DO NOT ATTEMPT this without someone technical helping you.

UPDATE:

Before proceeding with any of this, read about some of the additional issues that came up in this follow up post.