whatsapp? not much

A friend of mine is going abroad and because he uses blackberry he has to have a data plan to BBM even when he can connect via wifi, and there is no skype for BB for the network he uses. This sent him looking for another communication app and he found whatsapp and I decided to pay the 1$ to get it on my IPhone.

Right now from my limited usage I am disappointed as I assumed the hype had a merit but I don’t see a reason to use it when I don’t have too.

Control XML-RPC publishing wordpress plugin

With WordPress version 3.5 remote publishing via XML-RPC became permanently active. This plugin simulates the functionality in versions 3.4 and before. Once active, XML-RPC functioning is disabled, and it can be enabled or disabled again in the “Settings” >> “Writing” admin page.

Download from repository

If you find this plugin usefull, don’t forget to donate

I will be very surprised if I will receive enough donations to cover the cost of the effort in designing, coding testing and supporting this plugin.but it is a nice sign of appreciation for my work.

Nice touch to the wordpress iphone app, it opens the admin at the right page if it detects that XML-RPC is disabled. Which makes me wonder why it doesn’t go all the way and submit the changed setting, or at least highlights/explains what shoud be changed.

You can’t disable pingbacks in wordpress :(

Yeh, the best that you can do is not to display them. All the site wide and per post options control whether the pingback/trackback will be stored in the DB, but the piece of code handling pingbacks from reception till checking if to put them in DB will always be executed.

This is probably not a big thing as I don’t remember exploits utilizing pingbacks, but it annoys me esthetically that an option  described “Allow link notifications from other blogs (pingbacks and trackbacks.) ” doesn’t do what can be interpreted from the description (what it does is to set the default of the ping option on the post edit page).

The decision to enable xml-rpc remote publishing support by defualt in wordpress 3.5 is good, but the execution is lacking

xml-rpc protocol is basically used to expose a set of API implemented by a site/server which enables other software to interact with the site/server in a way which is easier to program then trying to mimic user interaction. WordPress currently (version 3.5) expose API for publishing pingbacks, and content. Software like windows live writer by Microsoft uses the content publishing API supplied by WordPress to create a non browser editing environment, but the main users of the protocol right now are smartphones because the small screen size makes the WordPress web interface almost unusable.

Upto WordPress version 3.4 the remote publishing by XML-RPC was disabled by default, and the text explaining the option in the admin was technical and said nothing about smartphones.

With the rise of smartphone use, and the number of smartphone apps that use XML-RPC to publish content to wordpress, it is only a logical move to enable XML-RPC by default, but the development moto of “decisions not options” was taken too far as in this case the option has enough importance to justify having it.

The reasons are mainly security related

  1. It doesn’t matter how robust is WordPress code there is always a chance of a security bug that might relate only to the XML-RPC code
  2. Plugin authors will probably start supporting XML-RPC opening more attack vectors, and user will not even know about it because it will not have any GUI indication, and you will not know that unless you read the plugins documentation.
  3. There is no knowledge base on how to defend against brute force/dictionary attacks from XML-RPC. Current plugins might work,but will they give you a notice like “You failed to login 3 times, please wait 5 minutes till the next attempt” on the XML-RPC layer, and how the app will display that notice?

It might be that core developers are right and there is no risk added by having XML-RPC on all the time, but I think that a more conservative two step approach like

  1. Make it default to on, leave the option in the admin
  2. In two releases look at the experience of running WordPress that way and decided whether to eliminate the option as well

The reason it should work that way is that most user just leave the default setting on, so there will be a big enough user base to field test the feature even when the option to turn it off exist.

WordPress settings API is PITA

The WordPress settings API is there to “help authors manage their plugin custom options“, but does it? Many lengthy tutorials pointed to from the codex hints that the answer is probably “not really”. To quote Olly Benson from yet another settings API tutorial/example (emphasize mine)

WordPress does make a habit of creating mountains out of molehills sometimes, and the Settings API seems to be a fantastic example of this.  Trying to follow the instructions on the initial page got me hopelessly lost, and it was only when I went through Otto’s WordPress Settings API tutorial that I begin to understand how to implement it.

And the problem is not with the codex, the problem is in the structure of the API itself. Instead of having a simple fast and dirty code like

add_action('admin_init','my_init');

function my_init() {
add_page('title','title',10,'my_options_page');
}

function my_options_page() {
if (isset($_POST['my_value'])) {
validate_value();
update_option('my_option',$_POST['my_value']);
}
<form>
Enter value <input type="text" name="my_value" value="<?echo get_option('my_option')?>
</form>
}

Where all the logic of handling the change of values is placed in the same place as the presentation, the my_options_page function, which makes it much easier to understand and debug.

The settings API basically moves your options handling away from your presentation code. To use it you need to call at least 3 initialization functions to which you have to supply 3 callback functions, and all the handling is done in a “black box” that doesn’t give you any hint for misconfiguration and it is hard to debug.

When trying to use the API I end spending more time to make myself feel good about following coding best practices then needed to code the same functionality in an equally accessible and secure way.

__return_false and its siblings are great way to provide callbacks that do nothing in wordpress

Some of the wordpress API functions like add_settings_section require that one of their parameters will be a valid callback function. If your callback does not suppose to do a thing then you can simply use __return_false that immidiatly returns false as the callback instead of declaring a dummy callback by yourself.

The time has come to clean the net from the prehistoric junk called breadcrums

One guy on the wordpress stackexchange asked how have to have breadcrumbs that show a different “path” the one he currently gets, and this reminded me that I hate breadcrumbs.

Breadcrumbs where created by Jacob Nielsen, and he describes the motivation in the article “Breadcrumb Navigation Increasingly Useful“. I was using the net on 2007 and before so I totally agree that at that point in time adding breadcrumbs to sites had improved their usability. But times had changed and we understand better how users use the internet the the importance of “in site” navigation system, and a catch all default like breadcrumbs have no place anymore on the net.

The problem with breadcrumbs is that they are based on the assumption that content is hierarchical and there is an hierarchical path from the home page to any page in the site. There are several problems with that assumption:

  • A lot of the content on the internet is not hierarchical. This post is categorized as “Rant”, but it is mainly because I don’t like to have an “uncategorized” category. Many blogs and small sites owners categorize because the CMS tools give them (and some times force them) the option to categorize and the end result is that there are totally unrelated content being categorized at the same way.
    Take a look at Jacob Neilsen article itself, what is its breadcrumbs? “useit.com > Alertbox > April 2007 Breadcrumbs “. Right now the alertbox contains 457 links to artcles. If I want to find more information on an article I read there, it is better to leave the site and go for google to make a search then trying to guess which of the links on that page might actually contain the information I’m looking for.
  • For many pages (like in the question) there might be multiple hierarchical paths so which one should you use?
    For this post there is the path of the category “rant”, the tag “Breadcrumbs”, and the date it was published “2012” > “12” > “12”. For personal blog the date hierarchy is the most appropriate, but for technical hierarchy by categories makes more sense.
  • Site owners don’t want users to navigate by hierarchy, they prefer to direct user traffic to a more profitable pages, or pages that they think better serve your needs instead of overwhelming the user with information at an higher hierarchy level.
  • Most sites that care recognized that navigating by hierarchy is frustrating to the user as it requires at least 2 clicks to reach a destination (one up and one down) and improved their in-site search so the user will get to its destination in at most 2 clicks.

In 1995, when the idea of breadcrumbs was created, web sites followed the structure of file systems. The breadcrumbs solution is actually used in the windows explorer in windows 7 but it is just not good enough because yes it takes me 5 levels up in the hierarchy if I need to in one click, but it doesn’t help me to get down the hierarchy to where I need.
But modern OSs are trying to get away from the hierarchical organization of data, Iphone hides the file system from the users, and other OSs trying to analyze user behavior and provide built in search facilities. Sites, being more flexible should lead this trend instead of stick with the old ways.

But wait, what about SEO, isn’t breadcrumbs good for SEO? Maybe it was true in 2007 before search engines standardized on using site maps. Without site maps breadcrumbs where a relatively easy way to provide inter site connectivity that was required to help search engines discover all of the content in the site. Today if your site doesn’t have a site map you either don’t care much about SEO, or you are sure that your site is inter connected.

The only SEO related reason to use breadcrumbs today is that google might use them instead of the full URL in the search results when the URL is very long. This for sure improves the usability of the google results, but does it add value to the site owner? Even if it does, I would add bread crumbs either as RDF (ugly) or use the microdata way but just hide it with CSS. This way google has the data, and you have more free screen space on your site.