1) I found a stats plugin to use that works well with the REUS install after a few custom tweaks. Some minor modifications to the database calls and the reporting page to allow for more tracking on recent links, and the WP-Shortstats plugin has been performing flawlessly. I have included it with custom changes in the new REUS .zip package (link at end of this post).

Best thing is, the stats data belongs to YOU, no one can hold it hostage (unlike e.g. Budurl.com, which wants to only allow you to download your stats with a paid account). Also note that many 3rd party services’ stats solutions tend to lack good comparative screens, overviews, or ordering by e.g. “all-time highest clicks”, and so forth:

With REUS you can watch your clicks roll in in near real-time as shown here (you’ll have to hit refresh in the “Admin > Dashboard > Shortstats” screen to update). No fancy graphics like world maps, etc., but the information you really need to assess the success of your links:

2) Using your own short domain looks custom and gets attention. As you can tell from the above screenshot, people get curious about your custom/novel shorterner URL, and navigate to the “/” root quite often on first use. To make this useful/profitable for you, one key manual update that needs to be made to the “/wordpress/wp-content/themes/redirect_engine/index.php” file is to set up redirection of “/” to your blog or other page of your choice.

So in my example an inquisitive user would type in “http://3on.us/”, which for my set-up redirects them to the original REUS post on my blog.

3) You can create links that you completely determine the URL appearance of, both as to the domain (which will seem pretty custom vs. the publicly available services), as well as to the link extension, which can now be at least semi-sensible:

Keep in mind that a non-sense link is harder to process for the brain, and “a confused mind always says No!” as they say. So people are less likely to click. Meaningful URLs do have higher click-through rates from what I can tell so far, and marketing savants such as StomperNet’s Brad Fallon seem to agree (and guys like him test everything!).

Here is another bit of proof. This screen cap is a stat taken from celebrity Internet marketer Joel Comm’s TwitPwr.com URL shortening service:

What it shows is that the total average click-through for all TwitPwr.com links is just under 8 (about 160k / 20k), and his list of user includes some pretty illustrious company with largish follower counts. As my own stats screenshot from above shows, my REUS links have been pulling well above that on an average of about 1,000 followers over the last 4 weeks:

147 links have been clicked 3438 times on Twitter and a few other sources, for an average of just under 24 clicks per link. Not bad (and yes, I did subtract out the “/” root inquiries and robots.txt hits; and robots.txt disallows all further search engine bot access).

Granted there are many variables that come into play that make a simple 1-to-1 comparison difficult, including the fact that Twitter users may be slightly more reluctant to click on TwitPwr.com links due to the slightly, shall we say, “promotional” nature of that service. But the numbers are still pretty convincing, especially given the follower advantage for many TwitPwr users.

4) URLs can be shortened further on the fly due to…

…Wordpress’ post slug tolerance, e.g. “3on.us/roll-tinyurl” will still work as “3on.us/roll-t” in case you had to save even more space to fit into 140 characters on Twitter. By the way, if a duplicate match should arise due to lobbing off too much from a link extension, Wordpress/REUS will default to the earliest URL/post found:

5) Just about all of the other URL shortener Bookmarklets disallow for creating custom extensions, even if the main service does! To get this feature, you will have to manually copy/paste the URL to be shortened into their home page, etc. Try it out yourself with e.g. tr.im, their bookmarklet does not appear to allow for customizing the link the way that the tr.im Web interface does, and it cannot be edited after the initial save.

Whereas the REUS Wordpress-based solution leverages Wordpress’ own “Press This” bookmarklet to make custom extensions without copy/paste possible (as described in the original post and the new install instructions).

6) By owning your own Tinyurl service, you know that your links/stats won’t one day go out of business (in this economy, you never know…), just as long as YOU are still in business. And you can back up all of your links and stats, and could even run them locally from your own computer, just in case you were forced to give up your main hosting account and could no longer afford the $10/year for the add-on domain used for your REUS install (let’s just assume right now that that will NEVER happen…).

7) To recap some of the benefits already described in the original post, with REUS you can create links as short or even shorter than the shortest http://is.gd etc. link, because you could choose to have the link extension only be one character, e.g. “http://3on.us/x” (limited supply of those of course).

Some of the services already waste an extra 2 characters or more in the domain name, e.g. “budurl.com”, “twurl.nl”, “twitpwr.com”, etc. With REUS, if you get yourself a 3 character .us domain to install on, you will have up to 16 charaters for the link extension and still be within Twitter’s 30 character link length limit.

I’ve also found that I was able to quickly commit to memory some of my most-used links with shorter/memorable names, so that I could easily type them in manually in certain situations, for example in some blog comments.

8) If you are using marketing related link tracker services such as aWeber.com or 1shoppingcart.com, you can in principle use your new REUS to replace those as well. For that type of use you would also not be constrained by the extension length as much (e.g. in Email), and could use even more descriptive link extensions, e.g. “http://3on.us/grab-your-free-copy-here”.

9) You are free of the various idiosyncracies of other 3rd party shortener services. For example, both Tinyurl and is.gd truncate your “#[anchor name/id]” on-page-anchor entensions (not sure why), like those used to direct straight to a specific comment on a blog post page.

10) I have built a character counter into the custom “press-this.php” file (called by the “Press-This” bookmarklet), that comes with the REUS distribution. This makes it faster to create exactly the right link length (after I found myself doing a lot of counting initially) that will still display without Twitter abbreviating your link with an “…” ellipsis. As already mentioned, in the case of my example domain “3on.us”, I have exactly 16 characters left to stay within Twitters 30 character limit.

All while typically having the link extension prepopulated with candidate terms and phrases from the post/page Title (if present in the Title tag) that can easily be edited down to the desired length.

—-

So, 10 good reasons to get your own REUS install. It’s completely free, no strings attached. If you use Twitter and care about the links you post there, you really might want to give it a whirl.

Here is the link for the updated REUS distribution:

http://businessmindhacks.com/v/redirect_engine.zip

Here is the link to the original REUS post again, as well as a link to an “install instructions only, no rationales” version.

Enjoy!

—

OK, haven’t posted in a little while, in part because I had been working on some pretty cool techy stuff. Here is the first result from it:

Have you been using URL shortening/redirection services like TinyURL, is.gd, etc. in order to send lengthy links to friends in a shorter format, or to fit them into the space-constricted posting fields on micro-blogging services such as Twitter?

If you have, and you’re a marketer, you have probably been wishing that you could track the number of clicks on those links you post to Twitter, or improve the appearance of the link text, etc.

While there are some services available that allow you to do some of that, such as Tweetburner.com which creates a trackable “http://twurl.nl/…” style link, they almost all have one drawback or another, e.g. they 1) don’t allow for custom link text (Tweetburner), 2) sometimes truncate your original link’s # anchors if present (is.gd), 3) don’t allow for tracking, 4) want your Twitter credentials to allow for tracking, and 5) they all end up kind of owning your data.

So I figured, if there was a fast/cheap solution to set the same thing up for yourself, so that you control all of the variables, that would be a good thing, no? You will see in a moment how it can be accomplished using a basic Wordpress 2.7 blogging software installation. Now you’ll likely still use other services to auto-shorten links as well, but when you want to make it count, and want your shortened link on your terms, I bet you’ll like what I have cooked up for you.

The Instructions

Let’s take it step-by-step. Note that I won’t get too in depth with basic technical explanations, I’ll assume that you are familiar with FTP and have already done a standard Wordpress install before. If you’re new to Wordpress, I’d recommend hiring someone to do these steps for you, they should bill you for at most 1 hour as you will see.

I am posting the expected time to complete with each step:

1) You will need to buy a .us domain to install as an add-on domain with one of your existing hosting accounts. I used a http://Bluehost.com account for this, they have reasonable prices and service, but use any hosting/domain provider you would like. Note that it’s not worth getting a separate hosting account just for this engine, and an add-on domain should only cost about $8-10 per year.

Search for short, 3-4 character .us domains, as you’ll obviously want to save space. I found that there are still plenty of 3 character semi- to non-sensical domain names available with one or two numerals in the name, e.g. I picked 3on.us for my test case.

Once purchased, …

… install the domain in your hosting account’s domain manager as an “Add-on domain”, which should also create a new directory under your public_html directory, in my case I simply chose “3on”. This is what the process looked like in a CPanel hosting account:

— Time: 10 minutes (depending on how long you search around for a domain you like :).

2) Now simply download a copy of Wordpress (WP) 2.7, and install it on the newly created directory, so that the directory structure will read “/public_html/3on/wordpress/…” (structure shown below is how it should look in your FTP client program, obviously with your own directory name)

Go through a normal WP 2.7 install including setting up the database and editing wp-config.php, if you’re using Fantastico to automate this, just make sure that the install directory is the new one you want.

Either way, make sure you select option “no search engines” during the install, as this will avoid your stats getting falsified by frequent search engine hits on your redirect/link shortening engine. The “Settings > Privacy” panel should later look as shown below, verify and if necessary adjust after the installation:

— Time: 10 minutes.

3) Upon install, log into the WP admin panel, and edit “Settings > General” as shown in the screenshot below (obviously with your own domain name).

You’ll also need to do one more manual step to copy the “/wordpress/index.php” into the new domain’s root directory, i.e. “/3on/index.php” and change the path inside the file as described in the link right next to “Blog Address URL”:

Enter the address here if you want your blog homepage to be different from the directory you installed WordPress.

The point being that you need your blog to respond at the domain level without any further path, i.e. “http://3on.us/” and NOT “http://3on.us/blog/”, etc. which would obviously be counterproductive to our link shortening agenda.

— Time: 2 minutes.

3) Now that Wordpress is installed, go to “Settings > Permalinks”, and select “Custom Structure”, placing “/%postname%” into the field by that option. This will append your redirect “post” names directly to the domain, e.g. “http://3on.us/testlink” — Time: 1 minute.

— Time: 1 minute.

4) We’re now coming to the heart of the matter the modifications needed to have your Wordpress install act as a redirect engine. I’ve packaged the necessary files as a Wordpress Theme, download them here:

http://businessmindhacks.com/v/redirect_engine.zip

Then extract the .zip file, and FTP upload the “redirect_engine” folder into your “/wordpress/wp-content/themes/” directory as you would any other theme. Activate the theme by going to “Appearance > Themes”, then selecting “Wordpress REUS” by clicking on the theme’s screenshot or link, and finally clicking “Activate Wordpress REUS” in the upper right hand corner.

If you are interested in the code that makes the redirection work, look at the “single.php” file. It’s really quite simple. Also note that “page.php” contains the same code, so you can in principle use pages to create redirect links as well. However, you won’t be able to use the “Press This” bookmarklet we’re about to discuss to do so, as it defaults to “Post”. Use the “Pages > Add” menu instead if you’re so inclined (e.g. to keep certain links separate from your everyday links).

— Time: 5 minutes.

5) Now that the redirection is in place, we just want to make it a bit more convenient. This is where leveraging Wordpress’ “Press This” bookmarklet feature comes into play:

First, go to the “Tools > Tools” menu, and there locate the “Press This” bookmarklet link as shown. Then drag & drop it onto your Bookmarks Toolbar (in FireFox, which is the only browser I’ve tested this in, but IE should work similarly).

— Time: 1 minute.

6) You are now ready to test the new bookmarklet. Simply go to any web page you would like to shorten the URL for, and then click on the bookmarklet button in your Bookmarks Toolbar (obviously that Toolbar needs to be visible):

You will see a popup as follows (and may have to give your new wordpress site permission to open pop-ups, you’ll want to do this):

Note that you will have to be logged into your Wordpress install as “admin”, else you’ll be asked to log in first. Change the “post” title at the top to your desired link name, like in the following example (the post’s “slug”, which is the actual term for the link extension in Wordpress, is created automatically; note that any uppercase letters will be converted to lowercase and any spaces turned into a hyphen (-):

Then press the “Publish” button in the right bottom corner of the pop-up. Done! Your shortened redirect link has been created.

Note that the custom code for “single.php” arranges it so that the URL will automatically be parsed out of the “post” content (the live link shown above), while the link text (e.g. “Twitter Raising Money…” ) will be used as a post title/description in case you choose to pass this shortened URL on to Twitter. You can change this descriptive text in the form shown above, just make sure that you don’t accidentally delete the entire link (and thereby the underlying URL).

You will see the following output:

Now the “TwitterThis!” option won’t be visible to you yet until you do one more custom change to Wordpress I’ll describe in a moment, but you will already be able to copy & paste the newly created short link by right-clicking on “View Post” and selecting “Copy Link Location” (“Copy Shortcut” in IE):

You will also be able to see you newly created “post” that is the basis of your short link in the “Posts > Edit” screen, where you can do the same copy & paste maneuver as above from the “View” option that appears as you hover over the individual post row in the table:

Or click the “View” link to test that your redirect actually works.

Note that you can also rename the bookmarklet itself in your browser’s Bookmark Toolbar by right-clicking, selecting “Properties”, and changing the “Name” to your desired option, e.g. “MyShortLink” in case you’re using the “Press This” bookmarklet for other Wordpress blog installations or yours.

OK, this was the long version of testing, let’s say it takes you a few minutes the first time. Once you have done it several times, this should take you only about 30 seconds anymore.

— Time: 3 minutes.

7) Now comes the last step to enable the “TwitterThis!” option on the “Press This” result pop-up as was shown above. Locate the file “press-this.php” in the directory “/wordpress/wp-admin” and rename it to “press-this.php.old” or similar. Now go to the REUS theme directory “/wordpress/wp-content/themes/redirect_engine” and find the “press-this.php” file there. Then copy that file into the “/wordpress/wp-admin” directory.

Done. I tried to find a more elegant solution for this step, but there didn’t seem to be any as far as adding the extra bit of code through the Wordpress action model, etc. If you know of a way that this could have been done in a more automated way, please contact me. Thanks.

Alright, here is what you will see when you click on “TwitterThis!” in the “Press This” pop-up (assuming that you are already logged into Twitter, else it will prompt you to log in before passing you on):

Basically, the status field will show the link text which will typically be the linked post’s title for most blogs, as well as your brand-new shortened link with the readable extension. Here is what the Twitter status (the “tweet”) will look like after you hit “update”:

As you can see, Twitter did NOT alter the link itself in any way, this will be the case as long as you keep it at a total of 30 characters or less, else it may be adjusted with an ellipsis (“…”) or turned into a Tinyurl.com style link by Twitter.

In my example, we have 7 characters for “http://”, 7 for the “3on.us/” domain name plus forward slash, leaving 16 characters for the link extension (the post name as described above). “twittervaluation” is exactly 16 characters as it happens, so we know it works. When I tested “twitter-valuation” (17 characters) the link had a bit cut off at the end by Twitter with the “…” ellipsis when the actual tweet was displayed.

— Time: 3 minutes.

So what did we gain?

First, by my count, the whole thing should have only taken about 35 minutes or so. If you are not as handy with Wordpress installs, FTP, etc. and want to hire someone to do this whole bit for you, my guess is that they’d have a hard time justifying more than 1 hour of billed time.

Second, you now have a completely flexible redirection engine / URL shortening (REUS, kind of sappy, I know) device, that

1) Can create links 2 characters shorter than even the shortest http://is.gd link, because you could choose to have the link extension only be one character, e.g. “http://3on.us/x” (obviously you’ll have only a limited supply of those…). Note also that is.gd does truncate your “#” on page anchor entensions, like those used to direct straight to a specific comment on a blog post page. Score another one for REUS…

2) Can create links that you completely determine the URL appearance of, both as to the domain (which will seem pretty custom vs. the publicly available services), as well as to the link extension, which can now be at least be semi-sensible.

If you are used to using the link tracker services of aWeber.com or 1shoppingcart.com, or have seen those in list emails sent to you, you can in principle use your new REUS to replace those as well. For that use you would also not be constrained by the extension length as much, and could use even more descriptive link text, e.g. “http://3on.us/grab-your-free-copy-here”.

3) I am working on a stats solution using an already available “Wordpress Stats” plugin as we speak, I will update you as soon as I’ve verified everything. Once that is in place, you will have stats for your REUS. In the meantime, you can use the Stats tools available from your hosting account, such as “Webalizer” or “Awstats” in CPanel, just turn them on for the new domain and you should be able to view your click-throughs. Either way, the data belongs to YOU.

I would hope you agree: Not too bad…

The “theme” is being submitted to Wordpress.org later today, I will keep you posted when it officially becomes available from their site.

UPDATE: OK, seems like this is a little over the Wordpress.org Theme Team’s heads, they didn’t know what to make of the REUS “theme” and rejected it (so far) on the grounds that “This is way too much work to setup a theme.” Even though the only truly exceptional step is the replacement of the “press-this.php” with our custom version. Oh well, no big deal, it is small enough (about 30KB zipped) to easily host from my own hosting account. Here is the link again:

http://businessmindhacks.com/v/redirect_engine.zip

In happier news, I found a stats plugin to use that works relatively well out of the box to get some statistics going for your REUS install. It’s appropriately named “WP-ShortStats” and can be downloaded here. I will talk to the creators and see if they’d like to make a small modification to the reporting page (“Dashboard > ShortStat”) to allow for more tracking on each link, i.e. showing all of the referrers. Or else I’ll make some custom adjustments myself when I find the time. I’ll keep you posted.

Related to what I wrote near the beginning, it turns out that “Budurl.com” kind of holds your click-through stats hostage, you can only download them with a paid account. One more reason to use REUS…

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.

The code for gravatar image URL is taken from Tom Werner’s simple gravatar.php plugin, the failover to Mybloglog was my idea.

Check it out in action here.

Note that the commenter email address must be URL encoded twice, because the gravatar.com script otherwise strips out the @ symbol.

Plus this makes for minimal protection from email phishing bots. Better would be to have Mybloglog adopt Gravatar’s md5 encoding of the Email address.

If MyBlogLog also had the "&default=[url]" failover support, this could be chained to support further avatar service providers. Since it doesn’t, the chain stops with their somewhat ugly and small default (the grey square with the question mark).

And this also represents one fly in the ointment: MyBlogLog could at least make the size of that default the same size as the avatars their "coiserv.php" script serves – 48 x 48 pixels. I am going to talk to someone at Yahoo about this who might be able to pass it on to the right people.

To get the code, right-click and "Select All", then copy and paste to your theme’s comments.php template where you want the Avatar to appear.