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.
- Open phpMyAdmin (a different MySQL web access tool should be fine, too)
- You should see the welcome page. Find the Database selection box and select your WordPress database
- 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)
- You should see the wp_users table structure, but you’re looking for its contents, so find the Browse link and click it
- 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)
- 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
- Close phpMyAdmin
This is great! I always wondered why this TinyMCE editor in WordPress is so poor, but when you go to their web site you see many many useful buttons. Finally there is a simple way to extend the default toolbar.
The thing I probably missed most was the U button. In fact I use to render underlined text with a maroon color by means of the WordPress stylesheet. I always had to add the markup manually, and in WordPress 2.1 it got trickier because I had to make a Visual-Code-Visual roundtrip, due to the escaping facility added to the Visual side.
I like WordPress because it’s easy to install and use. But I really dislike the way it’s put up.
I’m not going into an exhaustive critic here because I really bend to the dedication coders devote to WordPress. I’ll just say what refactoring WordPress needs.
- the architecture must conform to a clean design, with the details hidden in lower layers, but with the mechanics shown in higher ones.
For example, if you open the wordpress/index.php file this is what you find:
<?php /* Short and sweet */ define('WP_USE_THEMES', true); require('./wp-blog-header.php'); ?>
which is certainly short and weird for the main code of any software! We shoud see the famous loop here, shouldn’t we?
- the documentation must be organized like any other software documentation: A user guide + a developer guide + an API reference + an instant guide.
For example, at this moment in the docs main page there are 114 content links in 8 categories.
- any given external name must get an expert approval, before it’s used for the first time. A name is to be considered external if it’s going to be used (or understood) by someone else, be they persons or software, outside the smallest scope where it appears for the first time.
For example, digging in the code I found this function name: maybe_create_table (at wordpress /wp-admin /upgrade-functions.php :332). By its name I’d say that sometimes the function creates a table, and other times it does not. This is true with respect to the chosen implementation, which has been optimized for not creating a table if it already exists. But it’s false with respect to the context, because before executing the function, a table may exist or not, but after executing it, a table will exist for sure. So, maybe_create_table should be renamed as always_create_table, or just create_table. In case of collision with a previous create_table function, it could be named create_table_if_needed. And it’s generally a good idea to sort the words of a multi word name such that in a sorted list of similar objects, similar/related entries will appear near to each other.