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.