I am proposing a WYSIWYG theme generator and editor for WordPress. By the end of the GSoC, the theme editor would be capable of altering theme structure and the location of content within themes as well as importing and exporting themes. In addition, the editor would be constructed in such a way that it would be easily extendable and would continue to grow long past the end of the summer.

By drawing a theoretical line between structural and stylistic CSS, the theme editor could drastically rearrange a theme’s structure while leaving its visual aesthetic intact. This will allow users to easily change themes to serve their own purposes, whether it be a blog, a CMS, or another application.

The overarching goals of the WYSIWYG theme generator/editor are the following:

* Provide an intuitive GUI through which anyone (regardless of skill level) could productively edit WordPress themes
* Allow users to create any layout they choose (and in doing so, provide alternatives to the sidebar-content-sidebar paradigm)
* Allow content and widgets to be assigned positions and managed visually
* Optimize theme memory footprint and provide automatic cross-browser compatibility

What follows is a justification for the creation of a WYSIWYG theme generator and editor and an outline of its potential implementation in the form of deliverables.

Background and Justification for Use

I based my ideas off of the following thoughts and questions:

1. To what extent can a user modify a theme without programming?

* Currently, certain themes allow the user to select various parameters to customize the look of their website. What if users could visually edit the wireframe of their website and administer the positions of widgets and content?

2. How can users be encouraged to employ principles of graphic design in their themes?

* CSS frameworks (such as Blueprint [1] and YUI Grids [2]) allow designers to easily combine the principles of print design and web design through the use of grids. While grids are by no means necessary, they encourage a consistent website aesthetic and provide clarity when handling large amounts of content.

3. Can the memory print of a default theme be optimized after it has been customized?

* Customized themes often contain unused and overridden CSS and hidden DOM elements. Can these be automatically removed or avoided?

With these questions in mind, I have developed an outline for a WYSIWYG theme generator and editor. I’ve found that by placing a formal divide between structure and style in CSS a theme can easily be manipulated by the user. Since CSS and HTML are functionally linked, compiling structural CSS and HTML in tandem allows a theme to be built and optimized the fly. By treating stylistic CSS as a separate entity, the aesthetic look and feel of a website can be preserved across structural edits. This flexibility will allow the user unprecedented freedom and speed in theme design and customization.

Creating and embedding a grids-based system within the editor will provide a consistent foundation on which pages can be built. Making themes cross-browser compatible is tedious work and a headache for users of all experience levels. By embedding cross-browser functionality in the theme generator, all themes created by the editor will be inherently cross-browser compatible.

I’m seeking to make theme design within WordPress a natural process. I plan to refer to and learn from other attempts to build a theme editor, such as the now defunct Canvas, when I create my implementation. Ideally, the theme editor will become useful tool for users of all experience levels.

Schedule of Deliverables
Implementation and Deliverables

Please Note: I will be in France between May 25 and June 11. I will have internet access, and I will be able to contribute, but not as much so as usual. In preparation for this trip, I will start work on my deliverables several weeks early. I finish my final exams on May 4th, so I will have more time than the usual student during the community bonding period and can work on my first set of deliverables (which coincidentally will not require as much WordPress knowledge) during that time.

Deliverables will consist of major functional benchmarks:

1. A CSS library designed for positioning DOM elements (Weeks -3 – 1)

* Grids-based, but adjustable
* Calculate values within the library from three of four input values: number of columns, column width, gutter width, and website container width
* Cross-browser compatible

2. An editor that outlines block elements to create the appearance of a wireframe (Weeks 1 – 2)

3. Modify the wireframe by clicking on an element and adding a row/column adjacent to the element, or by clicking on and removing an element (Weeks 3 – 4)

* Automatically adjust affected surrounding elements’ CSS

4. Resize elements within the wireframe by dragging element borders (Weeks 3 – 4)

* Also, the ability to align elements left/right/center
* Automatically adjust affected surrounding elements’ CSS

5. Allow the user to add CSS styles (Week 5)

* Via uploaded file (which could be accessed in the editor)
* Override any user-input styles that would affect the structural CSS
* A potential future modification could allow users to directly edit structural CSS

6. Position content modules within the theme by dragging module titles into wireframe elements (Weeks 6 – 7)

* Titles would initially be found in a list of content modules (such as post content, widgets, menus, etc.)
* The main “content” module would refer to a separate PHP file that would act similarly to the common theme’s index.php and redirect to the proper files for each page type (front page, archives, etc.)

7. Allow the user to create multiple pages per theme (Week 7 )

* If the designer wants various pages to differ in style (e.g. front page and archives), the theme can refer to separate structures for specific pages.

8. Compile and save the theme (Weeks 8 – 9)

* Compile a structural CSS file that only includes the portions of the library used by the theme
* Compile a PHP file that includes the structural framework and the functions necessary to load the page content
* Set a variable that defines the template as “framework compatible”

9. Load and edit “framework compatible” themes (Weeks 9 – 10)

* Generate the wireframe from the compiled PHP file
* Generate the CSS library from the values within the compiled CSS file

10. Documentation and testing/debugging where necessary (Weeks 11 – 12)

Potential Future Expansions

I chose to create a WYSIWYG theme editor not only for its immediate use to WordPress, but its incredible potential. While creating a theme editor will likely prove to be quite the full plate, I have considered several additional functions that I hope will eventually come to fruition.

1. Include Preset Physical Elements, Layouts, and Themes

* Allow users to add complex elements (e.g. SuperFooter, Sidebar-Main-Sidebar) in a single click
* Allow users to apply preset layouts (e.g. Blog, CMS, etc.) to any theme, effectively preserving the style of the theme
* Provide users with default theme(s) on which they can base their customizations

2. A Hybrid Wireframe/Live-Website View

* A preview of the live website with the interactive wireframe superimposed on top of it.
* Allow grids to be toggled on and off.

3. GUI based CSS Style Editor

* Implementing an editor for stylistic CSS would directly complement the structurally based editor, allowing users to customize the entire visual representation of a theme without using a line of code
* This style editor could also implement a typography management tool

4. Backwards Compatibility

* Unfortunately, one caveat of an editor capable of altering theme structure is that the theme must have been compiled by the corresponding generator. Otherwise, the editor cannot make any assumptions regarding the construction of the theme or the effects that will ensue after editing its structure. That said, the theme editor could still act as a visual widget manager, and if the GUI based CSS style editor were implemented, that would remain compatible as well.

5. Markup Editor

* A markup editor could be implemented in conjunction with the GUI, and could update and be updated by changes within the GUI.
* A markup editor could also allow the user to edit the theme’s PHP files.