Posted on

Scripting on the Moon

Ideally, an application, library, component, or widget defines only a single global variable. That variable should be an object which contains and is the root namespace for all of your stuff. (Douglas Crockford, Global Domination)

JavaScript libraries like YUI, Prototype, and jQuery, all follow a common pattern when it comes to the declaration of the namespace the library is built upon. They prefix the namespace variable with the var keyword, as here:

{[.declaration /enzymes/chili-js.php]}

I think they are wrong, because the var keyword is used for declaring local variables. It usually works fine because the root script (the file which defines the namespace, like yahoo.js) is usually loaded directly into an HTML page, so the local context where it is evaluated is the JavaScript global object.

But if it’s not the case, maybe because I’m using a different method to load the root script, then the library’s namespace could get declared in a local context which is different from the JavaScript global object and it won’t be global as expected by library’s users.

It could be argued that the method used to load the script root is flawed: it should evaluate any loaded script in the global context. But I think that this is a weak argument: a library’s namespace is intended to be global, no matter where the script is evaluated.

Using a platform library for web programming is like buying a superpod for watching tv programs. If I’m on the Earth all goes as expected, but what if I move to the Moon? On the Moon I’d want to turn the superpod on and watch Lost and Prison Break. (No news please, I’m on the Moon.) Anyway I’d get very angry if that super gadget could only tune lunar garbage.

JavaScript doesn’t have a global construct, because it implements implied globals, i.e. any variable defined without the var keyword is considered global. Douglas Crockford doesn’t like implied globals, and JSLint points them out because they could be a mistake, but they are really the only available method to make a variable global.

Lunar YUI
works fine if you execute YAHOO = {}; before loading the root script
Lunar Prototype
doesn’t work
Lunar jQuery
doesn’t work
Posted on

WordPress Custom Fields Restyling

I use Custom Fields a lot, always by means of Enzymes, for managing the code snippets I’m going to comment about.

The Custom Fields section inside the post editing page shows added custom fields in a table whose columns change their width to fit the content, but the rows don’t change their height. I do not like that design: a definition list is much better than a table there. The key is the definition term and the value is the definition data.

Here are some pictures about the results of my experiment. The first row is my restyling, and the second row is how the same data appear in the usual design. There are three custom fields already added to this post: snippet1, snippet2, and snippet3; in the right picture, a new google custom field is going to be added

customfields1.png , customfields2.png , customfieldsnew.png

customfieldsold.png

Features of my restyling
  • added fields and the new field are evenly represented by the classical definition list style, where definition data is indented below the definition term; this provides a powerful clue for identifying the key / value roles, thus making all the labels superfluous
  • space usage is smarter; the key spans all the available width; the value almost all of it, and its height is greater than usual too, thus allowing for a convenient inspection, for viewing and editing purposes; the vertical scrollbar is much more useful than the horizontal one
  • by clicking its key, a custom field gets expanded, thus showing its value and its two editing buttons, while the rest of the custom fields gets collapsed; showing only one custom field at a time helps keeping user’s attention focused
  • the selection box for chosing an already known-to-the-system key is replaced by a list of buttons, located above the key field; by clicking any of them, the key gets copied into the key field, so that the user can leave it alone or change it, if needed; the overall design is more coherent
Posted on

How to reset a WordPress password

I’ve found this method today, and it works very well. I’ve just used it to reset my admin access password to a localhost installation. In fact it’s impossible to recover a password by means of an email if your system cannot send emails. This method is also very easy, and without email delivery delays in between.

  1. Open phpMyAdmin (a different MySQL web access tool should be fine, too)
  2. You should see the welcome page. Find the Database selection box and select your WordPress database
  3. You should see a list of tables, many with a common prefix, organized as links on the left and as rows on the right. Click the link wp_users (instead of wp you’ll use the prefix you chose when installing WordPress, if different)
  4. You should see the wp_users table structure, but you’re looking for its contents, so find the Browse link and click it
  5. You shoud see the wp_users table contents, one row for each registered user. Select the one with the admin value under the user_login column header and click on the Change link (with a pen icon, right below the last row)
  6. You should see a classical data entry form. In the row which has the user_pass value under the Field column header, select the MD5 value from the selection box under the Function column header, and write your new password in the text field under the Value column header. Then click Go
  7. Close phpMyAdmin
  8. Done