Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Hi all
Just wrote a script to do core updates and was looking for a method to run update.php from the command line.
So I came across drush and am really impressed so far. Am planing to use it for all other kinds of tasks now as well.
Anyway - for the original task I've wanted to use it, it shows some unexpected behavior: _all_ themes get disabled when
running "$ drush updatedb". So afterwards when visiting the website, I'm back on garland and would have to enable them again.
Of course, there might be workarounds, like saving the status before and restoring after updatedb. But I just checked: update.php
(manually, from the web) doesn't disable any themes. So "updatedb" which pretends to automate this should, imho, also not do that !?
The problem, I found out, is the call
from drush/commands/core/drupal/update_6.inc: update_main_prepare()
to drush/includes/environment.inc: drush_get_projects()
to drush/commands/core/drupal/environment_6.inc: drush_get_themes()
to drupal/modules/system/system.module: system_theme_data()
where "db_query("DELETE FROM {system} WHERE type = 'theme'");" deletes all themes. They are restored later in that function but the "status" is lost.
So system_theme_data() should probably be avoided on drupal 6 (or fixed).
However.
I think I will go on hacking drush on my site for now - probably dropping the drush_get_projects() call from update_main_prepare() ... or something like that :-)
But would be nice to have that fixed.
Thank you in advance
Greets - Patrick
PS:
autsch ... it happens even when no updates are actually performed ... just try yourself if you're brave
$ drush sql-query "update system set status=1 where type='theme';" will more or less restore
the state... sigh ... thought that drush was quiet popular - how come nobody noticed so far ... ?
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 762754.patch | 1.34 KB | jonhattan |
Comments
Comment #1
patrick2000 commentedduplicate of http://drupal.org/node/523194
Comment #2
jonhattanThe problem here is similar to #756228: pm-enable and pm-disable not working for themes.
In summary:
* _system_theme_data() stores an array in a static variable. This array is returned. Code outside can alter this array and in fact it is altered for example in list_themes(). Related issues in core: #305653: Themes disabled during update, #632080: _system_theme_data() should clone the returned objects., #759766: call to system_get_files_database via system_theme_data overwrites changes made directly to database.
* system_theme_data() is destructive by removing themes from the system table and re-inserting them.
* a piece of code calling system_theme_data() twice will disable all themes. This was the problem in issue 756228.
* a piece of code that calls _system_theme_data(), alter the result, and calls system_theme_data() may disable all themes.
Now the problem has moved to update_6.inc:
* This diff: http://drupalcode.org/viewvc/drupal/contributions/modules/drush/commands... was part of #537280. At that time drush_get_projects() was based on _system_theme_data() so the problem was not present. It was changed to system_theme_data() to make pm commands work with themes.
* drupal_maintenance_theme() calls list_themes(), that will alter the result of _system_theme_data(). After that, update_6.inc do a call to drush_get_projects() [See: http://drupal.org/cvs?commit=315914]. After that, update_check_incompatibility() calls system_theme_data() via drush_get_themes(). There're two calls to system_theme_data() when the static in _system_theme_data() is already corrupted by the initial call to list_themes(). Those two calls mean two times for themes to be disabled. They got disabled man.
I think the call to drush_get_projects() introduced in commit 315914 by Adrian is specific to
aegiropen atrium. And I think my posterior change to drush_get_themes() to call system_theme_data() breaks it.Part of the fix is to revert update_6.inc to _system_theme_data() and module_rebuild_cache(). This file is D6 specific and derived from update.php no need to get 'closer' to drush api. This will fix the first theme-disabling task.
Comment #3
moshe weitzman commentedAny chance we can get a patch?
Comment #4
jonhattanPatch featuring:
* remove duplicate code
* revert to use _system_theme_data and module_rebuild_cache
* a fix for the issue (a workaround of the problem in core) and a comment that explains it
Comment #6
moshe weitzman commentedcommitted. thanks. please reopen if any problems arise. i did not test this.
Comment #7
patrick2000 commentedHello again...
Just wanted to say thank you very much, Mosche and Jonhattan, for fixing this.
Sorry for mixing up "themes" and "modules" first and then not showing up any more for a long time after creating a bunch of issues.
I'm glad it's fixed now. Looking forward to drush 3.0 ... :-)
Cheers
Comment #8
asb commentedI can not reproduce the fix, the issue still occurs on my sites. Description: #780868: Updating a module through Drush disables default theme
Comment #9
pimok3000 commentedI can confirm this problem occuring every time i update some module via drush. I have read through all the related issues upgrading fusion/acquia_prosper theme and skinr module to the latest versions. To reproduce the problem i now simply have to dl and en some module go to the admin/build/themes and seeing that the acquia_prosper theme is the default but NO theme is active. Logging out shows the site without any css, reloading the page gets the css back, logging in and going to admin/build/themes still shows NO theme active even though it shows all of my fusion/acquia_prosper css in a normal way.
Comment #10
asb commentedI went to HEAD again and haven't experienced this issue for several hours. I think it's really fixed now. Closing the issue.
Thanks & greetings, -asb