Posted by nedjo on October 14, 2005 at 3:21pm
| Project: | Drupal core |
| Version: | x.y.z |
| Component: | theme system |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
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.
Comments
#1
Here'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.
#2
I'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.
#3
Installed 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
#4
Works for me in terms of enabling other themes and having blocks appear.
#5
Sorry, 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.
#6
The 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?
#7
Ah -- 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!
#8
Okay, 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.
#9
Intersting that this improved the date widget for the codemonkeyx archive.module but, upon replacing the core archive.module I get the following error:
PHP Fatal error: Cannot use string offset as an array in includes/form.inc on line 189This seems to be the same problem as this bug report.
#10
Wrong thread, sorry.
#11
Can some of the forms API wizards review this in depth?
#12
Well, 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.
#13
Thanks 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.
#14
Um... 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.
#15
#16
Committed to HEAD.
#17
i'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?
#18
coolcatt, please file a new bug for a regression if it is still happening on the latest HEAD.
Robin
#19