Posted by Bèr Kessels on September 24, 2008 at 3:18pm
..really nice. They allow me to build a theme that I can alter from Drupals admin area.
45% (10 votes)
...quite alright. But I use only the core settings in my themes.
23% (5 votes)
...nice. I extend them all the time.
0% (0 votes)
...a thing I always forget. In my theme toggling "search box" has no result at all.
5% (1 vote)
...a feature I could do without. When I build my HTML I decide what to print; and when that changes, I change my HTML.
27% (6 votes)
Total votes: 22
Comments
I am deciding what route to take for the YUI-framework base
I would like some opinions and, if you like, some additional thoughts in the comments on what route to taken for a base theme.
I, personally, dislike the theme settings. I think that whether or not a, say, search-box, appears is down to
Same goes for the "show post settings". I usually decide to print them (or not) in the specific node-foo.tpl.php, and disgard the settings in the theme.
However, others seem to think these settings are nice. And I can see them being useful for the Joe Schmoe Blogger who knows nothing about XHTML and CSS and theme layers and the likes.
But, a base theme, such as the YUI framework will become, is not for that Joe Schmoe, but is targeted at designers and theme developers. Hence I, personally, think I should remove most settings from the various theme forms with overrides, when one uses this base-theme, so as not to confuse users (I checked this theme setting but it does not change anything).
What I would liek to know, though is:What about the $logo, the favicon and the other settings?
Do you actually use any of the settings in your theme-development process?
http://www.webschuur.com | http://bler.webschuur.com
I usually don't put anything new
I usually don't put anything new in the theme settings but if I am building on top of some other theme I tend to use the existing settings. While it's not very useful to me personally it is a simple to give the clients the power to change basic parts of the theme.
But let's face it, if you are the only one administrating the website I would not say ignore them.
Also, theme settings are wonderful when setting up a simple website quick with no requirements whatsoever on a custom theme.
...and yes, I use
...and yes, I use (especially) use the $logo, $favicon, $slogan because they will allow my clients to change them in the future. I see it as looking into the future what they want to be able to do if I suddenly drop down dead :-)
yea, the tram question
Sure, people often ask from me: "what happens if you get hit by a tram"?
Personally, I think a $logo or a $slogan are the least agile of all things. How often does a company change its logo (versus how often they change the layout and ordering of content)?
In five years of Drupal developement, I hardly ever got requests to change a logo (once, 2 months after delivery the final corporate image was established), favicon (never), and slogan (twice, once I went into the admin area to change it there, the other time I changed it in the theem). While I /do/ get gazillion requests to add sidebars, more columns, change grid-layouts. etc.
IMO solving the "can I put an image in the top-lef part" issues are a lot more valuable then being able to change some logo. A logo is so extremely tightly integrated into the design (or, so it should be...) that it hardly ever changes without the whole site being changed.
If I am hit by a tram, I have a well documented, open source system there. That virtually every Drupal developer, and potentially every webdeveloper-with-some-brains can take over.
http://www.webschuur.com | http://bler.webschuur.com
Joes
"But, a base theme, such as the YUI framework will become, is not for that Joe Schmoe, but is targeted at designers and theme developers."
Yes, but what if I choose your base theme to create a contrib theme, that will be used by lots of Joe Schmoes? :)
IMO it is then up to you to
IMO it is then up to you to include the settings specific for your end-user theme.
IMO settings such as "allow blocks to be placed in a left sidebar" make a lot of sense (toggling of and on a region) for certain themes, provided they have such a sidebar in the first place!
YUI will not have such sidebars, since it is a base-theme. You, the developer, should be able to create themes with sidebars, without them, with four columns, two- online columns or whatever fancy layouts you come up with.
If, in that fancy layout, it makes sense to add certain options, you could do so, at your end.
On the other side: makeing a JoeSchmoe theme from YUI grids is a PIAS: Druapl does not allow/like the BSD licenced 3rd party CSS to be shipped from within its CVS. So hosting at DRupal is not an option here, the barrier for Joe is therefore very high to begin with :).
http://www.webschuur.com | http://bler.webschuur.com
So: what settings do you
So: what settings do you think should be left in place, for you (the developer) to extend towards your end-users?
Should I, e.g. leave the $logo in place, at the cost of complexity on the developers side, so that the end-users can use it once a theme is extended towards that target-group?
I would reallly like to find out what settings to
1. introduce.
2. drop.
in a base-theme.
Bèr
http://www.webschuur.com | http://bler.webschuur.com
Ok, let's look at the
Ok, let's look at the list.
Imho, if I build a specific theme for one site, I agree I wouldn't need of most of them.
When a company's logo changes, the design usually also changes, so they'll need theming work anyway. I don't think baselines change that often.
Pictures in posts, favicon, menus, search, are all your choices so you don't need a toggle in the theme settings.
So what's left? Probably the mission statement, but it would be more flexible as a block so the users could use an RTE. I have personally never used that variable...
Well, it seems I agree with you in the end. No setting left ^_^
Depends on the use-case
When building a contrib theme, the theme settings allow you to make the theme more user-configurable.
For most one-off themes for clients, you don't need them. But sometimes a client does have a requirement in the RFP that naturally lends itself to a "this is a theme setting" decision. At Palantir, we've got a client right now who will have multiple sites so they want options to configure each site's theme differently.
For full disclosure, I'm the one who got the custom theme settings api into D6 (with help, of course.) :-) And I've got some to-dos to make them more flexible and easier to use in D7.
- John (JohnAlbin)
- John (JohnAlbin)