Suggestions for WordPress

First, let me tell that I’m a WP enthusiast. I love WP features, and the day it will completely rule the blogosphere is not that far. Still, there’s always room for improving, and I’ll try to give some suggestions while 1.6 is still in heavy development:

• Hosting – WP is filling this gap fast, with the growing popularity of WordPress MU powered sites. WordPress is the ultimate blogging machine, but what does that mean if you don’t have a place to host it? Usually non-tech people don’t have a domain and don’t want to pay for hosting if they can blog for free (that’s the reason why Blogspot is so widely used, IMHO). People want to just blog, that should be developer’s “first law”. Hosting is the most important factor. People use Blogspot because they see it as a reliable option in terms of free hosting.
• Plugins – Well, the plugins themselves are not an issue, but there should be a way for users to install plugins in WP MU powered sites. This is a problem, because one of the most interesting features of WordPress is its ability to insert new code in it. Almost everybody wrote a plugin for WordPress, even me . BUT, if you’re using a site where you don’t have FTP access, how will you install your plugins? Of course you could use pre-installed ones, but that only solves half of the problem; what do you do if you want to use a plugin which is not pre-installed? And what do you do about security? I’d like to give my 2 cents on that: WP plugins could be like Debian packages. If the plugin has all the information necessary for its installation (with pre-install and post-install scripts), then why couldn’t it be automated? It could be a matter of telling where’s the plugin’s URI, click and install. Any additional information could be asked at installation time as Debconf does. One could ask “Hey, it’s still PHP code, how about security?”. Well, it doesn’t need to be installed immediately, it can be submitted for approval, and once the site admins approve it, the next requested installations of that plugin should be instantaneous. MD5SUM’s and GPG signatures should help too. On the WordPress side, it would need a lintian-like tool to verify plugins compliance with the new plugin API (see next topic).
• Customization – Have you ever noticed that we usually do the same things when starting a blog? First, we choose a “template”. If you like it as it is fine, otherwise you start to deal with changing colors and images to personalize your own template. Second, we add our bells and whistles to the sidebar – be it plugins, images, switching the order of things or even just changing strings. As of today, this is done by “getting your hands dirt” with code. I strongly advocate that the users should not touch code. But how can we achieve this without touching code? My suggestion for the colors/images problem is to create some kind of “CSS web interface”. Of course I know this would be a web application itself, but I’m not talking about every aspect of css, just colors and images would suffice. Think of something like KDE kcontrol. You choose what part you want to change colors, and then SELECT the color you want (instead of inserting some cryptic hex code). And to give the user the option to change the header image it’s not that complicated. So basically a new tab in admin interface named “Customize Style” could almost prevent users from knowing that PHP even exists. And yes, if we could have every theme available in 4 or 5 different color combinations would help a lot. The next thing is the sidebar. I still think there should be a better way to insert a plugin than “going to your somefile.php and inserting < ?php myplugin; ?> between lines x and y”. IMHO, EVERY PLUGIN SHOULD HAVE ITS CONFIGURATION DONE VIA THE ADMIN INTERFACE. I know that this would probably mean a rewriting of the plugin API, but hey, isn’t it worth it?

  KControl’s interface

• WYSIWYG – being an author of a WYSIWYG plugin myself, one could ask that I’m pushing WordPress developers saying “my plugin is better than the new WP’s WYSIWYG”. This is actually very, very wrong. I just happen to like that feature, and if WordPress provides it, I really don’t care who wrote it. To be honest, at a first glance TinyMCE seemed better than FCKeditor in some ways. I still have some issues, but I’ll give more details in another post. By now, I just want a blockquote button!!! Oh, and I have to mention that the fact that it’s resizable is VERY cool. And it would be awesome to have TinyMCE replacing the comments box too (remember, blog readers don’t have the obligation to know HTML just to use bold and italic functions)!

In the end, if these features make it into WordPress, this is how the user blogging experience could be:

1. Joe wants to blog. He goes to wordpress.com, signs up and activates his account.
2. Joe logs into wordpress. He then proceeds to choose his blog’s style.
3. Once he finds one he likes it, he tweaks a little with colors and upload a image to use as a header background image.
4. Now that the visual part is done, Joe starts to deal with his sidebar. He switches the order of some things, but then he notices that he wants to insert a plugin in his sidebar (something like “latest comments” or “9 users online”).
5. He requests the plugins. This is not the first time these plugins are requested, so they’re immediately installed.
6. He then starts to browse “The WordPress Open Source Shop” where he chooses the plugins he wants in his blog. He then finishes his plugins requests.
7. Once the plugins are installed, he inserts them where he wants them to appear in his sidebar via the admin interface.
8. He then starts to blog, without having to touch a single line of PHP (what’s PHP, anyway?)

Pretty exciting, isn’t it? The good part is that it might not be that far from reality (how about making it into 1.6?).