How to make the WordPress login for your personal use only

Limit Login Attempts is a very good WordPress plugin that limits how many login retries an IP can perform (and fail) before being locked out some time. I cannot recommend it enough: it works like a charm and can be tweaked at will. It also notifies you about lockouts, so that you know if someone is trying to gain access to your site. Of course you still need a strong password.


Let’s see how a login would work in the real world. If the blog was a house, the login page would be the door and the login button the doorbell. A guest comes to the door, slides their business card below, and rings the doorbell. The gatekeeper wakes up, collects the business card, checks guest’s credentials against the list of people allowed to get in. If there is a match, the gatekeeper opens the door, otherwise goes back to sleep.

In a brute force attack, a guest is trying to get in by submitting ever changing business cards to the gatekeeper, hoping to find a match by mere chance. When such an attack takes place, the gatekeeper is doing a lot of “useless” work, and soon they’ll ask for a raise.

To prevent that, the master provides the gatekeeper with a scanner for business cards that reveals the factory (IP) that made them. Automatically, the scanner rejects any guest whose credentials are written on a business card made by the same factory of the business card of a guest whose credentials were not on the list. This is Limit Login Attempts.

It’s a nice mechanism that in general will work very well because many guests make their business cards themselves. Additionally there are so many commercial factories around that the risk of a rightful guest to be using the same factory of a gatecrasher is very small.


Limit Login Attempts has been doing quite a nice job since I installed it, but lately non desirable people have started sliding below the door business cards made by many different factories, thus reducing a bit the effectiveness of the scanner. Along time, I went through all these levels of annoyance.

  1. Just ignore them.
  2. Write a sarcastic post about them.
  3. Tweak the scanner to block more and faster.
  4. Destroy the doorbell.
I never have guests on my list: it’s always just me at the door. So I do not need a doorbell because I can call the gatekeeper and trust them to recognize their master’s voice. Of course, I still present my credentials.

Step 1 of 2 – Edit the wp-login.php file

In your WordPress blog directory there is a file called wp-login.php. It’s the file that shows the login page. At the very beginning, after the statement that reads {[ .wp-login-start | 1.hilite(=php=) ]} insert the following lines of PHP code {[ .my-login-server | 1.hilite(=php=) ]}

What these lines do is to check if the user has submitted a login form with a given challenge/answer pair. In this example they are doit/now. If the pair is there, then the login form is processed as usual, otherwise the user is redirected to the home page.

Of course you MUST NOT use doit/now, but feel free to choose any other pair of words that you can easily remember, possibly unrelated, like spoon/pig. (sorry, now you cannot use that pair either) Use only letters a through z. (this is not a password !)

That pair is your secret. Do not tell anyone, unless you want them to be able to get through the login page.

Step 2 of 2 – Add a bookmarklet to your browser

Edit the following code such that the challenge/answer pair matches the one used in Step1. Then make a bookmarklet out of it, copy the result in a new bookmark and call it My login. {[ .my-login-client-safer | 1.hilite(=javascript=) ]}

What these lines do is to add a challenge/answer pair to the login form and submit it.

When you want to login, go to the login form and enter your username and password as usual, but remember to hit the bookmarklet instead of the standard button. (If you used the standard button you’d be redirected to the home page, without logging in.)

A Login Dongle Plugin

I’ve already made a Login Dongle plugin for WordPress with all that code. I’m going to upload it this week. Stay tuned.

EDIT (2012-02-09):


Full UTF-8 support in WordPress

A few days ago I discovered that WordPress didn’t support full UTF-8 strings, whose characters are 1 to 4 bytes long. Instead it does support all unicodes belonging to the BMP, whose UTF-8 characters are 1 to 3 bytes long.

This WordPress defect is “caused by” MySQL 5, which only supports UTF-8 characters in the BMP. Apparently, MySQL 6 will be full UTF-8 compliant.

This morning, with the help of the UTF-8 class I recently developed, I made up a new WordPress plugin that adds full UTF-8 support to WordPress.

And this is the same sentence by Douglas Crockford, from the RFC4627 I cited in the previous post:

a string containing only the G clef character [𝄞] may be represented as “uD834uDD1E”

Windows users see a rectangle: it’s a Windows feature, but they should see the following thing

Imagen 1

You should note that the G clef above (not the one in the picture 😉 appears in the HTML not as an entity but as a common UTF-8 character, entered as is in the WordPress editor. You can see it for yourself by comparing the source code of this post (1) with that of the previous one (2).

Note that my plugin works for post and page content, title, excerpt, and also for searches, but it doesn’t cover custom fields (since version 2.0.0) any character written to and read from the database. For this reason Anyway, I’ve just opened a ticket about this issue in the WordPress Trac: please drop by and comment 🙂

What follows is the code of my Zend_Utf8 class, which I included in the plugin, after de-Zend-ifying all of it, for safe distribution in the wild.

{[ .Ando_Utf8 | 1.hilite(=php=) ]}

WordPress on Chrome has the messiest editing bug

I found this bug recently, and there seems to be very little evidence of it in Internet.

I have the last versions of WordPress, Chrome, and WinXP. When editing a post in Visual mode, if I write normal text, all is well, and if I change to HTML mode and back to Visual, all is fine too. But if I click the bullet list (or number list) button in a paragraph, the bug is reproduced: the path at the left bottom corner of the editing box says “Path: ul li span”.

This additional span has a style that sets the size of the font to 13.3333px !!

The formatting, as seen in the HTML mode, is:

And if I undo the bullet list (or number list), it becomes:

The real nasty things about this bug are:

  1. It doesn’t show up in Firefox (the most common default browser among web developers)
  2. It’s pretty common, but almost nobody noticed it
  3. It shows up when doing/undoing a bullet list or a number list
  4. The bug adds ghost spans, one per item, that you must remove manually (like in the following entry)
  5. And manually means manually in HTML mode, because in Visual mode, the “Remove formatting” button usually removes too much formatting
  6. The bug is so strong that if you remove the ghost spans and then undo a list, the same number of ghost spans are added back again
  7. If you don’t remove the garbage as you go, it gets messier and messier, because the ghost spans start to appear also where never there has been a list
  8. I wasn’t able to find where the bug comes from: a search of all WordPress code returns nothing interesting

I’ll look at my theme and plugins code.

For now, it’s a filed bug.