The road to Textpattern 5

As Textpattern 4.3.0 draws nearer to a release, it’s time to look forward a little to Textpattern 5. This weblog entry holds important information — especially for plugin authors and admin themers — to help gear up now for the proposed changes in Textpattern 5.

Update 05 Nov 2012: Please note that this announcement has been superceded.

Textpattern 4.2.0 and earlier has a predominantly table-based admin side. In some places tables make perfect sense when displaying tabular data; on list pages, for example. In other places (e.g. Images panel, Write panel) it’s a bad use of space and very restrictive for plugins and themes.

The good news is that where 4.3.0 is hamstrung by tables, Textpattern 5 will not be. The admin side will be remodelled wherever it makes sense with a more semantic markup system (perhaps HTML5 if it’s accepted by then).

To that end, we need a way to bridge the gap between today’s Textpattern admin side and tomorrow’s Textpattern 5 that won’t break huge swathes of plugins and admin-side themes. Textpattern 4.3.0 is that bridge.

If Textpattern 5 launches without a solid user base of plugins and themes, adoption will be slow and upgraders will—quite rightly—not move forward without their arsenal of plugins. This is largely based on a gut feeling and some anecdotal evidence that plugins are the backbone of many CMSes.

Come with me if you want to live

The idea is to introduce new classes, IDs and wrappers in the 4.3.0 release that plugin authors and admin theme designers can begin to use. The crucial factor is:

Even if the tables or other markup falls away, the class names and IDs will prevail in the new markup wherever possible.

This means, to all intents and purposes, more plugins and themes are likely to work out of the box in future Txp versions if we all start to use these new selectors from 4.3.0 onwards.

The history of things to come

Under 4.3.0, virtually every admin-side widget/logical group of widgets can be directly accessed without chains of descendent selectors or back-and-forth jQuery manipulation. The hope is that the underlying markup can be changed without affecting plugins and themes too much. Of course there’ll be casualties, but we hope to mitigate these.

Getting to r3372 has been anything but a smooth ride because the current names, IDs and classes leave a lot to be desired in places. To preserve backwards compatibility in the 4.x branch, we can only add stuff, not rename existing entities.

The sections below give some idea of what’s going on beneath the 4.3.0 admin side—which looks fairly similar to 4.2.0 to the untrained eye ?. If you have Firebug installed, feel free to browse around the new names and become acquainted.

Beneath the hyper-alloy combat chassis

There are a number of guiding principles behind the changes:

  • Remove the need to prepend DOM node selectors with HTML tags; make every element (wherever possible) or group of related elements directly, independently addressable
  • Multi-word classes use a hyphen between words because IDs have (usually) used underscores in the past. The hyphen is a tradition that some tabs already employ so it made sense to continue it
  • If a control didn’t have something to group it (e.g. there was no containing <div>, like the left sidebar of the Write tab around ‘Advanced’ or ‘Textile help’) then it now has one so the entire block can be switched on or off or moved with comparative ease. The id of the containing block has _group appended to it (e.g. id="advanced_group")
  • Where a control already had a unique ID, a class has usually not been employed. A class may be added at some point if necessary; only time will tell
  • Semantically-named wraptag elements have been added (usually as a <div> inside the tables) so that when/if some tables are phased out, the new wrapper names can be used in future admin-side markup. See below for a concrete example.
  • The pages themselves have a class named after their primary navigation link. So, for instance, all the pages under the ‘Content’ panel have class="content" on their <body> elements
  • The class names are uniform across tabs to give flexibility in targeting rules at varying scopes with minimal rule sets. If you only want to target stuff on a particular page / group of pages without affecting others, you just need to prepend your rules with the ID (or class) of the HTML <body> tag

Regarding the wrapper containers noted above, here’s an example from the Write tab. This is the existing markup:

<td id="article-col-1">...</td>
<td id="article-main">...</td>
<td id="article-tabs">...</td>
<td id="article-col-2">...</td>

New bloaty, class-soup markup in 4.3.0:

<td id="article-col-1"><div id="configuration_content">...</div></td>
<td id="article-main"><div id="main_content">...</div></td>
<td id="article-tabs"><div id="view_modes">...</div></td>
<td id="article-col-2"><div id="supporting_content">...</div></td>

Semantic markup in 5.0.x:

<div id="configuration_content">...</div>
<div id="view_modes">...</div>
<div id="main_content">...</div>
<div id="supporting_content">...</div>

You can see from this how important it is to start using the new names as soon as possible. Any plugin or theme that expects <td> elements to exist, or relies on some implied node order will likely fall over in Textpattern 5.

There’s a storm coming in

Tables will probably be retained in list-type areas because they contain tabular data. These include the Articles, Files, Links, Comments, Users, Visitor Logs and Plugins panels. But the markup of the tables has been sharpened now:

  • Header rows at the top of tables are wrapped with <thead>
  • Data rows are wrapped with <tbody>
  • The extra rows at the bottom of the table containing the multi-edit dropdown and any ‘Show details’ checkboxes are wrapped with <tfoot>. The subcells are also individually named (e.g. class="multi-edit")
  • Column classes are named after their column names in the database wherever possible, or after what they represent if the database column is ambiguous / non-standard
  • Columns are also grouped with additional classes where it makes sense. For example, all date-based columns have a date class as well as one of posted (and/or created) and modified. This allows someone to disable/enable or otherwise visually group related columns of data, either with or without the header row
  • Article categories are classed as category1 / category2 and the generic category
  • Sub-items—usually a ul/@li@ set—that appear inside an individual table cell are also classed wherever possible. In the case of the Articles tab, there are action-edit and action-view classes on the ‘Edit’ and ‘View’ links respectively
  • Each row is classed as odd or even so zebra striping can be performed. This is arguably not necessary with nth-child selectors, but is convenient
  • The multi-edit checkbox column has class="multi-edit" the same as the multi-edit controls beneath the tables

Say… that’s a nice bike

While the tables remain in some areas, other places will get a make-over. Most of the details pages have been positioned so the tables can be removed to leave behind the sleeker markup. Specifically:

  • The class names of the relevant items from the database are the same as on the list pages
  • Groups of controls usually take the prefix of the item they represent, e.g. on the Files tab, the three rows that give file information are class="file-info"
  • The centre pane in the Write tab now has div wrappers around each of the three views (Text, XHTML amd Preview) so each can be targeted individually
  • Text labels are put in a <label> wherever possible or inside <p class="label">...</p> if not
  • Sidebar content such as tag builder lists have a wrapper div/class on each group so they can be accessed individually if required (e.g. to place a new item above/below a specific existing group). The expanded state of each group is now remembered
  • Each item in the tree on the Category tab has its ‘level’ inside its class, e.g. class="level-0" for root nodes, level-1 for immediate children, and so on. If the category tab is laid out in something other than a tree, this allows the hierarchy to be maintained visually through CSS
  • Status radio button groups have multiple class definitions for convenience: the whole group is class="status" and each individual radio button has two classes: its name (Draft, Hidden, etc) and its numeric status identifier (status-1, status-2, etc.)
  • An ‘active’ class is employed for the currently selected radio/checkbox items and their containers. In the Write panel’s status box, this leads to the comical class="radio active" ?

Other CPU upgrades

  • The Advanced Options node on the Write panel has been split out into a set of logically grouped twisties; the state of each is remembered:
    • Advanced Options contains Article/Excerpt markup and override form
    • Custom fields get their own node; if there are no custom fields defined, the group heading remains but has class empty added to it. This preserves the node for those plugins/themes hooking into it (and preserves the callback) but allows a theme/plugin to hide it if desired. To this end, a CSS rule has been added to the classic theme with .empty {display:none;}
    • Article image has its own node
    • Meta info (keywords/url-only title) have their own node—still not convinced that ‘Meta’ is the right sort of label here. Anybody have any suggestions?
  • The Pages panel has a ‘Create new page’ link
  • The Forms panel has ‘You are editing form nnn’ above the textarea. The list of Forms on the right are now in collapsible groups which saves a little horizontal space so the edit area can be wider
  • The Style panel has ‘You are editing style nnn’ above the textarea and the ‘Create new style’ button is above the list on the right hand side. This means the left column is redundant so it has been removed in favour of widening the stylesheet textarea
  • Each column on the Pages, Forms and Styles panels have the following IDs:
    • tagbuild_links (where appropriate) for the left column
    • main_content for the central column
    • content_switcher for the right column

Uzi 9mm required (a.k.a. I’ll be back)

Two tabs that still pose problems are the Sections and Preferences panels. Sections are just a complete nightmare to handle elegantly and need significant brain power devoted to them.

For the Preferences panel, current thinking is:

  • Move Languages to its own panel (i.e. Languages). Even though it is a preference of sorts, it kind of transcends a basic pref setting due to the language management system.
  • Remove the remaining 3rd tier navigation items so that Preferences becomes a sole panel, thus there is no more ‘advanced’ and ‘basic’ distinction, just a single page of collapsible nodes containing all prefs, plus a save button
  • Consolidate the existing prefs into better groups. Obvious candidates are to combine the commenting prefs into one group instead of splitting them between basic/advanced panes.
  • Add a ‘Plugin’ node on the Preferences panel. Beneath this, a plugin that has registered its preferences intent has its own entry. When the plugin’s name is selected, its prefs are displayed directly on the Preferences panel like any other Textpattern prefs. Plugin authors would of course still be free to insert prefs anywhere else in the structure—or write a custom tab to handle them—but for simple settings this would be a convenient shortcut and may help reduce clutter on the Extensions panel.

The future is not set

That pretty much covers the ethos behind the changes. Now and over the coming weeks, please take a look under the hood of the new admin side and if you like what you see or have any thoughts on how things could be done better (or perhaps have some better naming convention) speak up now! Once 4.3.0 is out, we’re stuck with it.

It would be remiss not to mention the fine folk who have kindly assisted with guidance, mods, feedback, suggestions and all important road testing so far while this has been in development over the past six months or so. In no particular order: jakob, renobird, phiw13, redbot, jstubbs, maxvoltar, net-carver, squaredeye, masa, and Sam (brown). You’re all oceans of awesome!

Comments

  1. This has been totally awesome to read, and is a bit scary to comprehend. I’m quite impressed with the forethought being put into this transition.

  2. This is great news Stef and has been a long time in the making. I for one am glad these processes are being put in place to help bolster the future of Textpattern. Really looking forward to it.

  3. That is an interesting read Stef, and as Sam quite rightly said, “This is great news”. TXP has been a fantastic tool & resource for me for the last 4 years and I’ve built a lot of websites using textpattern as the backend. The steps being taken now to bridge the gap between 4.2 & the TXP 5 will future-proof Textpattern for years to come.

    Keep up the good work!

  4. This is indeed great news! Thanks for the update Stef. Exciting times ahead.

  5. Great post, Stef, and superb work on re-engineering TXP guts for being both future-proof & backward-compatible.

    As always, I’m stepping in a bit later to share ideas, but as you say you are inviting us mere mortals to give some feedback, then, here I am.

    The only feedback I’ll give right here right now is regarding one minor error in the post itself. On the “Semantic markup in 5.0.x” block code, there are spaces (or better say, multiple strings) on the id attribute, and that’s a no-no in the real world.

  6. Darn Stef. You broke my stylesheet :-(. Naughty boy. Required changes to all of 7 lines and 106 characters.

    Seriously. That is a nice step forward. For real. Now I’ll have to dive into it to see if some tidbits can be improved or have issues…

    One thing I’d like to see is a wrapper div, or html5 section around the main tables (#edit mostly and #lists). It will be useful once most of those tables go away (although I hope that the #lists tables will stay – they do contain tabular data, after all).

    Looking forward to an improved and more flexible Prefpane.

    PS – I don’t see any issues with the underscore that maniqui mentions. Displays just fine here.

  7. I remember seeing, at some point, changes to the section tab allowing for an inline display method for section creation and management (crockery perhaps). Any plans for the section tab prior to 4.3?

  8. Congrats fellas. Really cool to see forward progress.

  9. @stef:
    1. I’m happy you’ve come to like the <thead> / <tfoot> combo. It makes for a real good improvement to all the data tables.

    2. About the extra div, I see a couple of advantages. One is to add a more useful ‘wrapper-ID’ than what we have now – most of those tables have either #edit or #list. Having that ‘wrapper-ID’ already in the code might make life easier for extension authors (they can start using it as a hook for whatever they try to inject or manipulate) and stylesheet authors. You’re right about the data-tables. Strictly speaking, those don’t need it, except for that unfortunate choice, ref ID. A few years ago we added (more semantic) classes to all those tables though.

    As for <section>, yeah, that only validates as HTML5. A <div> will do fine.

    3. As for the underscore. I checked first in Camino (default browser), then Safari 5. I now had a look at Firefox running on XP and Linux/Ubuntu and didn’t see any problems either, but FX is configured with a different monospace font than the default (Courier New on XP, iirc; I use DejaVu on both XP and Linux).

  10. The usual ‘Thank you folks great job’ is ‘de rigueur’.

    Txp has always been straightforward and wise by doing early move to Standards and so embrassing the right choices, since it’s initial conception. Dean’s initial choices and legacy are huge.

    And this is still the best we have in common, appart from the software itself, a unique project where Devs & Designers are working together.

    Standards please yes, they are the cement.

  11. The underscores in the IDs render just fine in Firefox Nightly/pre-4.0-Beta-1 builds, with its improved font rendering backend. ;-)

  12. Stef — Thanks for this fantastically detailed update. I really appreciate the team’s hard work and focus on this issue, because a more semantic approach will make jQuery manipulation and theming infinitely easier. As you move forward in development, I have two suggestions, one big and one small.

    # BIG: Use HTML5. It’s worth it. Leaner code overall, and some of the more subtle form types could really be a nice touch for those who use browsers that are not IE. # SMALL: For the preferences section, can we drop the yes/no radio buttons and just go with simple checkmarks to indicate whether something is set? The whole yes/no thing seems kind of redundant, and in a few cases, forces the actual text surrounding the preference to be worded oddly.

    Great work.

  13. Wow! I think that might be the most detailed look at the future of TXP ever.

    Thank you Stef.

    :)

  14. Any news / ideas on having native access to external template file access without having to use the Allow PHP in Pages rule?

    see: USING FILES FOR PAGE TEMPLATES IN TEXTPATTERN
    http://hicksdesign.co.uk/journal/using-files-for-page-templates-in-textpattern

  15. Wonder why my post asking about external files for templates was deleted?

    Anyways I wanted to know if any thoughts had been given to have a native way of editing Templates outside of the DB rather than use PHP pages includes as outlined in the HICKSDESIGN journal today

  16. @Giovanni: Your post hasn’t been deleted. I think there’s some cacheing going on in this page, because new comments don’t show up unless I do a complete, hard refresh of the page. Grrrr.

    Anyway, to answer your question: no it’s not under consideration at the moment. There’s currently at least one plugin that allows you to do this, and a Firefox add-on that allows you to edit textareas directly in your favourite text editor.

  17. Nice post Stef.

    I should remind all admin theme designers that any existing themes will need to be updated to work properly with Txp 4.3.0

    I have already done mine but I won’t put them up on Textgarden until the new release happens. If anyone would like a copy now just email me and I’ll zip it over.

  18. Hello Stef

    Please tell – when you plan to release TXP 4.3?

  19. Yes, …please tell – when you plan to release TXP 4.3? I am waiting new release!!!

  20. Stef, this is good news and I’m sure will serve TXP well but the admin UI is only part of the problem, personally I think if you try retain plugin compatibility in TXP5 you’ll be severely limiting possibilities. Let me explain…

    I’ve just come back to TXP after a long hiatus and being brutally honest it’s feeling really old. Maybe I’ve been spoilt by other CMS’s but my dream for v5 would be:

    • Database abstraction so people aren’t limited to just MySQL
    • Proper model associations with hooks for plugins to create their own models and associations (article has many images, article has a event, etc…)
    • Abstraction of the models, views and controllers, MVC
    • All the models and their attributes using the same naming convention
    • I even envision the core models being moved into extensions which can be enabled/disabled as needed. I guess this is going back to zem’s idea of ‘elements’ in crockery
    • A proper testing framework so core and plugin features can be checked and verified throughout development

    As you can guess these would be big features and changes for TXP. I believe trying to keep plugin compatibility would be next to impossible. Yes it’s not great to break the popular plugins but in the end it’s about building a good foundation which will serve the community well for another ~7 years. We’ve seen before how people have taken over abandoned plugins and updating them for the latest releases — why would v4 to v5 be any different? Undoubtedly there will be a long alpha/beta cycles which will give plugin authors time to update their plugins.

    I really do hope some of my ideas are on the roadmap of TXP5. I would even get off my arse and help out with patches etc; if I knew my time would be well spent.

    I guess what I’m really trying to say is don’t worry about retaining plugin compatibility. Textpattern is great, the core developers are doing an amazing job and the community is so friendly and helpful. I’m sure in the end it will all work out. And let me know what I can do to help ?

  21. @Stef Sorry it took so long to get back to this – life got busy. The code I was referring to is here : http://code.google.com/p/textpattern/source/browse/development/crockery/textpattern/elements/txp_section/txp_section.php

    At one point this branch was operable to some extent and the visual presentation was very pleasantly inline. The code is extremely divergent from the current state of affairs though, in the direction of subsections from what I can tell. It may not be of much service for the matter at hand.

  22. Hi there,

    how about (please don’t punch me!) external templates ? We have tools like Coda,BBEdit,Ultraedit,Vim,Espresso all support external file editing via (S)FTP / DAV.

    Cheers,

    b

  23. Can’t wait to check TXP 4.3.0 before TXP 5… Awesome!

    Thanks to all developer!

  24. @ Stef
    First, great to see that something is going on regarding the admin side!

    You mentioned a plugin in reply to Giovanni that let you edit your template outside of DB. Did you mean cnk_versioning or something else?

Commenting has expired for this article.