The Short Story

Elastic is being broken down and rewritten. This is probably a bit confusing, especially for those of you who aren’t WordPress developers. You might be asking “why?”—I’ll tell you.

While the concepts behind Elastic are great, the current plugin limits WordPress developers heavily. It doesn’t integrate smoothly into how we write WordPress themes, and as a result, very few themes use Elastic.

I’m taking the concepts from Elastic and rewriting them to be tightly integrated with the WordPress core.

I’m taking the concepts from Elastic and rewriting them to be tightly integrated with the WordPress core. Some may even make it into the WordPress core itself. Hopefully, as a result, almost any theme will be able to use the new theme editor with ease.

Unfortunately, this means that any bugs in Elastic 0.0.3 will likely go unfixed. Elastic has always been an in-development project, and still lacks many key features. As such, I feel the best use of my time is to move forward. If you’re interested in the reasons behind the change, a more detailed explanation follows.

I’ll continue to update this blog with progress and previews, and hopefully we’ll all emerge on the flip side unscathed. I really want to see the project happen—the positive feedback has been overwhelming. Thanks for all your support.

—Daryl

The Long Story

When I began writing Elastic last summer, I had no idea of the sheer scope of a theme editor. As the summer progressed, I quickly realized that infinite layouts required changing the way WordPress handled themes, and thus the Elastic Engine was born.

Two months ago, I began to redesign this website using the APIs I’d created, and I realized one thing: The default WordPress Theme API is really, really good. Unfortunately, in its current incarnation, Elastic sidelines a large section of the default API. In short, this isn’t a good thing. The missing APIs likely confused anyone who attempted to develop with the engine, and made development much more difficult.

In my last post, I wrote:

“We’re going to be moving back towards the WordPress engine; taking the good parts (because there are quite a few of those), but maintaining our concept of modular theming.”

That still stands. However, while poring over the WordPress source code, I discovered a way to add modular themes to the WordPress core. Not only does this allow developers to take advantage of the WordPress theme API they know and love, but it implements modular themes in a better fashion than the current Elastic engine.

The concept of modular themes was reason for the existence of the Elastic theme engine. This change turns around 1000 lines of code into a mere 30.

Unfortunately, the change implements modular themes in a different way than the Elastic engine. As a result, any interaction between the editor and the new modular themes would have to be rewritten. When I realized this, I found it an opportune time to restructure the project. You see, the editor has two parts—editing a theme’s styles, and editing a theme’s layout. These are two very different tasks, with very different requirements.

As it stands, the editor focuses on layout instead of styles. Unfortunately, layout is both the harder and more demanding of the two tasks. A style editor requires no interaction with a theme’s content (i.e. PHP and HTML); instead, it only has to edit CSS. A layout editor, however, heavily interacts with PHP, HTML, and CSS, and requires the developer to use APIs when writing their theme. In addition, a layout editor heavily benefits from the addition of modular themes.

Rather than tie style and layout together in the same editor, I’m planning on building a style editor with an optional layout-editing add-on. This will hopefully manifest in the form of a Visual CSS Editor plugin (the subject of my proposal for the 2010 Google Summer of Code), and a parent theme that will add layout-editing to that plugin, as well as the necessary APIs.

Separating the two components will impose fewer requirements on themes, and as a result, allow more themes to use the editors. Finally, while I may be able to reuse some of the algorithms from Elastic, much of the editor will be rewritten with a new, extensible core.

Questions? Suggestions? Please let me know.

Today I have the pleasure of introducing a handful of things:
Elastic 0.0.3, a new website, and a new concept.

Theme Engine vs. Theme Framework

You might’ve noticed that we’ve started calling Elastic a “theme engine” instead of a “theme framework.” While you might say “well, it’s only one word”, that word marks both a shift in focus and a solidification in where Elastic is headed.

The difference is that a theme engine controls how the page is loaded, not how it looks.

Put simply, a theme framework is a theme that serves as a starting point for other themes.

A theme engine is a theme or plugin that changes the way WordPress renders themes. The difference is that a theme engine controls how the page is loaded, not how it looks.

While there are about seven dozen accepted definitions for “theme framework”, we decided that there is a clear difference between the two. Theme engines are a level below themes entirely. All themes run on a theme engine, framework or not.

WordPress’ default theme engine consists of the template hierarchy and a handful of other files like header.php, sidebar.php, and comments.php.

For instance, you could write a theme engine that redirects every single page to the wikipedia article on Cabbage, but it wouldn’t be of much use. The Elastic theme engine is focused on creating module-based themes instead of page-based themes. “But wait”, you say,”then weren’t you a theme engine the whole time?”

Okay, so what’s changed?

The file structure. That and some bug fixes, but that’s about it. But seriously, this is huge. We’ve relocated the central library that we required every theme to include into the plugin itself. Authors don’t have to embed the engine in their themes. Instead, they load it with one line of code ( do_action('load_elastic_engine'); ) and a handful more to warn users if Elastic isn’t installed.

Distribution is where this comes into play. Now, theme structure is cleaner and themes can centrally stay up to date with the Elastic engine through the WordPress plugin repository.

The one temporary downside is this: since we’re not currently maintaining backwards compatibility, themes made with the engine may break on engine updates (and will break when 0.0.4 is released). This is why we recommend Elastic for testing purposes only.

Where we’re headed

0.0.3 is less about new features than it is about regaining our focus.

0.0.3 is less about new features than it is about regaining our focus. Elastic’s been a theme engine all along, we just didn’t know quite how to say it. This version has served as the shift to the new file structure. 0.0.4 will be about solidifying the engine and making rock solid APIs that not only support the visual editor, but theme developers as well. We’re going to be moving back towards the WordPress engine; taking the good parts (because there are quite a few of those), but maintaining our concept of modular theming.

Finally, I want to own up. I keep saying that I want your help, but it’s been hard to track me down, and hard to see where the project is going. The redesign is the first step in increasing project transparency, and will soon be joined by our own trac, documentation, and a comprehensive roadmap. If you’ve emailed me about Elastic and haven’t received a reply, I guarantee I’ll get back to you soon.

So enjoy the new site, experiment with the engine, and let me know what you’d like to see. We have a lot of changes on the horizon, so get excited. Once the engine is stable, then maybe we’ll start talking about theme frameworks. They run on theme engines, you know.

P.S.: If you’re going to WordCamp Ireland next weekend, be sure to come say hi!