Building a WordPress framework
March 20, 2007 — While my posting frequency has been decreasing as of late due to the search (and securing) of a job, working out the details for my impending move to San Francisco, and, rather covertly, working on the design and development of version 8, due to launch at the end of next month. I’ve nailed down its general look and feel in Photoshop, and the actual graphic part of the design is all but done.
After I was done working in Photoshop, I started to write the actual markup for version 8 (theme named “Nightingale”) when I ended up hitting a bit of an impasse. Aerial, the current theme, was built with semantics in mind (such that I could simply swap out Aerial’s CSS for other ones, minimising design time,) and while Aerial worked to some effect, the underlying document architecture was still in some ways restrictive. Aerial’s development taught me a lot about the semantics of the Web, but a simple CSS facelift wasn’t going to help me build some of the insane functionality I wanted into Nightingale.
What is it, then, that Nightingale needed that Aerial didn’t have? A lot of things, really. Aerial was built back before Valerio Proietti’s awesome mootools was released to the public, and thus uses the older (and deprecated) moo.fx libraries + moo.ajax. Aerial, in a bit of a rush to get out the door, missed its intended livesearch and Mint interfacing functionalities, and building them into the Aerial codebase seemed much like an architectural afterthought. Even so, I wanted to build some interface changes into the way comments are displayed and numbered, support some standard microformats, and, of course, work with the most valid code possible. While it’s certainly possible to build such things into Aerial’s own codebase, the end result would have been pretty hackworthy.
As I explained in Aerial’s own unveiling, Aerial was built upon a strict grid system with a highly modular, class-based grid design pattern. That said, I’ve improved as a developer since the release of Aerial, and its ignorance of multiple
With that process, I began my work on Fuselage, a fully-functional WordPress framework, a sort of mootools for WordPress developers. Fuselage is both a developer’s framework as well as a user’s framework, with a backend for options to work with the default markup as well as a full codebase of CSS classes, standardised microformats, and custom template tags to do the things that WordPress doesn’t on its own. While Fuselage won’t be released until version 8 (Nightingale) itself is, I thought it might be worthwhile to leak a bit of information on the framework’s current feature set and how it will work in the end.
- XHTML 1.1 Semantic Validity Fuselage will be built to the XHTML 1.1 specification, with automatic backward DOCTYPE compatibility to XHTML 1.0 Transitional for older posts (or XHTML 1.0 Transitional can simply be forced from the Fuselage backend.) Fuselage will automatically handle content negotiation to serve XHTML 1.1 pages as
application/xhtml+xmlto browsers that can handle true XHTML properly.
- A true grid-based design pattern At the core of every site I’ve made over the past year and a half is a strict grid structure. Fuselage offers a full grid-based CSS framework, allowing a developer to specify features for XHTML markup by using a core class framework. Set your column widths to what you’re looking for in
fuselage.struct.css, and then all you have to do is define column widths in your markup. Want a structural
divthat spans four columns? Simply class it
structCol4and Fuselage will automatically format the div properly. This offers extreme amounts of flexibility to grid-based web designers.
- Standard UI controls Fuselage will offer simple, preset styles for common blog UI elements, from comment and search forms to social bookmarking tool widgets. For greater UI support, Fuselage offers a true breadcrumb navigation engine to help a user retrace their steps to a parent page. Fuselage will also maintain a proper browser history in Mozilla and IE when AJAX is in use by using the RSH library.
- Simple UI Effects Fuselage maintains simple UI effects using the mootools library and defined colours. Want to fade in or fade out an element? Simply class it
- Built-in AJAX Livesearch and Commenting Theme developers using Fuselage can build in AJAX commenting simply by creating one
structAjaxContainer, within the comment list. Livesearch will function much in the way that K2′s livesearch does.
- Support for Common Formats To increase compatibility with standards, Fuselage’s default code will work with WordPress widgets and maintain built-in template tags for generating standardised Microformats such as hCard. Fuselage also maintains formats and template tags for downloads, inline video, and more (including Chris Messina’s figure alignment pattern).
- Built-in sIFR 3 Support sIFR 3 Beta will be worked directly into Fuselage, with standard classes for implementing sIFR (want to turn sIFR on? Simply class an item
Monocoque: The most awesome thing about Fuselage
My favourite feature of Fuselage is Monocoque, the feature that allows the base Fuselage theme to work entirely in AJAX mode, creating what is essentially a one-page theme in browsers that support the full methods of AJAX and necessary browser UI handling. This effectively deals away with a refresh, while using the best methods available to maintain browser history and proper bookmarking.
To conserve bandwidth, Monocoque’s current design negotiates with its own handler, passing WordPress data back and forth into Monocoque’s sector of the page using JSON instead of a raw HTML block. Monocoque will be able to intelligently decipher external links from internal links so that external links will open properly. Of course, Monocoque is the toughest part of getting Fuselage to work properly, but it will also be rather revolutionary (as well as probably taking the whole AJAX thing one step too far, but hey, somebody’s gotta do it.) In this way, Monocoque will allow a Fuselage-based WordPress theme look and act exactly like a Flash application with true degrade-ability and decreased load times.
The war against bandwidth and processing
Unlike Sandbox, which really only provides a very simple core (which Fuselage does with styles disabled, I’ve already drawn out a basic design for Airframe, the stock Fuselage template, which will work with every Fuselage feature and offer a starting point for those willing to create new Fuselage styles or develop their own code using the Fuselage framework. Airframe should live up to the same aesthetic traditions as my existing themes, and, with Airframe alone, the Fuselage codebase can be a great theme for those that are neither design- nor development-oriented.
Now that I’ve explained all of this that I’m working on for the next version of this site, I’m definitely getting back to working on it. Maybe I’ll have something to show for it even sooner than expected. (Okay, probably not, but I’ll have the beginning to a new, multi-part First Class post sometime next week.)
Comments are closed on archived posts.