Transferred from my blog at Dries' request. First, the blog post:
Today on drupal.org I just posted my ‘personal battle plan’ and it includes a fairly large project that doesn’t actually require a great deal of Drupal experience to help on; it requires just enough coding knowledge to extract the right amount of code, create the files, and then — probably the only place where a little bit of coding knowledge is really needed — effectively separate logic from presentation without adding too much processing time to the code.
The idea here is that I think there should be a project called the Drupal 5 Themer Pack which includes every (or nearly every) theme function in Drupal 5 core as a .tpl.php and the corresponding template.php code. Right now I envision the structure that each Drupal ‘system’ might have a file such as template-forum.php which is included from your standard template.php. It includes all of the forum theme functions, and each one has a .tpl.php for presentation. This code does not change the output in any way but makes it easier for Drupal themers to identify the theme functions they need and actually modify them.
As a bonus, it might include alternate versions — maybe a PHPbb-like set of templates for forum, or whatever. Plug it in, make the changes you need, and go.
There is a fair bit of work here, but it’s also learning work — because in so doing, whoever extracts the theme functions will be forced to learn something about how Drupal actually does that part of the code. It could lead to recommendations for patches for future versions of Drupal to improve the theming functions, and it could make life a whole lot easier for themers who don’t want to have to know anything about code at all, because they can take these things that are already created for them and simply tweak them. That’s a lot easier than doing the actual extraction like they have to do now.
Right now I am basically doing an exploration of who might be interested in contributing to this project, and working to organize effort and get something good going here. I’m thinking of pitching this to the Drupal Dojo as something that students can work on as a learning exercise AND contribute to Drupal.
Any thoughts? Want to work on it? Make sure I have contact info — as I’ll be putting together a list.
Second, Dries' response:
Earl, for Drupal 5.0, Vlado, Adrian and myself spent a couple of weeks trying to move all theme functions out of the modules into stand-alone phpTemplate files. The idea is that designers should simply copy the template file and start modifying it, rather than having to convert a module into a theme themselves.
We created a script that does just that -- and that got us 95% there. It removes the theme functions from the modules, converts them to template files, and stores the template files in the module-specific directories.
It all worked (except for the last 5%), but the problem we ran into is that it turned out to be 10% slower.
I'm hoping you and others can pick up the work (with help from us), and help us get this _in_core_. I think this is a case where we are better of changing the default behavior. It makes too much sense not to do it in core -- plus, we already started working on it.
What needs to be done is "simply" this: we need to make it 10% faster. :-)
Let's talk more about this on the mailing list?
My response: Yes, there are absolutely aspects of this that are a good push toward core. However, there are a couple of important things here: 1) Drupal 6 should be 6 months away, and this kind of project can benefit now, as well as having a future benefit by having the bulk of the theming work be done now. By being useful now, people who might not otherwise participate in this work might participate and contribute. 2) I think it's important to get more themers participating in Drupal, and making this easier is a good way to do it, and to follow up 1, can be a major benefit now. 3) I don't have a solution for the 10% slower yet. 4) This project mitigates that 10% problem by presenting the pack as a pick & choose type deal. You don't include the templates for items you aren't overriding, but for themes that do want to override them, they drop the code in, add a line to their template.php to include the right stuff, and start modifying. To refute 3) above, I might have a solution to the 10% issue which involves template compiling -- I believe the bulk of the slowdown comes from having to read template files into memory over and over again. Compiling all the .tpl.phps into a single file could mitigate that effect. I don't know, it'd have to be proofed and benchmarked. This work could benefit that. Also, I have access to Frando's work on creating .theme files but I don't have access to Adrian/Vlado's work on separating out into .tpl.php. Frando's work includes an extractor, though, that I think can be repurposed to do just that, so I'm not terribly concerned.
Am having trouble posting to your site, so will throw in my interest to participate/approach here. I have sort of a question first. Once I was doing a project for someone who wanted to take advantage of the theme switching functionality that Drupal has, while at the same time needing some heavy theming (presentation functionality) common among all themes. I had to make a module, because it was either a module or replicate everything in all the themes to keep the theming and the theme switching. At that time I dreamed of a kind of "theming abstraction layer" around the theming engine. A kind of phptemplate which had an editable/extensible part around the theme engine itself, so that if someone wanted, they could affect "all" themes (associated with the theme engine of course). This kind of thinking might have something to do with the speed problem also. Anyway, that may or may not be possible/desirable for most, and I think your idea is a great step forward to Drupal usability. I would love to participate in some way. We already have touched on this in a couple of Dojo classes (copying theme function to template file) and it will be a wonderful (apprentice rather than dojo, with occasional dojo help, I think) effort. I think it would be better identifying a series of use cases (phpbb, newspaper publishing, "community" (profile theming with custom css, mypage theming, etc), software development collaboration site, what have you. Then people could pair/team together on a use case basis and do a fun "treasure hunt" for what they need on the basis of the exercise you are proposing. Once several get under way, that 90% is hit (it will be a different 90%). Then some volunteers can do a mop-up operation. Others can work on the optimization question. There will be a continual process of refactoring on the basis of lessons learned (all teams would publish their efforts). I would like to work on a community/newspaper publishing effort (maybe text columns, placement/theming of additional fields for the story, feature pages, countless other things) and I would like to start from the use cases, and as few modules as possible (maybe aggregation or aggregation-type module or import type module (use of importexport module) to import stories already written for hard copy into the web environment), get the basic functionality going on a clean 5.0 installation, then do the exercise you propose. And like Josh, you should make a group on http://groups.drupal.org/, you won't have to necessarily lead it, or spend much time working with it, but it would centralize our efforts and make it economical to work together, choose pairs, groups, and report work done. Another alternative (talk to Josh) would be just to use a thread on Dojo, but it's all the same to most people I think. Victor Kane victorkane@drupal.org (for contact info) http://awebfactory.com.ar On 1/21/07, Earl Miles <merlin@logrus.com> wrote:
Transferred from my blog at Dries' request. First, the blog post:
Today on drupal.org I just posted my 'personal battle plan' and it includes a fairly large project .... called the Drupal 5 Themer Pack which includes every (or nearly every) theme function in Drupal 5 core as a .tpl.php and the corresponding template.php code.
Op zondag 21 januari 2007 12:15, schreef Victor Kane:
Am having trouble posting to your site, so will throw in my interest to participate/approach here. I too cannot post.
<a href="http://drupal.org/project/sympal_theme">Sympal Theme</a> is exactly what you want to make. The only difference? it already exists! <a href="http://cvs.drupal.org/viewcvs/drupal/contributions/themes/sympal_theme/">See the files aready converted </a> Okay, 24 .tpl.php files is not where the most work went into: creating a good standard, consistent and semantic XHTML scheme to stick to, was. Now that we have that consistent XHTML scheme, all tpl.php files are quite easy to generate: no longer do you need to think hours about what HTML that file should contain, the standards already define it for you: its a matter of seconds to create these files and let them fit into the site while keeping the rendered pages very well structured! Watch that project grow more tpl.php files in the next weeks. And please consider adding to this project, instead of starting a new project!? Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Wouldn't it make more sense to make the default templates in core better as suggested before instead of "porting" another portion of drupal into some sort of contrib project? Stefan Op 22-jan-2007, om 11:37 heeft Bèr Kessels het volgende geschreven:
Op zondag 21 januari 2007 12:15, schreef Victor Kane:
Am having trouble posting to your site, so will throw in my interest to participate/approach here. I too cannot post.
<a href="http://drupal.org/project/sympal_theme">Sympal Theme</a> is exactly what you want to make. The only difference? it already exists!
<a href="http://cvs.drupal.org/viewcvs/drupal/contributions/themes/ sympal_theme/">See the files aready converted </a>
Okay, 24 .tpl.php files is not where the most work went into: creating a good standard, consistent and semantic XHTML scheme to stick to, was. Now that we have that consistent XHTML scheme, all tpl.php files are quite easy to generate: no longer do you need to think hours about what HTML that file should contain, the standards already define it for you: its a matter of seconds to create these files and let them fit into the site while keeping the rendered pages very well structured!
Watch that project grow more tpl.php files in the next weeks. And please consider adding to this project, instead of starting a new project!?
Bèr
-- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
In my opinion, no. Drupal is great because it cleanly separates "core" (controller, logic; and model, database, cleanly separated into its database abstraction layer) from presentation, giving you the ability to plug in Smarty, phpTemplate, etc For example, let's suppose I want to make a theming engine based on XLST theming: I would make a theming engine which ensured div creation via pure XML, would write a minimalist XLST transformation that would be expanded in every individual theme, and would add on some standalone CSS. Drupal goes very far in implementing the MVC (model, view controller) pattern. The core should call the theme engine for the presentation layer. What I am suggesting is to give flexibility on a theme-engine wide layer, and not only in a single theme. Victor Kane http://awebfactory.com.ar On 1/22/07, Stefan Nagtegaal <development@istyledthis.nl> wrote:
Wouldn't it make more sense to make the default templates in core better as suggested before instead of "porting" another portion of drupal into some sort of contrib project?
Hey Victor
Drupal goes very far in implementing the MVC (model, view controller) pattern.
Yes and no. There seems to be some effort in attempting to achieve this in the future, but it is certainly not there (yet), as you say yourself Drupal "goes a long way", but just not (yet) far enough. Just take a look at ROOT/includes/menu.inc, e.g. line653: <code> return "\n<ul class=\"menu\">\n". $tree ."\n</ul>\n"; </code> There's more in that file. Including mark up violates MVC separation IMHO. Actually, I thought this is exactly where Earls' project suggestion is suppose to lead us to (clean MVC). Someone please correct me! <quote parent_post="Earl Miles"> effectively separate logic from presentation without adding too much processing time to the code. </quote> By the way Earl, I am also interested in this project, but am currently a little busy with some other stuff. Further I agree with Victors first suggestion to turn this into a Drupal Dojo project. Bright Regards JasonMR
Hello, You mention one thing that cannot be dealt with in a contributed theme: the almost-random string concanation done by core functions. Another very nasty one is how cascade theme-ed content. Op maandag 22 januari 2007 13:38, schreef jason@jayro.net:
There's more in that file. Including mark up violates MVC separation IMHO.
Actually, I thought this is exactly where Earls' project suggestion is suppose to lead us to (clean MVC). Someone please correct me!
We see these two concepts in core (deliberately left simple, for more confusing/real-world examples hunt for Foreaches, Ifs and Whiles inside theme functions): ... return theme('foo', $data); ... theme_foo($data) { $out = '<div id="foo-wrapper">'; $out .= theme('bar', $data['items']); $out .= '</div>'; } -------------- ... $part = teme_item_list(); $part .= theme('foo', $data, $part); return $part; ... theme_foo($data, $list) { $out = '<div id="foo-wrapper">'; $out .= $list; $out .= '</div>'; } Or, in words: do you call a theme function from within a theme function? Or do you build strings, then pass these chunks-of-HTML along to the next theme function? I -personally- always prefer the first option: that way your theme has much more power, which comes with added complexity. This project of Earl would probably need to agree on one of both as 'preferred standard'. Currently the random use of one of these two in Drupal (and contribs) is utterly confusing, and IMO the main cause for the inconsistency in the outputted XHTML. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
On Monday 22 January 2007 5:07 am, Victor Kane wrote:
Drupal goes very far in implementing the MVC (model, view controller) pattern.
I wish people would stop saying that. Drupal is not MVC in the slightest. It's a PAC architecture. Two very different things that many many people keep confusing. (I blame Sun.) That's not a bad thing, but please don't confuse the two as it only leads to more confusion and architectural breakdown. For more details: http://www.garfieldtech.com/blog/mvc-vs-pac -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 23 Jan 2007, at 4:27 AM, Larry Garfield wrote:
For more details: http://www.garfieldtech.com/blog/mvc-vs-pac
You misquoted me. I commented on the page.
On Tuesday 23 January 2007 1:43 am, adrian rossouw wrote:
On 23 Jan 2007, at 4:27 AM, Larry Garfield wrote:
For more details: http://www.garfieldtech.com/blog/mvc-vs-pac
You misquoted me.
I commented on the page.
It's possible, since I was going just from the slides as I wasn't at the actual presentation. If so, I apologize. (I also commented in reply.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Op maandag 22 januari 2007 11:58, schreef Stefan Nagtegaal:
Wouldn't it make more sense to make the default templates in core better as suggested before instead of "porting" another portion of drupal into some sort of contrib project?
Probably. But just like me, many people need a solution now. By having it as acontrib we can work 'in real life' on the template files, and improved XHTML. *I* prefer that over spending many hours in the core issue threads, only to have to wait another release cycle before I can actually use something that looks like what I had in mind in the first place. But more important: this theme is not just about making lots of tpl.php files: its abotu making them use *consistent* classes, IDS and consistent use of DIVs, ULs. Consitent nesting. In order to get that in core, you first need a Big Picture. For core, preferring small iterative patches, this means the only option is to make an theoretical Class ID and XHTML standard, from wich many small patches can be derived. But it can also be done by developing it 'in the real world'. By putting it to test when people build their CSS on top of it and so on. That said, nothing withholds anyone from making patches from (parts of) that theme. Once (if) more people use it, the Real Life will prove wether or not a choice was a good one: if it was, a patch for core is made very easily. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Bèr Kessels wrote:
But more important: this theme is not just about making lots of tpl.php files: its abotu making them use *consistent* classes, IDS and consistent use of DIVs, ULs. Consitent nesting.
Where are these classes/ids/tags listed and documented? -- Neil Drumm http://delocalizedham.com/
Op maandag 22 januari 2007 19:46, schreef Neil Drumm:
Where are these classes/ids/tags listed and documented?
http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html http://project.webschuur.com/node/127 (login required hence I just created the file below) http://cvs.drupal.org/viewcvs/drupal/contributions/themes/sympal_theme/XHTML... Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Have you every given any thought to my idea of "theming abstraction layer"? In that way, all would be exposed for all themes associated with the phptemplate theming engine. Victor Kane http://awebfactory.com.ar
At that time I dreamed of a kind of "theming abstraction layer" around the theming engine. A kind of phptemplate which had an editable/extensible part around the theme engine itself, so that if someone wanted, they could affect "all" themes (associated with the theme engine of course).
Hey Bèr,
<a href="http://drupal.org/project/sympal_theme">Sympal Theme</a> is exactly what you want to make. The only difference? it already exists!
I just wanted to give it a try out, and got an error pointing me to the first line of "search_form.tpl.php". It has this: <code> print form_render($form); </code> Which I had to change to the following to get it to work: <code> print search_box; </code> I'm still pretty new to Drupal, is this an error, old code, or a function still to be defined? Bright Regards JasonMR
Op maandag 22 januari 2007 13:10, schreef jason@jayro.net:
I'm still pretty new to Drupal, is this an error, old code, or a function still to be defined?
Weird, this was fixed: http://cvs.drupal.org/viewcvs/drupal/contributions/themes/sympal_theme/searc... I am still fighting with the new CVS stuff, so probably made a mistake. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Hi Jason, I was looking at it as well. The error is due to form_render being changed to drupal_render in 5. Ber has fixed it in the HEAD version. Here is the CVS search_form.tpl.php: http://cvs.drupal.org/viewcvs/drupal/contributions/themes/ sympal_theme/search_form.tpl.php?rev=1.2&view=markup Addi Berry 240-274-0875 http://rocktreesky.com On Jan 22, 2007, at 7:10 AM, jason@jayro.net wrote:
Hey Bèr,
<a href="http://drupal.org/project/sympal_theme">Sympal Theme</a> is exactly what you want to make. The only difference? it already exists!
I just wanted to give it a try out, and got an error pointing me to the first line of "search_form.tpl.php".
It has this: <code> print form_render($form); </code>
Which I had to change to the following to get it to work: <code> print search_box; </code>
I'm still pretty new to Drupal, is this an error, old code, or a function still to be defined?
Bright Regards JasonMR
Hi Addi and Bèr, thanks both for the clarification. Though, I still have a question, why use "drupal_render($form)" instead of simply using "search_box"? And where is "search_box" defined (if anyone knows of hand)? Bright Regards JasonMR
Op maandag 22 januari 2007 17:17, schreef jason@jayro.net:
Though, I still have a question, why use "drupal_render($form)" instead of simply using "search_box"? And where is "search_box" defined (if anyone knows of hand)?
Two things: 1) you may have noticed the TODO? This tpl.php must be made into a normal chunk of XHTML rather then calling some internal Drupal function (which, in turn calls another theme function trough some api, etc) 2) By asking your question, "where it is defined", you have answered the actual question :), and you mention the most important reason for making this all .tpl.php files. By defining the HTML we have such a form in a consintent, place. Once ALL stuff is defined in .tpl.php files, one no longer needs to ask himsef "where the F does thát piece of HTML come from?", but simply has to open the proper .tpl.php file and go like 'aah, so, that is where I can add another sliding door-wrapper-DIV'. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Bèr Kessels wrote:
Op zondag 21 januari 2007 12:15, schreef Victor Kane:
Am having trouble posting to your site, so will throw in my interest to participate/approach here.
I too cannot post.
<a href="http://drupal.org/project/sympal_theme">Sympal Theme</a> is exactly what you want to make. The only difference? it already exists!
No, the only difference is that yours is a THEME while what I intend to do is merely a collection of stuff. You're trying to 'fix' things in Drupal with your theme. I am merely trying to expose the templates. I want the output to be *precisely* the same as it is with stock Drupal. That means resisting the urge to fix anything. There are some very serious differences in what this I have in mind and what sympal_theme appears to be meant to do.
Earl Miles wrote:
No, the only difference is that yours is a THEME while what I intend to do is merely a collection of stuff. I don't think that's true Earl, Sympal is also a collection of stuff, to be pruned or modified in order to actually create a theme.
You're trying to 'fix' things in Drupal with your theme. This I think is the crucial difference - Ber is driving towards a better (or at least standardized) xhtml/css framework. We might take issue with his route but I doubt any of us would argue that's a bad thing.
I am merely trying to expose the templates. I want the output to be *precisely* the same as it is with stock Drupal. That means resisting the urge to fix anything. And that means your large project will be a dead end *if* all theme functions get moved into tpl files and are organized into a more structured xhtml tree for Drupal 6.
There are some very serious differences in what this I have in mind and what sympal_theme appears to be meant to do. The only real difference I can see is that you want to extract Drupal's current theme xhtml into a collection of templates rather than attempting to improve on it. In effect your themer's kit is just another base theme for people to build real world themes on. That's no bad thing but I'm not sure we need yet another one.
Drupal's theme system has grown organically over the years and I'm pretty sure everyone agrees it could do with some tidying, moving theme xhtml to tpl files is the first step in that, and makes theming easier in the process. As Dries says, working on that provides more benefits in the long run. -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
Adrian Simmons wrote:
Earl Miles wrote:
No, the only difference is that yours is a THEME while what I intend to do is merely a collection of stuff.
I don't think that's true Earl, Sympal is also a collection of stuff, to be pruned or modified in order to actually create a theme.
Semantically speaking, there is a large difference. When someone says 'theme' they see that they're getting a whole package. How is anyone to really know that they can pick and choose? And what's the chances that some of it will turn out to be dependent upon other parts of itself? The fact that very few themers are even really aware that they could pull .tpl.php files out of the sympal theme tells me that this isn't the way to go for the purpose that I'm trying to serve. And why is this? Because they see "theme" and immediately it's just another theme, lost in the noise. The Themer Pack is Not A Theme.
You're trying to 'fix' things in Drupal with your theme.
This I think is the crucial difference - Ber is driving towards a better (or at least standardized) xhtml/css framework. We might take issue with his route but I doubt any of us would argue that's a bad thing.
I don't take issue with his route, but that is one thing that I am absolutely disinterested in, at least as a Drupal 5 pack. If this pack 'fixes' things, it really isn't compatible with core and it doesn't do the job that I want it to do, which is allow drop in replacement.
I am merely trying to expose the templates. I want the output to be *precisely* the same as it is with stock Drupal. That means resisting the urge to fix anything.
And that means your large project will be a dead end *if* all theme functions get moved into tpl files and are organized into a more structured xhtml tree for Drupal 6.
No, the project can contribute code to that effort as well. As can Ber's project.
There are some very serious differences in what this I have in mind and what sympal_theme appears to be meant to do.
The only real difference I can see is that you want to extract Drupal's current theme xhtml into a collection of templates rather than attempting to improve on it. In effect your themer's kit is just another base theme for people to build real world themes on. That's no bad thing but I'm not sure we need yet another one.
No, this is absolutely wrong. It is NOT a base theme. It is light years from a base theme. I don't really understand what I said to even give the impression that it is anything like a base theme. It will include no *.css files *at all*, to start with. Its pieces should be droppable into *any existing Drupal 5 theme*, giving .tpl.phps to the theme developers for easy modification. It is extremely good for site designers and usable for general theme designers as well. Attempting to improve upon it is different. Improving upon it requires changing things. If I drop a template in there and get a suddenly different HTML output, then the style.css that I already has may become invalid. That is what I want to avoid. I want the HTML to change from default Drupal *only* if the themer modifies the .tpl.php file. I have no qualms with including 'alternates' that are improved, but that is not what this base project is about. Improving is something that can be done for Drupal 6, that's fine. But seriously, trying to tell me that we don't need this (especially when several of the types of people this is targeted at are going YES YES YES we need this) is irksome to me. These are the points I want to address: o Drupal does not have enough good themers working on the project. o A lot of themers are simply unable to identify themable code in Drupal. They're just not PHP coders, that's not what they do. o A lot of themers who can are unable to even deal with a lot of the currently themable code in Drupal because there is too much logic in it. This project serves one purpose: o To make it accessible for themers to be able to fully control the system that Drupal allows them to, but they currently cannot because they do not have the skills and the tools to access those parts. I see a real need here. Dries and Steven want more themers on Drupal. I think this is important. I think the work to be done here is not complicated, it is simply a little tedious. I think once it's done, a themer can look at these templates and *see* a lot more of what is going on. So yes, just because I'm not already looking forward to Drupal 6 and thinking about how this should go into core, don't try to kill this project. I'm aware that Drupal has problems and issues, but I'm also looking at this with an eye for what can we supply people with NOW.
Earl Miles wrote:
o Drupal does not have enough good themers working on the project. o A lot of themers are simply unable to identify themable code in Drupal. They're just not PHP coders, that's not what they do. o A lot of themers who can are unable to even deal with a lot of the currently themable code in Drupal because there is too much logic in it.
I haven't followed the details of the whole conversation, but having watched a two-day theming workshop with about 30 attendees, and seen the questions they put forward, I'd say that Earl's identified needs are right on target. Finding themable code, and overcoming the large amount of logic in certain key themable functions, is a big issue. --Jeff
On 23 Jan 2007, at 17:34, Jeff Eaton wrote:
o Drupal does not have enough good themers working on the project. o A lot of themers are simply unable to identify themable code in Drupal. They're just not PHP coders, that's not what they do. o A lot of themers who can are unable to even deal with a lot of the currently themable code in Drupal because there is too much logic in it.
That's exactly what we want to address in Drupal 6. :)
I haven't followed the details of the whole conversation, but having watched a two-day theming workshop with about 30 attendees, and seen the questions they put forward, I'd say that Earl's identified needs are right on target.
Finding themable code, and overcoming the large amount of logic in certain key themable functions, is a big issue.
Agreed. I think both Ber's, Earl's and Adrian/Vlado/chx/Dries/core's efforts are well worth pursuing. They all serve the same purpose -- making Drupal more accessible to themers. Jeff: would be great to see some of your themer training feedback flow back into core. -- Dries Buytaert :: http://www.buytaert.net/
Op dinsdag 23 januari 2007 17:31, schreef Earl Miles:
The fact that very few themers are even really aware that they could pull .tpl.php files out of the sympal theme tells me that this isn't the way to go for the purpose that I'm trying to serve.
I am sorry about that. Though I /do/ beleive, that given some time people will be well aware of this. First: Sympal Theme is Not For Sissies. If you don't know your CSS and don't know stuff like faux-colums/holygrail/horzintal-lists by heart, then *at this moment* its useless for you. I beleive that my target group is very well suited to pull out the bits they like and ignore the bits they don't need.
No, the project can contribute code to that effort as well. As can Ber's project.
And how can we make sure we 'wtand on eachothers shoulders' rather then standing in eachothers shadow? My initial idea is: get this default XHTML structure right and settled. We can work from there. I, in the base-theme, ThemePack in patches for core.
It will include no *.css files *at all*, to start with.
Neither does Sympal Theme, not in the sense you may think. If you had looked, you had noticed that the CSS is purely informative: it displays the node(as in XHTML node) details such as class and Id names in the browser. The other two CSS styles are there to prove to newcomers that it is not just academic babbling about semantics and SEO, but that it is very simple to build columned layouts with less then 10 lines of CSS. So if those are the parameters, then Sympal theme is not a theme either.
Its pieces should be droppable into *any existing Drupal 5 theme*, giving .tpl.phps to the theme developers for easy modification. It is extremely good for site designers and usable for general theme designers as well.
I come o this from a different angle: By setting a good structured, consistent and welldefined standard, its both easy to drop into any place, AND easy to override.
Attempting to improve upon it is different. Improving upon it requires changing things. If I drop a template in there and get a suddenly different HTML output, then the style.css that I already has may become invalid. That is what I want to avoid. I want the HTML to change from default Drupal *only* if the themer modifies the .tpl.php file.
90% of the upgrade work on a theme is fixing the CSS: classes, IDs and nesting of modules and core that were improved during the release cycle. Unless we change the entire concept of Drupals tehme system (and I think the everythingAPI is actually gettign us there) this will always be the case. So: changed HTML is a fact we have to live with. But: if a theme layer above that maanges to keep consistency in place, then your CSS will not break. Say, hypothetical: Core returns <div class="login-block-form">...</div> But in a new version, a better Fapi changes this into <div id="login-block-form" class='form-element'>...</div> But, in a theme that has a Grand View of the whole structure, we can change this back to the consistent HTML we had before. Then, when the core changes, we only need to change minor things in the .tpl.php file and/or the template.php file, so that at a new release our HTML, wih IDs and CLASSES remains the same as before the changes.
These are the points I want to address:
Nothing different from my points.
This project serves one purpose:
So yes, just because I'm not already looking forward to Drupal 6 and thinking about how this should go into core, don't try to kill this project. I'm aware that Drupal has problems and issues, but I'm also looking at this with an eye for what can we supply people with NOW.
Then I fail to see how you want to do this. Patches for core to improve themes means waiting till 6. A base theme is not what you want either. But more important: I fail to see why my project is not what you really want. Is it merely the fact that I try to create a consistent, structured HTML and that we need to change what core outputs to get there? Or is there anyhting else I can do to make you like my project a little more? For example changing the name and stop calling it a theme? Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Bèr Kessels wrote:
Then I fail to see how you want to do this. Patches for core to improve themes means waiting till 6. A base theme is not what you want either. But more important: I fail to see why my project is not what you really want. Is it merely the fact that I try to create a consistent, structured HTML and that we need to change what core outputs to get there? Or is there anyhting else I can do to make you like my project a little more? For example changing the name and stop calling it a theme?
Well, you're including a page.tpl.php, a node.tpl.php, etc. These are also things I want to avoid. I don't want to include any .tpl.phps that are already provide by phptemplate.engine. And I don't dislike your project. I just see this project and your project as having a fundamentally different direction. Unfortunately, in my desire not to have what I'm trying to put forward here brushed aside, I have understated the importance of your direction: Cleaning up the XHTML is a really good idea. The thing is, I think that's primarily core work. Or something that could be done as an 'alternatives'. At which point, then this project and sympal theme begin to really come together. However, I don't think it benefits themers to have changed XHTML be the primary focus of the themer pack. I think it's very important that the output this delivers be precisely the output Drupal delivers, and let the themer decide if they are going to change that. Using these template files, changing that XHTML should be a relatively simple task. Once this project has reached its first stage, we can begin submitting patches to core, where the logic we separated for this pack can be integrated into Drupal 6. If we do our jobs right, then maybe Drupal 6 doesn't need the themer pack, and this project becomes a stepping stone onto something grand. Or we don't do our jobs well enough for core, but we spur some ideas, and maybe it's not until Drupal 7 or 8 where the pack becomes obsolete. Either way is perfectly okay. Maybe the real issue here my believe that focussing on the XHTML is the wrong place to start. I want to focus with the separation of logic and presentation, and IMO it's very important to not change the fundamental output while doing that. It becomes trying to accomplish too many things in one step. 1) create the .tpl.php and template.php files. 2) separate the the logic from the presentation while preserving the output. 3) release into the wild; let themers begin to use the code. 4) Figure out a way for core to utilize these templates too, without having the 10% speed hit. Once they're in core it won't be so much with the pick-and-choose, they have to all be there. 5) let XHTML experts look over these; make changes, and submit the XHTML changes as core patches; because now their changes will primarily be template changes which are easier for non PHP programmers to deal with, and willing developers or the combination developer/themer can submit patches on their behalf.
Hi Bèr, Earl, Although, as you know, I'm not much of a themer, I happen to have already done some thinking tangentially related to both your approaches: it's the theme of "multichannel" drupal, or how to access/use a drupal site without a web browser. For my own needs, this stems from the need for back-office GTK-based apps accessing the e-commerce front office; for others, it might be serving cHTML or even WAP. I think that considering this type of scenarios might guide both these projects and their possible convergence/cohabitation: both a set of consistent xml ids, and the ability to have a no-HTML output or, if necessary, an HTML output with consistent id/class naming make it easier to create the transforms used that can be used in these more challenging (drupal-wise) environments. So it might also make it easier on future theme developers. Just my 0.02... FGM
Op dinsdag 23 januari 2007 22:46, schreef Earl Miles:
Maybe the real issue here my believe that focussing on the XHTML is the wrong place to start. I want to focus with the separation of logic and presentation, and IMO it's very important to not change the fundamental output while doing that. It becomes trying to accomplish too many things in one step.
Okay. To summarize for all the people in this thread: * Sympal theme is an attempt to improve the XHTML. It is a basetheme that comes with many pre-made .tpl.php files which you can use to change into your own preferred XHTML. * Theme pack is an attempt to split out logic and presentation more. This wll be achieved by creating many pre-made .tpl.php files which you can use to change into your own preferred XHTML. So, I think both should be used in separate cases but both can work together very well. Here are my plans: * I will continue to make more .tpl.php files for sympal_theme, thereby maintaining a consistent XHTML structure and predictable IDs and Classes. * Whenever there are many more tpl.php files release by Theme Pack, I will try to look for a smoother way to get these files into sympal theme, thereby changing them to maintain that consistent XHTML and so on. Once Theme Pack reaches step #5, I think we can look how/if the structure of Sympal theme suits the needs for the "experts to look at the XHTML". But I think it may be a good idea to read up on http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html and the links in there. That is the best documentation of how I ordered the XHTML. If people like that concept, we may alreay have the biggest part of 5 done :) Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Earl Miles wrote:
The fact that very few themers are even really aware that they could pull .tpl.php files out of the sympal theme That seems tantamount to saying that very few themers understand how Drupal phptemplate theming works...which may well be true :)
Because they see "theme" and immediately it's just another theme, lost in the noise. The Themer Pack is Not A Theme. So, do we need an extra section in the theme download are of drupal.org? There's more than sympal that is intended to be a 'base' theme. Where are you going to insert the Theme Pack so it won't get lost?
It is NOT a base theme. <snip> It will include no *.css files *at all*, to start with. What would a base for a phptemplate theme be, if not a bunch of tpl files?
Its pieces should be droppable into *any existing Drupal 5 theme* Ah. Now your intention is clearer :)
trying to tell me that we don't need this <snip> is irksome to me. Apologies if I rubbed you up the wrong way.
o To make it accessible for themers <snip> Dries and Steven want more themers on Drupal. I'm not disagreeing with your aims :) I'm skeptical that this will really bring in more quality themers. Time will tell. Good luck.
If there is one good thing I'll take away from this thread it's that it made me look a lot closer at Sympal, and I think that's something I might contribute too. I'd like to work on the separation of theme fucntions into tpl's in core but I don't have the php skills for that... -- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On 24.Jan.2007, at 06:05, Adrian Simmons wrote:
Because they see "theme" and immediately it's just another theme, lost in the noise. The Themer Pack is Not A Theme. So, do we need an extra section in the theme download are of drupal.org? There's more than sympal that is intended to be a 'base' theme. Where are you going to insert the Theme Pack so it won't get lost?
+1 May I suggest a separate section called "Theme Development Modules"? And have it announced prominently on the front page with a direct link to that section. Back to lurking, Liza Sabater, Publisher www.culturekitchen.com www.dailygotham.com TEL - 646.552.7365 AIM - cultkitdiva SKYPE - lizasabater
Adrian Simmons wrote:
If there is one good thing I'll take away from this thread it's that it made me look a lot closer at Sympal, and I think that's something I might contribute too. I'd like to work on the separation of theme fucntions into tpl's in core but I don't have the php skills for that...
That's certainly a good thing. Improving the XHTML is a worthy, valuable goal!
Yes, there are absolutely aspects of this that are a good push toward core. However, there are a couple of important things here:
1) Drupal 6 should be 6 months away, and this kind of project can benefit now, as well as having a future benefit by having the bulk of the theming work be done now. By being useful now, people who might not otherwise participate in this work might participate and contribute.
Correct. There is always a trade-off to be made between how long people will have to wait for something, how many people will be able to benefit from it (both short and long term), how much work it requires and/or duplicates, and the upgrade problems one wants to impose on their users. Improving the theme functionality in Drupal 6 is going to draw a lot more designers to Drupal than a (temporary) themer pack, IMO. Plus, it avoids duplication of work and causes fewer upgrade pains. Hence, I plan to be working on separating out theme functions into .tpl.php files for Drupal 6. People that are willing to help, including you and/or Ber, are more than welcome to. Of course, you can work on whatever you want -- just wanted to reach out and invite to help for the reasons outlined above. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
Improving the theme functionality in Drupal 6 is going to draw a lot more designers to Drupal than a (temporary) themer pack, IMO. Plus, it avoids duplication of work and causes fewer upgrade pains. Hence, I plan to be working on separating out theme functions into .tpl.php files for Drupal 6. People that are willing to help, including you and/or Ber, are more than welcome to.
I've done a bit of thinking about this. The first step I see is moving the variable setting from PHPTemplate to the core theme system. The key thing to realize here is that what is called from a module is not what a themeable function or template wants to receive. Node module likes calling theme('node') with a small number of arguments, but node.tpl.php has a much larger set of variables. The way I see this being implemented is adding a preprocessor step to theme(). If theme_foo_preprocess() exists, then that would be called with the original arguments and returns a larger set of, probably named, arguments. That function would be called in a themeable manner, so my_theme_foo_preprocess() could replace that argument preparation. This would move a large chunk of code out of PHPTemplate into the core theme system where it belongs. -- Neil Drumm http://delocalizedham.com/
On 23 Jan 2007, at 12:52 AM, Neil Drumm wrote:
This would move a large chunk of code out of PHPTemplate into the core theme system where it belongs.
This has already been done, for the templates patch me , dries , vlado and chx were working on. https://svn.bryght.com/dev/browser/templates/drupal (check theme.inc) There's a couple of small bugs, but that's an updated version of the templates work for drupal 5, including all templates split, and all theme calls changed to theme('thing', array('param' => 123, 'param2' => 321); (which is necessary to be able to load templates without requiring phptemplate_stub functions)
I've created a working group for people interested in helping out with this project. http://groups.drupal.org/themer-pack-working-group
participants (14)
-
Addi Berry -
adrian rossouw -
Adrian Simmons -
blogdiva＠culturekitchen.com -
Bèr Kessels -
Dries Buytaert -
Earl Miles -
FGM -
jason＠jayro.net -
Jeff Eaton -
Larry Garfield -
Neil Drumm -
Stefan Nagtegaal -
Victor Kane