I had modded a local-sample.css to local.css. Upon updating theme via update page, local.css was gone and local-sample.css was back. Is this behavior caused by core or by the theme? I posted to the theme issue queue and he said it was not the fault of the theme.

Comments

bfroehle’s picture

Issue tags: +Update manager

I assume the theme in question is Danland.

The current behavior of update manager is to delete the entire theme or module directory before installing the new version. This is the only way we are able to ensure that files which are no longer distributed with the theme or module are removed.

Perhaps we can improve by adding a warning that any local customizations to a theme will be overwritten.

Branjawn’s picture

Are you psychic?? Yes, I am using Danland. And yes, a warning would be great! Luckily I only had about 10 lines of custom css and I remembered them all.
How hard would it be to leave local.css alone since that is becoming established protocol in place of subtheming.

bfroehle’s picture

Not psychic -- see http://drupal.org/user/406556/track

We'll consider this addition. For the moment, be sure to always back up your theme before updates.

bfroehle’s picture

Category: support » feature
Branjawn’s picture

Thanks Bradley!

dww’s picture

Title: Core update of theme erased local.css » Detect and gracefully handle locally modified files during updates via the Update manager
Version: 7.0 » 8.x-dev

Yeah, this is "by design". Unfortunately, adding a warning means breaking all the core translations (or at least that the warning won't be available in other languages until those translations are updated). And certainly anything smart like a new feature trying to preserve locally modified files isn't going to be allowed in a stable release. So, I think this is going to have to be D8 material at this point...

caschbre’s picture

I'm wondering if a D7 option would be to allow for themes/modules to identify files (in the .info file??) that should not be updated with the update manager. This would at least give themes the ability to not have local.css updated.

bfroehle’s picture

For the time being, a sub-theme type mechanism like Zen or AdaptiveTheme, is really the best way to keep local customizations (short of doing everything in version control and merging in upstream changes).

bfroehle’s picture

Also, I believe Drush can be set up to take backups of themes and modules before upgrading them --- their mechanism for doing this might be worth investigating as well.

Branjawn’s picture

I just want to say I appreciate everyone's consideration. My local DUG post was not as kindly accepted. It was more of "you're an idiot for doing that".

bfroehle’s picture

The near term solution might be to put a warning in the update manager that "All local file modifications will be overwritten." or similar.

jhedstrom’s picture

Version: 8.0.x-dev » 8.1.x-dev
Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)
Issue tags: +Needs issue summary update

I'm inclined to mark this "won't fix". There are well-supported mechanisms for patching core (eg, Drush make, Composer). Hacking core (eg, w/o documentation or a patch) has never been supported.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

Closing as outdated. If still a valid feature request please reopen updating the issue summary per #12

Thanks!