Before reading this post, check out my thoughts on how to implement a new taxonomy system using CCK. It figures into my idea here as well:
http://groups.drupal.org/node/246#comment-1625
Proposal: A theme/module that manages each *.tpl.php file for the site admin by storing the layout in the database. For each handled hook (aka hook.tpl.php), the system would create a CCK type. The type would contain a Title and a text field. The textfield would be the place where the admin could enter the theme code. Each *.tpl.php would just be a shell to pull in this data from the currently selected node.
Each theme file would like:
<?php
print $data_from_node;
?>Themers could still extend .tpl.php files and just use the $data_from_node variable if/when they wanted it.
Pros:
- Admins could have many theme nodes in the system. They could swap them in and out at will
- Provide a good framework for a GUI based theme system. Imagine an extension to this system that allows you to drag and drop all the variables supplied by _phptemplate_variables($hook, $vars).
- No more file system for themers. Yay!
Cons:
- Possible performance issues
- Might be harder to manage for some themers who use apps like Dreamweaver to make their themes
Thoughts, implementation ideas?
-M
Comments
Well...
Pardon if I belabor the obvious, but I put this foreward solely for the sake of due dilligence.
In essence, I can see this being very convenient; I really liked the Polder theme and the style module that came with it. But I'd also be cautious about this in the sense that Drupal theming is by no means mature and this would necessarily have to be developed tangental to existing efforts. Besides questions about how modules are using themable functions, cck, views, etc., Adrian has already at least hinted about PHPTemplate 2.0, more work is being done on the forms API, etc.
And the first thing that comes to mind is that Polder became orphaned following the next core release, which brought me right back to square one.
Something like this might actually be less work a little further down the road, or it might wind up being even more complicated after the next release. No doubt you understand this much better than I, but for my own part, even though changes will doubtless still be made to the API and the overall process, I still think the best approach to simplifying theming overall is to focus on how themes are organized and documented.
Not mutually exclusive
You are certainly right. The most bang for the buck is consistently documentation. However, that doesn't mean we can't pursue other avenues of making themeing easier.
Here are a couple more benefits of the system I propose:
Mix and match theme components: With normal themes, one has to copy foo.tpl.php from one theme to another to try out or change things. With my system, an admin has a drop down list of foo nodes to choose from. He/she can flip back and forth by changing a system variable, instead of 'mv foo.tpl.php foo.tpl.php.old; mv ../othertheme/foo.tpl.php .', etc
Online/built in GUI editors: The real inspiration for this post was some recent work I've been doing with the Yahoo User Interface CSS Grids system (http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/mfredrickson/...). This module has a function that takes in a Forms API like array and spits out a grid structure. Right now, admins can use an included module to pick some nice defaults for the main and secondary columns (or just have one column). It works pretty well but doesn't give the admin that much freedom. And the code is going to be a real headache to maintain.
I'm thinking a cool alternative would be to provide a drag 'n' drop JavaScript interface that does the work. Of course, this needs to render to XHTML eventually, so why not just store that text in the database while we're at it. Also, by running in drupal we have access to all the variables being supplied to each .tpl.php file. This means we know what data is available. Dreamweaver can't match that. We're not there yet, as I say above, but these are just my early musings.
On the subject of future improvements to themes, I would love to see more hooks that themes can implement. Not having per-theme unique settings is lame. Not having the ability to create a '/mytheme/dynamiccss/' menu call back is also lame. I've solved this for nautilus by using an additional module and a style.php, but I'm not happy about it.
-m
The drop never stops moving.
The last thing I'd do is discourage anyone from contributing however they saw fit, and more so, you've definately got some good ideas.
Again, though, my concern is simply that Drupal has an arguably deserved notoriety for not being backward compatible, some wit summarized this as "the drop never stops moving" and its a good analogy. With this, it seems possible that it could be considerably more work in the long term than it appears, or even have the side effect of shifting a lot of support requests to your plate.
I'm not an authority by any stretch, however -- I'm actually best at doing things entirely the wrong way. I also posted a link to this topic to the themes mailing list and asked if anyone came away with the same impression, and that one person agreed is enough that I think it'd be worth getting on the list and getting some feedback from Adrian about PHPTemplate 2.0 and where everything is headed.
No doubt, there will be a lot of people adding to contrib who will end up at cross purposes with core simply through lack of communication.
Otherwise, I completely agree vis-a-vis grids.css, and I can say this as someone who put a lot of time into theming before learning how completely evil IE 6 really is. I tend to be quick to defend MS, I've worked for them and they are far too easy to blame for things they have no control over. That was when I stopped reading cheat sheets to find out what did what and started looking into what real-world design was like. I'm not an expert but I am pretty sure that I've bookmarked and read anything of value accessible through stumble upon.
On the downside of all this? I'm beginning to suspect that it might be worthwhile to pay at least half as much attention to javascript as I have PHP. I wouldn't argue with the value of AJAX so far and I've seen it applied with tabbed lists, nifty corners and the like to great effect, but something in the back of my head is saying "No! This is just patching the problem! Don't give in!"
But what do I know? I had no net access for a good three years after it started becomming publicly available outside of schools. Having spent too much time on BBS, I couldn't help but feel that not only was it not elite enough, but that it was much more a "now" solution than a good one. I got on, finally, I also traded my Amiga for a PC. Then I started a web page in spite of being adamant that the world didn't need another one, let alone mine. If I'm gonna get drug along... Yeah. TO DO: javascript Sigh
Theme hooks as nodes
I agree that my post does not take into account phptemplate 2. What wonders will the future hold? Only Adrian knows... ;-)
I have actually been thinking that my proposal is closer to another theme engine, than a phptemplate theme. PHPTemplate works off of the file system. This proposal would work from the DB. This is scary and exciting. It is closer than I originally thought to Ber's brickslate idea, which I think is good, because I think brickslate is a slick idea.
Allow me to refocus this debate: Should theme hooks (e.g. theme('page'...), theme('block'...), etc) be nodes? What are the pros and cons? What benefits does this provide to new themers? What benefits to old themers? Is it easier to upgrade a theme in the db or one on the file system?
As we've been talking about one pro is that we can create our own theming interface in JS/Flash/Whatever to stick on top of Drupal. While such a system could also just output some PHP to stick in a .tpl.php file, using nodes might be a cleaner solution.
Discuss!
hooks in nodes
This probably would work a lot better as an engine rather than attempting to keep tabs on phptemplate and its development.
Certainly one could take something like this and design it for people who didn't want to deal with the complexity of existing themes. Here's an example that's done as an excel spreadsheet. In all, I'd tend to think that the example would be a little more complicated than most newbies would prefer, but it also demonstrates an inherant limitation in the idea as a whole, since what can be done is pretty much to produce variations on one type of theme.
Even still, as far as being stored in the database goes, it'd be simple enough to export a dump of the table or tables used to store the nodes, but then you'd have to be able to import them using unique nids, etc. -- not sure if the Drupal installer would help with this or not.
Something else to consider is that you'd also want to make sure you were pretty much doing away with the need to keep anything in a theme directory as well -- you'd want to make sure that you were either handling graphics through the Image module or importing them into the database directly (I THINK this is possible, not sure), same with javascript files, etc. -- on the whole, you'd more or less want to create a lot of different options for themes and then provide a way to mix and match them with a GUI of some kind.
There's a module that allows theme creation now (it may be still limited to 4.6 or somesuch) but in all, its pretty much just a text editor to begin with. You could alternate between a gui and an editor that allowed the user to edit the text of the theme directly, but again, doing so will also add another layer of complexity to the thing.
While full support for CSS 3.0 is still a ways off, I can't help but suspect that its going to start getting hacked into themes before there's anything like full support, regardless. In the same sense that nobody wanted to limit design simply because IE 6 etc. didn't handle it well, I've already seen one site that went out of its way to make use of CSS 3.0 knowing that people would have to be using IE 7, Firefox 1.5 etc. to view it.
Then again, I still think you'd be way ahead to talk to the people on the themes mailing list to get decent feedback for this sort of thing.
not so sure
i think designers like the filesystem focus of our current theme. thats how they usually operate. but an engine that does it differently is interesting
have a look at olav theme and the phptal engine. phptal is quite cool in that the *.tpl.php files are real xhtml and can be edited in dreamweaver easily. they also contain dummy content which is helpful for designers.
anyway, thanks for posting this.
Also see
Also see http://groups.drupal.org/node/184. In railfrog we only use chunks. (aka nodes). Cool thing (and reason behind the concept of brickslate) is that each brick (somefile.rhtml theme file) is pulled into the database as ... a node (chunk).
In other words:
You design and develop a theme, then you "publish" it, meaning it gets pulled into the database. Each file (each themed function) then becomes a node. From then on, you can edit your theme inline, online.
Nice pipe dreams, once each themed function (brick) is a chunk:
You can give permissions (only registered users get NiftyTheme_image(), the rest just default theme_imgage output), assign conditions (only on friday third I will publish this node, only on friday third will the CoolLogo show up)
Etc.
http://www.webschuur.com | http://bler.webschuur.com
I read your brickslate
I read your brickslate writeup. One thing you point out is that drupal doesn't have a generalized relationship API, which is why brickslate would be difficult in Drupal.
In CCK, the node reference field is a generalized relationship API. It is no coincidence that my proposal relies heavily on CCK.
-M