Ordering in bbPress

June 9, 2007

Begining with a small amend: I forgot to mention in my first post that in all GSoC projects we have mentors. A mentor is an expert from the the open source organization the project is being held for, that should guide and lecture us. My Mentor is Michael Adams (his blog and his bio), from Automattic (the company that created and supports WordPress). So, Michael, greetings from your padawan. : )

Now with the main topic:

I have been looking at bbPress, which is a forum software created by the WordPress folks. It has a “forum order” mechanism which allows reordering and hierarchization at the same time. It is pretty cool and functional. It also doesn’t get in the way of the user (who is not at risk of dragging things unwillingly). It uses jQuery and Interface’s Sortable element, aparently with a little hacking, but not much.

But there is a key difference in the HTML of the forum list in bbPress and the page list in WordPress:

In bbPress a unordered list (<ul>) is used, and when a forum is a “son” of another forum, it is drawn in a nested <ul> inside the parent forum <li> element. So it is pretty easy to know (programatically) when an item is the son of another item and when you drag an item which has sons, their sons automatically go with it. This is also the usual way hierarchies that are supposed to be treated by JavaScript frameworks are represented in HTML. Bellow is a simplified HTML code a nesting of 3 levels in bbPress:

<li id="forum-1">
<div class="list-block posrel">
<strong class="sort-handle">[drag] </strong>
Root Forum
<ul id="forum-root-1">
<li id="forum-2">
<div class="list-block posrel">
<strong class="sort-handle">[drag] </strong>
Son of Root Forum
<ul id="forum-root-2">
<li id="forum-3" >
<div class="list-block posrel">
<strong class="sort-handle">[drag] </strong>
Son of Son of Root Forum

In WordPress, the page list (and all other lists, like posts, categories, etc) is drawn using an HTML table. When a page is nested to another one the only thing that indicates it is a dash (” —”) that is placed in front of the page name. There is no nesting and nothing in the element ids that indicates that a page is the parent of another. This means a lot of JavaScript hacking would have to be done to try to extend Interface’s Sortable to work in such an environment, without altering the structure of the page list HTML. Bellow is a simplified HTML code of a 2 level nesting in WordPress’ page list:

<tr class="alternate" id="page-2">
<th style="text-align: center;" scope="row">2</th>
<tr id="page-3">
<th style="text-align: center;" scope="row">3</th>
<td> — Son</td>

So, I guess in this early stage of development, I am in a crossroad and need to choose one of the following paths:

  1. Leave the HTML structure of the page list as is, and try to work around it. This would mean a lot of JavaScript hacking, specially to work with hierarchies. It could also mean not being able to achieve the same level of functionality there is in the bbPress solution. I believe ordering in the same hierarchy would be feasible, but for hierarchies I am not very optimistic and at this point have no clue on how this would be done and how much work would it be.
  2. Change the structure of the page list. It would make it possible to reuse most of the bbPress JavaScript code, that is built upon Interface’s Sortable. So, if you sum it up, there is a lot of reuse. This would mean having to change the PHP code that generates the Page list, and also having to modify (slightly) the AJAX that deletes the pages. The page list appearance would also end up changing a bit, since it would now be drawn with <li>s and <div>s, but I don’t think it would represent any huge impact for the users. So, the end result would be a lot less JavaScript hacking, some easy-to-do PHP coding, a small change in the page list appearance and an interface that would be consistent with what is used on bbPress (very effective, unobtrusive and nice to use).

My choice would be to go with option number 2. I guess it would make things a lot easier and tighter. I would also have more time to extend the ordering paradigm to other parts of WordPress (Categories, for instance).

The greatest “disadvantage”, if you put it this way, is that it would be the start of a “paradigm” shift in WordPress administration HTML, where lists would start to be drawn with unordered lists instead of tables.

I would like some pointers from Michael and others from the WordPress community.



  1. Great post Bernardo.

    There’s no problem at all in changing the markup of the WordPress admin pages. So don’t let the current layout constrain your ideas/development.

    With that in mind, it’s probably best to leave the actual WordPress code alone at this stage of the project. I suggest writing a couple static HTML documents with some hierarchical content and writing the JS for that first. See what structure is the most natural and makes the code simplest. We can worry about plugging it into WP later.

    Since we’re aiming for a generic jQuery plugin rather than anything specific to WordPress, it’d be nice if the JS could handle a few different sructures. However, we are writing this for WordPress. It’s be a waste of your valuable time to make the code as generic as possible when we have a specific use in mind.

  2. Great to hear that, Michael. I am going to do what you suggested and begin the work with HTML and Javascript only. My college is about to get off my back for a while now (the semester is about to end and we’ll have some vacations), so things should begin to flow faster now, as I have more time to put into it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: