Posted by Branjawn on January 7, 2011 at 2:02pm
Just a warning, updating a theme via update.php will erase local.css for that theme. Apparently, this is not a bug... but also, there is no warning. Hopefully that will be rectified soon! Just wanted to let others know.
You can read more about it here: http://drupal.org/node/1018052
Comments
Do not hack core / modules
More specifically, the best way to avoid having your things deleted is to not modify any core or contrib module/theme ever. If you have to modify something (avoid if at all possible), make a patch and store it somewhere reliable so you can re-do it later.
Using a source control system (CVS, SVN, git) and regular folder + db backups are also highly recommended.
Sure local.css is convenient... until it's not. It would be better if it used a path outside of the theme folder.
That the update process doesn't warn you is a usability bug, but it will only bite you if you aren't doing things "the Drupal way." All the same caveats apply to manual upgrade processes.
Ken Winters
I agree with Ken, AND also consider
You should subtheme, rather than directly edit a theme. Once you've subthemed, you never want to edit the base theme. Updating and theme and replacing the theme files isn't a bug, that's the update process "doing it's thing."
See ya at the D7 lunch,
Kyle
I'm with Kyle that the best
I'm with Kyle that the best way to customize themes are to create a sub-theme. It'll avoid the local.css overwrites that 'could' happen. When I modified a local.css file for a theme I was using before I didn't pay attention and copied the update overtop and lost my local.css. That made me want to keep with sub-themes. For those themes that I still have a local.css I now have it burned in my brain to either not overwrite that file and make sure I have it backed up.
With the D7 introduction of the update manager I hadn't thought about the local.css issue since I haven't come across it myself. The update manager probably needs some way of handling this issue but I wouldn't wait for it. Definitely keep up on sub-themes and / or backup your local.css files.
-
@foggyperspectiv | foggyperspective.com (blog)
D7 custom themes
An option would be to copy and rename the theme in question to something like "my_theme" and put it in /sites/all/themes/. That way, no changes would ever be over-written by core or theme updates. Happy theming!
.info
If you do rename it, you will probably also need to remove the project references from the .info file so it won't try to update.
The disadvantage here is that any bug fixes to the base theme will have to be applied manually, and you have to actually pay attention to them.
Ken Winters
Good point. Also the .info
Good point. Also the .info file for "my_theme" needs to be declared as a subtheme of "theme" and any custom css files need to be declared as well. @Branjawn, did you do all of that and have your subtheme in sites/all/themes and your stylesheet still got erased? If so, then it sounds like a pretty important feature request for D7... glad you pointed it out.
Another option if you are just making a few style changes is the Color Module, which got a big overhaul for D7 so maybe that is a good solution, but of course only for minor style changes.
Subtheming vs Local.css
Yes, I've subthemed before, but was lead to believe (Drupal kool-aid?) that local.css was the new awesome (lazy) way of doing things. I feel it was a grave oversight because: 1) the easiest way to alter a theme is by local.css 2) if someone, like me, uses that, they will obviously update via web ... I mean, they should have seen this coming. Module updating via web makes sense, you don't sub-module or alter modules (ideally) but we have been led down the road of using local.css.
Anyways, from now on I'll either update manually or remove theme.info and local.css before updating and then replace them after updating.
There is, and never was,
There is, and never was, anything "magical" about local.css. Using it is still hacking a theme, and the best practice for updating anything has always been to completely delete the directory and re-install a fresh, new copy. I don't know that I've ever heard of any Drupal Kool-aid that encouraged people to make changes to a theme and then update with abandon. I know with Fusion, we always encourage users to keep a back up of their customizations when they update their theme.
local.css is just a compromise for when you know people are going to try to hack the theme, and at the very least allows some separation from the theme files and a users' additions.
It was also a compromise because before Drupal 6.19 (I think) you couldn't create sub-sub-themes, so with themes based on a theme framework there was no way to create a sub-theme to make customizations with.
Misleading documentation?
Top Notch Themes has a page called USING LOCAL.CSS and here is the main text:
When I read that I don't see any warnings about using local.css, actually the instructions sound like they condone using local.css?
And to clarify, this was not on a production site, I was just messing around with Drupal 7 and setting it up to look similar to a site I made with D6 just to see what it would look like. For those of you chastising me for not having a backup, I didn't need one. The whole reason I set it up was to poke around Drupal 7 and learn what everything does.
More evidence of the misconception...
Here is a comment in a Drupal thread regarding Acquia Prosper (emphasis added): ...That's one of the reasons we have a "local-sample.css" file in Acquia Prosper's css directory. Just rename it as "local.css" and any css code you add to it will change the look of your theme, but won't be overwritten when you update. (http://drupal.org/node/631126#comment-)2266816
And from Aquia Marina documentation on DO
http://drupal.org/node/357261#local-css
So, by now I'm either misguided/delusional or I've made my point. The point being, it appears that the documentation suggests creating a local.css file will ensure "your changes will not be overwritten when upgrading to a new version of the theme".
And local.css will not be
And local.css will not be overwritten - if you update a theme, there will not be a 'new' local.css to overwrite the 'old' local.css. Nothing magically protects local.css from being deleted if the entire theme directory is deleted. It simply there to "allow for smooth upgrading", which is does, by keeping customizations separate from core files. Nothing about local.css could react to what upgrade.module does to it, and upgrade.module isn't going to be told to do anything special with local.css
The problem isn't that local.css is a special file and should be treated as a special file by the upgrade module - there's nothing special about the file, it is just a convention adopted by some theme developers to compensate for the lack of ability to sub-sub-theme. The issue is simply that your expectation of what upgrade.module would do were different than what it did.
Documentation refers to the Old Way?
I haven't had a chance to kick the tires of D7 yet, but I wonder if this relates to an 'issue' (by design, I think) I used to have when using drush to update modules. The issue goes like this: normally (in D6 and earlier days, and not using drush), one would update a module by downloading the .tgz file and either (a) untar locally and then ftp overtop the original project in the relevant sites folder or (b) ftp the .tgz file to the modules or themes folder and use shell to untar directly on the server. Both (a) and (b) methods will overwrite files of the same name as those in the new distribution. For themes, since local.css doesn't exist unless you create it yourself, there's no new version to overwrite your custom version - which is what the existing documentation refers to.
With drush update, though (just referring to the issue I found before the D7 days), the original module/theme's project folder is literally moved to a backup location and a new version is created from scratch. So, if you had a custom local.css file in your theme, it gets moved with the old code, and the new verson doesn't have your changes (unless you remember to copy the local.css from the backup location).
So, what I'm wondering is: is D7's new update feature doing what drush has always done: zapping (or moving) the entire old project folder, and then creating a new one from scratch (hence the loss of local.css)? And if it's moving the old folder, where's it putting it, so you can retrieve your custom local.css, theme images, etc., and even changes to .info files?
Sorry I don't have an answer here, but certainly the documentation for all those local.css-supporting themes needs to be updated...
best practice when updating
best practice when updating has always been to completely delete the old theme/module folder and re-upload a fresh copy of the updated project. This isn't anything new for D7 or drush. Any customizations to any theme/module should always be backed up, either in version control or on a development or staging site. It's always been a bad idea to have only one copy of anything.
Deleting old files
When you update a theme / module, you need to be certain not to leave old files in place that have been deleted in the newer version (will often break your site in subtle ways). The easiest safe way to do this is to delete the old folder entirely and replace it with the new one, which will also delete local.css. Your local.css will only be safe if you drop the new theme on top of the old (bad) or remember to replace it manually.
So, local.css is still a problem. It's better than spreading out your hacks (easier to migrate them forward), but it's still a hack and entails all the same difficulties.
Ken Winters