Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#16 | themefix_6.patch | 3.26 KB | chx |
#14 | themefix_5.patch | 3.27 KB | chx |
#13 | themefix_4.patch | 3.29 KB | chx |
#12 | themefix_3.patch | 3.31 KB | chx |
#11 | themefix_2.patch | 3.2 KB | chx |
Comments
Comment #1
chx CreditAttribution: chx commentedeffects HEAD, too.
Comment #2
chx CreditAttribution: chx commentedHere 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.
Comment #3
chx CreditAttribution: chx commentedOops forgot to set to CVS, 'cos the fix is against HEAD. Not that 4.5.2 does not need a patch...
Comment #4
chx CreditAttribution: chx commentedComment #5
(not verified) CreditAttribution: commentedWhile 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.
Comment #6
chx CreditAttribution: chx commentedAnonymous is right. I have made a better patch. Please commit, this is very important IMHO.
Comment #7
chx CreditAttribution: chx commentedMessage was wrong.
Comment #8
chx CreditAttribution: chx commentedMay 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.
Comment #9
Dries CreditAttribution: Dries commented- 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.
Comment #10
chx CreditAttribution: chx commented- 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.
Comment #11
chx CreditAttribution: chx commentedThis 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.
Comment #12
chx CreditAttribution: chx commentedPHPdoc and style fix
Comment #13
chx CreditAttribution: chx commentedComment #14
chx CreditAttribution: chx commentedComment #15
Dries CreditAttribution: Dries commentedCan'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():Comment #16
chx CreditAttribution: chx commentedAh, 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.
Comment #17
chx CreditAttribution: chx commentedAny problems?
Comment #18
Dries CreditAttribution: Dries commentedCommitted to HEAD.
Comment #19
(not verified) CreditAttribution: commented