Prior to the forms API patches, region initialization for a newly-enabled theme was called in function system_settings_save(). When that function was eliminated (in patch #29465, creating system.module revision 1.236), the handling needed for theme region initialization was missed, so now themes don't initialize. Until this is fixed, theme regioning won't work.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | system-theme-block-init_1.patch | 1.2 KB | chx |
| #8 | system-theme-block-init_0.patch | 1.18 KB | nedjo |
| #1 | system-theme-block-init.patch | 878 bytes | nedjo |
Comments
Comment #1
nedjoHere's a quick patch, reviving the needed code for initializing regions in themes. I haven't tested this as I haven't yet updated a test site to HEAD.
Comment #2
drewish commentedI'd been having problems getting the pushbutton theme to work with HEAD (no blocks displayed). I tried applying this patch to see if it was related. Perhaps it's just a coincidence but it's fixed my theme problems.
Comment #3
WiMax commentedInstalled the patch in my drupal home directory.
Did this:
patch -Np1 -i modules/system-theme-block-init.patch
Output:
patching file system.module
Hunk #1 succeeded at 787 (offset 14 lines).
Went in and tried again to noavail.
Details:
Latest CVS Head.
Latest PHP and MySQL
Linux from scratch 6.1v2
See Also: http://drupal.org/node/34550
Comment #4
gtcaz commentedWorks for me in terms of enabling other themes and having blocks appear.
Comment #5
gtcaz commentedSorry, after further testing, I'm still having problems getting blocks to show up in other themes (even a copy of bluemarine in another folder) after applying this patch.
Comment #6
nedjoThe code I've added back in is triggered when a theme is set from disabled to enabled. Have you tried disabling the themes and then reenabling them?
Comment #7
gtcaz commentedAh -- it works if you enable the theme, save, then switch it as the default and save again. If you enable a theme and make it default in one action, you get the disappearing blocks problem. Thanks!
Comment #8
nedjoOkay, here's a revised patch that addresses the problem by moving the default theme reset call to after block initialization is called. I've now tested this and it fixes the issue.
Comment #9
gtcaz commentedIntersting that this improved the date widget for the codemonkeyx archive.module but, upon replacing the core archive.module I get the following error:
This seems to be the same problem as this bug report.
Comment #10
gtcaz commentedWrong thread, sorry.
Comment #11
dries commentedCan some of the forms API wizards review this in depth?
Comment #12
chx commentedWell, forms had little to do with this, our development cycle broke this, I really do not know how could we miss this out during the merge. However, I rerolled the patch and it seems good to go after a reroll.
I will not post a patch for every separate forms API issue, but this is NOT forms API.
Comment #13
nedjoThanks for rerolling it, you're right that this isn't a Forms API issue, I can confirm that the patch works and is ready to apply.
Comment #14
colorado commentedUm... I confirm that it works as well to make the blocks show again on all the themes.
HOWEVER, as long as bluemarine is checked (even when not set as the default) it overrides the selected default theme.
Comment #15
colorado commentedComment #16
dries commentedCommitted to HEAD.
Comment #17
coolcatt commentedi'm a newbie but I applied the last patch
coolcatt@www:/www/drupal$ cd modules
coolcatt@www:/www/drupal/modules$ patch -Np1 -i ../system-theme-block-init_1.pa
tch
patching file system.module
Hunk #1 succeeded at 785 (offset -2 lines).
coolcatt@www:/www/drupal/modules$ cd ..
coolcatt@www:/www/drupal$ mkdir applied.patches
coolcatt@www:/www/drupal$ mv *.patch applied.patches
and I still have the problem of no blocks showing up when I select another theme then bluemarine... any thoughts?
Comment #18
robin monks commentedcoolcatt, please file a new bug for a regression if it is still happening on the latest HEAD.
Robin
Comment #19
(not verified) commented