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.