Archive for the ‘Wordpress’ Category


You have no spam. Must be your lucky day. :)

October 20, 2005

Now we have a Manage Spam tab. Things are getting better in’s land.


One question to rule them all

October 18, 2005

The newest mistery in’s world is: how did Anakin become Darth Vader? Oops…no, it’s not this one. Alright, this is the mistery: what’s the purpose of this API key???


Can anybody please tell me…

October 2, 2005

…why there are no more graphical smilies? They were pretty nice…


A first glance at the new rich text editor

September 20, 2005
  • Some buttons missing: underline, find, find/replace, sub, sup, fontsize, blockquote. I use fontsize/sub/sup a lot for footnotes. Usually I use a “1” or “*” with superscript to indicate footnotes, and fontsize to write them.
  • The more and nextpage button are not functional for now, at least for me (I guess devs must already be aware of it).
  • This resizable thing is very cool.
  • It would be nice if the insert image dialog had a “Browse” button so we could add images we just uploaded to WordPress. Actually, an upload button would be perfect.
  • Smilies are very nice .
  • It seems like TinyMCE is not XHTML compliant. For those who write in portuguese this is a problem, because characters like “é” are very common. If you like to write code, then characters like “< " should be a problem too. Also, and I don't know if this is TinyMCE's fault or WordPress', but I just can't insert spaces between unordered list items. I press SHIFT+ENTER and the spacing actually shows in editor, but don't show in my blog. Images don't have an alt tag, and it seems that WordPress inserts some paragraph tags; they're causing some XHTML trouble. Try to validate this page and you'll see them - it complains about tags (paragraph ones) that DO NOT SHOW UP in the HTML view (that's why I'm assuming WordPress is the one inserting them). This is VERY ANNOYING because TinyMCE TRIES TO INTERPRET code tags instead of replacing them with their respective XHTML codes.
  • The path at the bottom is cool for those who know a little HTML, it helps to show you “where you are”.

This is just a first glance, so don’t take it as a complete analysis…but if these issues were addressed this editor will REALLY ROCK.


Dashboard issues

September 20, 2005

I corrected a typo in another post yesterday and noticed that it showed in dashboard’s latest posts. Wasn’t it supposed to show the “just-created” posts instead of the “just-edited” ones? And it would be cool to add a checkbox to the Write Post page with something like “don’t show this post in dashboard”. Not that I mind, but what if you write a bunch of “Testing the nextpage button” or “Test 1” kind of posts? Should these posts show up in dashboard too?


The Community

September 19, 2005

I think I finally figured what is: it’s a community of WordPress developers (Ryan, Matt, Donncha) and beta-testers (us) doing their best to create the best blogging solution to date. Most developers’ blogs talk about changes/enhancements, while most non-developers blogs talk about new features, bugs and suggestions. It’s a very interesting approach and we have the chance to say NOW what should be included in 1.6 when it’s released. I had a few questions about nature when the invitations started to fly around (some people even suggested it would be an orkut-like site) , but I admit that I must be really dumb for not realizing it before.


Suggestions for WordPress

September 18, 2005

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 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, 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?).