Try putting a .theme file into themes/ without any subdir. Enable it (maybe just saving theme settings is enough), Nothing will work after this. To restore your site: remove the offending theme, issue an SQL: DELETE FROM {system} WHERE type='theme' and save theme settings again.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chx’s picture

effects HEAD, too.

chx’s picture

Title: Putting a .theme file into themes/ makes all themes not working » [QUICKFIX] Putting a .theme file into themes/ makes all themes not working
Assigned: Unassigned » chx
FileSize
542 bytes

Here is a patch which fixes the problem. However, I do not have the feeling that this is "the" solution. Feel free to come up with something better.

chx’s picture

Title: [QUICKFIX] Putting a .theme file into themes/ makes all themes not working » Putting a .theme file into themes/ makes all themes not working
Assigned: chx » Unassigned

Oops forgot to set to CVS, 'cos the fix is against HEAD. Not that 4.5.2 does not need a patch...

chx’s picture

Assigned: Unassigned » chx
Anonymous’s picture

While this patch would allow a theme to be placed directly in the "themes" directory, it disables the ability for that theme to use a "style.css" file, which is inconsistent. I would prefer a patch that enforces the criteria that themes MUST be placed in a SUBDIRECTORY of "themes" -- themes placed directly in the "themes" folder should be ignored... maybe we could send the admin a drupal_set_message that would tell them about the problem when visiting admin/themes too.

chx’s picture

FileSize
693 bytes

Anonymous is right. I have made a better patch. Please commit, this is very important IMHO.

chx’s picture

FileSize
712 bytes

Message was wrong.

chx’s picture

May I know why this is not getting commited? This is a very nasty issue, the poor site admin who tries a few themes and misplaces one is totally baffled why his themes do not work after this.

Dries’s picture

- That should probably be an error message, rather than a status (success) message.

- The coding style needs work.

- For consistency the theme name should be wrapped in em's.

- I'd prefer not to scan ./themes for .theme files and to ignore any .theme files places directly in ./themes.

Won't commit as is.

chx’s picture

- That should probably be an error message, rather than a status (success) message.

Ah, I was never aware of the second parameter of drupal_set_message! One always learns.

- The coding style needs work.

Spaces, my doom :(

- For consistency the theme name should be wrapped in em's.

Understood.

- I'd prefer not to scan ./themes for .theme files and to ignore any .theme files places directly in ./themes.

Well. Only a system_listing call happens before my patch in system_theme_data. All system_listing does it sets up a maximum of two starting points for a recursive file_scan_directory ($directory and $config/$directory) and file_scan_directory has no options for such an exclusion and it does not seem appropriate to change file_scan_directory only for this. Surely I miss something in here, but I still think that this special thing shall be done in system_theme_data. If this is accepted, the minor (from a coding point of view they are minor) issues will be corrected in no time.

chx’s picture

FileSize
3.2 KB

This is a whole new approach. Some credits: to nsk, because he triggered the bug and bought me Shadow of The Giant for fixing his site, but I took that as a sponsoring to fix this bug. To Steven for the $depth-as-argument and to Dries 'cos of "sensible defaults".

We do not throw warning this time 'cos system_theme_data is not even aware of the faulty themes.

chx’s picture

FileSize
3.31 KB

PHPdoc and style fix

chx’s picture

FileSize
3.29 KB
chx’s picture

FileSize
3.27 KB
Dries’s picture

Can't you perform the $depth <= $max_depth check before you call file_scan_directory()? Looks like you could move the check down to the if-clause surrounding the call to file_scan_directory():

 if (is_dir("$dir/$file") && $recurse) {
chx’s picture

FileSize
3.26 KB

Ah, you are proposing that we do not even call file_scan_directory when we are too deep? That's a wise idea, as usual from you ;) However, it can not be in the if-clause surrounding the call to file_scan_directory(), 'cos if you are expecting files, and hit max_depth, you may get some directories too. So it got a separate if.

chx’s picture

Any problems?

Dries’s picture

Committed to HEAD.

Anonymous’s picture