owen

I’m going to geek out for a minute here, so be warned.

I’ve started working again over at Red Alt. Red Alt is an outlet for my web development stuff. I eventually plan on moving all of my WordPress garbage there, away from my personal blogging. But I’m having a couple of issues.

I wanted to have some compelling features for the site when it opened, and I had just gotten too lazy about working on the site. So yesterday I wrote some actual code, and I’ve sort of hit a wall in my requirements/coding stage.

Here’s the application: I want to create a web service that walks users through creating WordPress output pages. The application would build an index.php file and wp-style.css file based on user input of their preferences. The resulting application would put an end to the generic green WordPress template for new users, and would give more advanced users a higher springboard from which to dive into custom page designs.

I need to digress for a moment. I don’t want to use this entire post to lament the WordPress 1.3 CVS additions of header/footer and alternate template functionality, but something needs to be said about it. I am not convinced that it is well conceived. The want for these things is obvious, but the implementation is poor. Perhaps someone will explain it all to me.

The way I was thinking of creating new templates was by including a kind of “choose your own insertion” language. For instance, a base template might be stored in the database for a certain layout structure. The template would include special tags that would alert the application that user interaction was required.

Different types of tags would do different things. One tag would request that the user select a color. The selected color would be used anywhere that the template specified that tag. A different tag would cause the application to include a separate code snippet from the database, which might contain other tags. Another tag would ask the user to select from a list of modules the ones that he would like to include in a specific area of the template.

After the application compiles all of the choices with the code snippets from the database, the process would repeat until there were no more special tags. In the end, the output file would be made available to the user for download.

Part of my issue currently is that the system will require more than one file for output. The PHP template itself will be produced and at least a corresponding style sheet. Each of these files may have to reference the other &emdash; If a module included on the template requires special CSS, the CSS will have to be added to the CSS output file in the correct place (the end?).

Perhaps the output CSS file shouldn’t include any CSS that is not directly used by the template. So each code snippet row would have an associated field for CSS that would include required CSS rules for that snippet. I would need to include a possibly complicated routine to ensure that no rules were duplicated, and would need to verify that no class names repeat within the database that aren’t supposed to overlap.

This doesn’t account for the crazy new wp-header/wp-footer stuff, which offloads the navigation elements into a separate file. I like the idea that I can create different templates to display content, but I would think that I could change the navigation along with the content display. I don’t like that I would have to create three files (header/footer/template) for each page type if I want things to be just a little different on each page, and would rather use one whole file with navigation embedded instead. Anyhow…

I suppose that I just need to set a limit on what I want to do and how dynamic I want it to be. I was thinking to include a corral of stock photos in the builder, too. These photos could be inserted as interjections in the web design and colorized to match the color palette that the user selects for his site. I even had some plans for a dynamic background pattern generator algorithm that could produce Squid-like swirling backgrounds at random.