Archives for category: WordPress Summer of Code

I’ve been recently working on creating an editor that should allow for the user to alter the layout of a theme. I’m working with the Blueprint CSS Framework and jQuery and am currently attempting to create an intuitive UI (and in this process some sort of page-structure standard).

Things I’m working on/problems I’m rolling around in my head:

  • Moving/Resizing columns within the editor: This is somewhat functional. I’ve created a few iterations on the concept, but the primary problem that I’ve run into is how to intuitively integrate width, padding, and margins in an environment where the user should not be required to know the HTML box-model. Mind you, I wasn’t planning on having each of the three independently integrated, but when using Blueprint, if you specify column spacing using padding (i.e. prepend/append) the column size will visually include that padding (if you use a background, for instance). In some instances, this may be desired. In others, users may prefer a transparent buffer between columns (i.e. margin). Finally, how do you know whether a user wants the buffer before the column or after the column (prepend/append)? I don’t want to give a user too many options, but if there is not a clear and clean implementation of margin, padding, and width, the flexibilty of the framework could suffer greatly.
  • User-customizable grids: Allow the user to specify the column count, column width, and gutter widths and generate a grid accordingly. Currently, this is functional within the editor. However, I will ultimately need to compile the CSS for the theme output, and that implementation will need to be slightly different.
  • Integrating all of this into theme structure: So now you’re wondering–what are you going to do with this editor? Currently I’m looking through the Sandbox code and documentation, and will (at the end of this first stage) hopefully have an output that resembles a customized Sandbox. More on that later.

Questions and comments are welcome!

Advertisements

I had a long meeting with Beau, where we discussed both the specifics and the scope of the project. New things abound:

Apparently WPSoC projects are expected to be “functional” by midterm evaluations, which significantly impacts the deliverables schedule I initially laid out. This is both good and bad—it gives me more time to test and optimize during the summer, but puts pressure to at least have a functioning core by midterm evaluations. As a result, when Beau and I talked details, we tried to categorize items as “necessary” or “that would be nice but let’s leave that for later.”

My project (which needs a name!) will be a plugin rather than a core patch, since plugins rely on the hooks API, which is much more stable than the core. This is awesome in several ways: I have no qualms with less debugging, and I’m already somewhat familiar with WP plugin development. That said, if my plugin could someday serve as the basis for a big core patch, my mind would be blown.

Focus and Functionality:

I want this editor to be useful to both theme developers and the average WP user. Eventually, the average user should be able to make a theme without knowing the first thing about “those codes that run the internet”. But for those of us that do, the themes should be hacking-friendly. To cater to the theme developers, the plugin will have two major functions—to fully develop a theme, and to rapid-prototype a theme.

Rapid-prototyping will serve as a basis for full theme development, and will be my focus this summer. Rapid-prototyping takes advantage of the structure/style divide I first proposed in my GSoC application. Since the user first informs the editor of the structure of the layout, the editor can return a basic theme suited specifically to the user’s needs. The output would be similar to a static theme framework, but include CSS that specifies layout. With a traditional theme framework, the user would have to rearrange the elements to fit their layout. The rapid-prototyping section will serve as a replacement for this process.

Using other theme frameworks:

Keeping the time crunch in mind, if an existing theme framework matches or can be easily adapted to the ideas for my own theme framework (and is properly licensed, of course), I’ll try to base my work off of that. We discussed the Carrington framework as a viable foundation, but I’m not sure if it fits the model I’m trying to establish. Regardless, it’ll be a good reference, and I’ll likely use code fragments from Carrington or another theme framework (I’m looking at you, Sandbox) over the course of the summer.

Making friends with the widget admin:

Initially, I thought that the editor could double as a widget admin. After some discussion, I’ll be leaving widget admin to the WP core (there’s a pretty slick new widget admin in the pipes, and the code surrounding it was described as “painfully complex”). What the plugin will do is widgetize (and maybe semantically name) all sidebars so that widgets and content can be placed anywhere in the framework. In addition, if I have the time, the plugin will add a button on the widget admin page to allow the user to view the layout in a modal window.