Here http://drupal.org/node/225125 one can find a few ideas why one might want to use a subtheme. But if I have a site that needs only one theme, it's just one site, and there's no real interest in playing with ideas of different looks, is there any reason to use a subtheme of Zen or Blueprint as opposed to how I always do it and just make a fresh, 'regular' theme?
Thanks.
Fred,
If you are comfortable developing a theme from scratch and using only that them on a site, it is perfectly fine. The advantage of using Zen or Blueprint is to give you a jumpstart with a framework theme (often called starter themes). Framework/start themes often reset css and provide helper code to make theming with Drupal easier.
The main reason I would subtheme is to allow easier updates to your framework/starter theme from d.o. If you have just hacked those themes downloaded from d.o, you have to merge your changes back in. Of course that can be done with git, but I still think sub-theming is better. If someone else looks at your site, it will be easier for them to see what is going on..
Thanks! Mark
On Mar 13, 2011, at 7:44 PM, Fred Jones wrote:
Here http://drupal.org/node/225125 one can find a few ideas why one might want to use a subtheme. But if I have a site that needs only one theme, it's just one site, and there's no real interest in playing with ideas of different looks, is there any reason to use a subtheme of Zen or Blueprint as opposed to how I always do it and just make a fresh, 'regular' theme?
Thanks.
[ Drupal support list | http://lists.drupal.org/ ]
In the case you describe you might nevertheless want to use a subtheme if the changes you'll be making on the one you'll use as starter are mostly cosmetic and you want to benefit from future bug corrections or ameliorations that the authors of the starter theme might introduce.
These days, theme's are viewed much like contributed modules which code you usually do not alter but rather override in other places. Personally, I think themes are quite different from modules and that there's a good chance that future ameliorations of a theme produce unexpected results on your website but, nevertheless, this seems to be the current mainstream thinking nowadays.
Roberto
------------ On Sun, March 13, 2011 4:44 pm, Fred Jones wrote:
Here http://drupal.org/node/225125 one can find a few ideas why one might want to use a subtheme. But if I have a site that needs only one theme, it's just one site, and there's no real interest in playing with ideas of different looks, is there any reason to use a subtheme of Zen or Blueprint as opposed to how I always do it and just make a fresh, 'regular' theme?
Thanks.
[ Drupal support list | http://lists.drupal.org/ ]
These days, theme's are viewed much like contributed modules which code you usually do not alter but rather override in other places. Personally, I think themes are quite different from modules and that there's a good chance that future ameliorations of a theme produce unexpected results on your website but, nevertheless, this seems to be the current mainstream thinking nowadays.
Yes, that's exactly what I feel. I was always nervous that I will make a subtheme and then in 2 months we will upgrade and then my client will call me on the phone frantic that I "broke" page X. He won't know that it's due to a CSS change in the new version of the theme.
Has anyone else experienced this? Or is it basically considered safe to use a subtheme and rely on the main theme author not to do something stupid?
Yes of course one should do upgrades on a test site etc. but everyone knows that for a simple module upgrade, just making a backup of the DB and old code should be enough--if something goes wrong, the site can be restored in about 60 seconds. I would *tend* to think the same for themes...
F
On Sunday, March 13, 2011 7:47:56 pm Fred Jones wrote:
These days, theme's are viewed much like contributed modules which code you usually do not alter but rather override in other places. Personally, I think themes are quite different from modules and that there's a good chance that future ameliorations of a theme produce unexpected results on your website but, nevertheless, this seems to be the current mainstream thinking nowadays.
Yes, that's exactly what I feel. I was always nervous that I will make a subtheme and then in 2 months we will upgrade and then my client will call me on the phone frantic that I "broke" page X. He won't know that it's due to a CSS change in the new version of the theme.
Has anyone else experienced this? Or is it basically considered safe to use a subtheme and rely on the main theme author not to do something stupid?
At the risk of sounding seditious, there's no reason you *have* to upgrade a base theme after the site is built unless there's a security update. In my experience security holes in the good/popular base themes are extremely rare, so if you want to build your site on a given release of Zen and then a new Zen release comes out you can most likely just ignore it.
--Larry Garfield
At the risk of sounding seditious, there's no reason you *have* to upgrade a base theme after the site is built unless there's a security update. In my experience security holes in the good/popular base themes are extremely rare, so if you want to build your site on a given release of Zen and then a new Zen release comes out you can most likely just ignore it.
That's what the point of making a subtheme? Why not just make a custom version of Zen or Blueprint and then avoid seeing that yellow warning every time you visit the Updates page?
I don't make themes from scratch--what I usually do is take an existing them, and change the name to something else and then customize it.
The main reason I would subtheme is to allow easier updates to your framework/starter theme from d.o. If you have just hacked those themes downloaded from d.o, you have to merge your changes back in. Of course that can be done with git, but I still think sub-theming is better.
But then you run the risk of the upgrade breaking something, no?
If someone else looks at your site, it will be easier for them to see what is going on..
Don't see why it's easier to deal with a main theme and then a subtheme as opposed to just one custom theme. Could well be more complicated with a base and subtheme in fact.
Why am I so stupid? Everybody else can restore a whole site in 60 seconds . :(
Perhaps you misunderstood what I meant--I didn't say debug and fix, I said "restore" which means to put back the old code which I had just moved to a different directory anyway and then import the previous version of the DB which I just saved. Actually I don't see those two operations either via ssh or a good Control Panel should take more than a minute. After that, of course one probably needs to make a dev copy of the site and run the upgrade and then examine what the issue is etc. etc.
I'm not trying to be unpleasant, just trying to understand here--but I still haven't heard a compelling reason for a simple one-theme site to use a subtheme. Maybe there isn't one...
Thanks, Fred
my .02
Being a relative newcomer here I started off creating Zen sub themes for all the reasons previously stated here. I have since switched to the Basic starter theme. I just download, untar, rename, wireframe etc. For me this process is much more straightforward and pleasant.
When I deliver the theme to the client it is set in stone. If a new theme needs to be created then I typically download the latest and go from there unless there are significant similarities then I would consider customization of the existing.... hmmm
I may have just strengthened the case for sub-theming. O well :).
*
Ryan LeTulle*
bayousoft http://twitter.com/bayousoft -twitter
On Mon, Mar 14, 2011 at 6:39 AM, Fred Jones fredthejonester@gmail.comwrote:
At the risk of sounding seditious, there's no reason you *have* to
upgrade a
base theme after the site is built unless there's a security update. In
my
experience security holes in the good/popular base themes are extremely
rare,
so if you want to build your site on a given release of Zen and then a
new Zen
release comes out you can most likely just ignore it.
That's what the point of making a subtheme? Why not just make a custom version of Zen or Blueprint and then avoid seeing that yellow warning every time you visit the Updates page?
I don't make themes from scratch--what I usually do is take an existing them, and change the name to something else and then customize it.
The main reason I would subtheme is to allow easier updates to your
framework/starter theme from d.o. If you have just hacked those themes downloaded from d.o, you have to merge your changes back in. Of course that can be done with git, but I still think sub-theming is better.
But then you run the risk of the upgrade breaking something, no?
If someone else looks at your site, it will be easier for them to see
what is going on..
Don't see why it's easier to deal with a main theme and then a subtheme as opposed to just one custom theme. Could well be more complicated with a base and subtheme in fact.
Why am I so stupid? Everybody else can restore a whole site in 60 seconds
. :(
Perhaps you misunderstood what I meant--I didn't say debug and fix, I said "restore" which means to put back the old code which I had just moved to a different directory anyway and then import the previous version of the DB which I just saved. Actually I don't see those two operations either via ssh or a good Control Panel should take more than a minute. After that, of course one probably needs to make a dev copy of the site and run the upgrade and then examine what the issue is etc. etc.
I'm not trying to be unpleasant, just trying to understand here--but I still haven't heard a compelling reason for a simple one-theme site to use a subtheme. Maybe there isn't one...
Thanks, Fred -- [ Drupal support list | http://lists.drupal.org/ ]
Thanks for picking this up.
yes; your clarity is received, and welcomed. - you were not talking about debug and fix, just the restoration.
I agree that as yu put it is quite conceivable to do the SSH and db restore operations in under a minute if the system for doing that is well established in your dev environment and mind beforehand. I agree it is having that 'instant' (where instant mans less than one minute) restoration point available that makes the difference. I always prioritise that availability. And in perhaps 7 or 9 times out of 10 the theoretically correct, and previously tested restoration operations will lead to a fully restored site in 'an instant' and we go "whoo. glad i had insisted on the restoration point".
and in the other 3, 2 or 1 times?
we missed a factor in our consideration, and the restore fails and our 'average of under a minute to restore' nudges up again way above the minute.
sounds like you have it under control Fred.
when things go right they are very right but when things go wrong they can be very ugly indeed; thus my minimum time for such restore is for sure way under a minute; but the average over the years is possibly much higher than that.
all good.
On 14/03/2011, at 11:39 PM, Fred Jones wrote:
Why am I so stupid? Everybody else can restore a whole site in 60 seconds . :(
Perhaps you misunderstood what I meant--I didn't say debug and fix, I said "restore" which means to put back the old code which I had just moved to a different directory anyway and then import the previous version of the DB which I just saved. Actually I don't see those two operations either via ssh or a good Control Panel should take more than a minute. After that, of course one probably needs to make a dev copy of the site and run the upgrade and then examine what the issue is etc. etc.
====================== John Saward B.Sc. Director and Problem Solver - Studio Also Pty Ltd Drupal CMS solutions www.also.com.au www.drupal.com.au john@also.com.au 03 5968 1541 0418 610 706 Skype: studioalso FB: john.saward (personal) FB: studioalso (business) ======================
I've been following this thread with interest. It seems to me that themes as they exist in Drupal serve two distinct purposes.
1. They make things look right. This is the CSS, JS, custom templates, template.php magic etc. that's necessary to make this-site.com look different from that-site.com.
2. They open up functionality. This could be the theme registry rebuilder, conditional stylesheets, Fusion-style column fun, etc.
If you're only interested in #1 then it seems to me that using a parent theme and updating it regularly might cause problems, and might not really help in anyway.
If you need #2 then I think your hand's kinda forced.
I think a hefty theme like Fusion really does straddle the line between module and theme, and that's part of the reason this discussion arises.
I'm no expert, but there are parts of Zen and Fusion that perhaps belong in modules (that can supply their own CSS, JS) and life would be easier if a theme really was nothing more than the icing on the cake (no heavy lifting). I know that Fusion already expects Skinr, and parts of Zen's goodness can also come in module format, so I wonder where future development will lead.
A.
. . . . . . . Andy Fowlston +44 (0)20 8747 5068 andy@pedalo.co.uk Skype: andy.pedalo www.pedalo.co.uk
This email is intended only for the above named addressee/s. This email may be confidential or legally privileged. If you have received this email and you are not a named addressee, you must not use, copy, distribute or disclose the email or any part of its contents or take any action in reliance on it. If you have received this email in error, please email the sender by replying to this message and delete it from your system. All reasonable precautions have been taken to ensure no viruses are present in this email.
pedalo limited cannot accept responsibility for loss or damage arising from the use of this email or attachments and recommends that you subject these to your virus checking procedures prior to use. Any views or opinions presented are solely those of the author and not necessarily those of Pedalo Limited
Please consider the environment before printing this email
This is an awesome discussion. Well worth having.
To your point below, I definitely test when updating my base theme so a blow up doesn't usually happen on prod.
I think you and others have the right idea on why not to do subthemes. If you plan to build your theme and never upgrade the theme, it makes sense. There have been times when I want to upgrade the Blueprint theme and it has been so nice to just drop in the new version without touching my subtheme. Also, I had to upgrade a Drupal 5 site to Drupal 6 and having a subtheme seemed to make that go smoother/quicker.
This may be another case where the "right way" is depending on your needs.
Thanks! Mark
On Mar 14, 2011, at 8:39 AM, Fred Jones wrote:
The main reason I would subtheme is to allow easier updates to your framework/starter theme from d.o. If you have just hacked those themes downloaded from d.o, you have to merge your changes back in. Of course that can be done with git, but I still think sub-theming is better.
But then you run the risk of the upgrade breaking something, no?
This is an awesome discussion. Well worth having.
Cool. Let it not be said that I never did anything good. :)
I think you and others have the right idea on why not to do subthemes. If you plan to build your theme and never upgrade the theme, it makes sense. There have been times when I want to upgrade the Blueprint theme and it has been so nice to just drop in the new version without touching my subtheme. Also, I had to upgrade a Drupal 5 site to Drupal 6 and having a subtheme seemed to make that go smoother/quicker.
OK, this makes sense.
Andy, your point is also *very* well taken. I have always approached themes are just a wrapper for HTML/CSS/JS and never really delved into the functionality aspect. I always figured that the majority of that stuff was for people using the theme "out of the box" and wanting to make changes without coding. But I think in D7 especially, more functionality is being opened up for coders also.
Thanks for the feedback everyone.
F
just making a backup of the DB and old code should be enough--if something goes wrong, the site can be restored in about 60 seconds
I'm always amazed, humbled and shamed when people give these sort of figures as their own personal accomplishment metrics. After 5 years doing only Drupal professionally, and having been in I.T. for 18 years, including time as a Unix System Administrator for a couple of Universities, I STILL can't accomplish in 60 seconds much more that the thought "Hmmm something has gone wrong here".
Why am I so stupid? Everybody else can restore a whole site in 60 seconds . :(
;-)
On 14/03/2011, at 11:47 AM, Fred Jones wrote:
These days, theme's are viewed much like contributed modules which code you usually do not alter but rather override in other places. Personally, I think themes are quite different from modules and that there's a good chance that future ameliorations of a theme produce unexpected results on your website but, nevertheless, this seems to be the current mainstream thinking nowadays.
Yes, that's exactly what I feel. I was always nervous that I will make a subtheme and then in 2 months we will upgrade and then my client will call me on the phone frantic that I "broke" page X. He won't know that it's due to a CSS change in the new version of the theme.
Has anyone else experienced this? Or is it basically considered safe to use a subtheme and rely on the main theme author not to do something stupid?
Yes of course one should do upgrades on a test site etc. but everyone knows that for a simple module upgrade, just making a backup of the DB and old code should be enough--if something goes wrong, the site can be restored in about 60 seconds. I would *tend* to think the same for themes...
F
[ Drupal support list | http://lists.drupal.org/ ]
====================== John Saward B.Sc. Director and Problem Solver - Studio Also Pty Ltd Drupal CMS solutions www.also.com.au www.drupal.com.au john@also.com.au 03 5968 1541 0418 610 706 Skype: studioalso FB: john.saward (personal) FB: studioalso (business) ======================
-
"Roberto Gorjão" -
Andy Fowlston -
Fred Jones -
John Saward -
Larry Garfield -
Mark Shropshire -
Ryan LeTulle