Posted by Daniel Wentsch on January 23, 2013 at 9:01am
7 followers
Jump to:
| Project: | Omega |
| Version: | 7.x-4.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hey there,
I'm just trying to dive into the new Omega 4 system and have a rather simple question:
For example lets say I simply want to disable the region $sidebar_second - where am I supposed to set this? I'm not talking about layouts and I'm just working on a simple subtheme created with the drush wizard.
I guess it would work to just unset($sidebar_first) in page.tpl.php, but I guess that's not the "right" way to do it.
As far as I understand in the previous version of Omega those settings came from the database. Am I right that this is now supposed to be stored in code or should one write his own theme settings to store such things in the database?
Thanks & regards,
Daniel
Comments
#1
Hey,
Right.. So instead of configuring those things through the GUI you would now go into your theme's .info file and manually override the regions there and simply leave out the $sidebar_first one!
This link might be helpful: http://drupal.org/node/171206
Taking a look at bartik.info might give you the right idea too. You simply put the regions that you wish to use into the .info file of your theme and then clear the cache afterwards.
But you raised a good point here... Maybe our default starterkit should contain the default regions in the .info file so people know whats going on instead of simply falling back to the default regions (@see link).
#2
Thanks for explaining.
The funny thing is that using my subtheme's .info file was one of the first things I tried to do, but I didn't succeed.
Withe following .info file $sidebar_second is still being printed, caches flushed multiple times of course.
regions[sidebar_first] = Left sidebar;regions[sidebar_second] = Right sidebar
regions[content] = Content
regions[header] = Header
regions[footer] = Footer
regions[highlighted] = Highlighted
regions[help] = Help
regions[page_top] = Page Top
regions[page_bottom] = Page Bottom
Edit 1:
Ok, the regions my info file seem to get ignored entirlely. A newly added test region doesn't show up at all. Do I have to do something that my info file gets parsed properly?
Here's the compelte content of my info:
name = nox
description = Omega based theme for nachtaktiv
screenshot = screenshot.png
engine = phptemplate
core = 7.x
base theme = omega
regions[sidebar_first] = Left sidebar
;regions[sidebar_second] = Right sidebar
regions[content] = Content
regions[header] = Header
regions[footer] = Footer
regions[highlighted] = Highlighted
regions[help] = Help
regions[page_top] = Page Top
regions[page_bottom] = Page Bottom
regions[test] = Test
Edit 2:
Please irgnore my previous statement, the newly added region does show up (I just forgot to output it in page.tpl.php). Problem remains: $sidebar_second does show up although being commented out in the info.
#3
Do you have omega tools installed and the layouts extension enabled? Because then it obviously pulls the sidebar_second region from the epiqo layout. Note: In order to be able to assign blocks to regions when using a omega layout we are pulling the region information from all layouts (and the main theme .info file) together.
However, you just brought up a good topic.. I have to write a patch for ignoring non-active regions on render time so that only the regions that are exposed by the active layout (or plain page.tpl.php) are forwarded to the theme layer.
But yeah... Turn of the layout extension for now if it bugs you.
#4
<?php
function omega_block_list_alter(&$blocks) {
if (omega_extension_enabled('layouts') && $layout = omega_layout()) {
foreach ($blocks as $key => $block) {
if (!array_key_exists($block->region, $layout['info']['regions'])) {
unset($blocks[$key]);
}
}
}
....
?>
Oh, apparently we are already doing that... but only the other way round. So a layout only gets the regions that it actually declares. However, when the layout extension is enabled we don't ignore layout regions on the main page.tpl.php...
Will fix that later. However, it's not a minor issue because it doesn't do anything bad to your site. Just ignore the regions in your template file and they won't appear :P.
Fix incoming tomorrow.
#5
Thanks for your help.
Unfortunately I won't be able to investigate further until probably Sunday .
I can say for sure though that the layout extension is turned off as I got confused by that concept a bit and wanted to start off as minimal as possible.
#6
Yeah, no worries... I will look into it and have a fix ready today in the evening. I am pretty sure that I know what's going on there.
#7
I just committed something that should fix this for you... Please try and see if it does: http://drupalcode.org/project/omega.git/commit/b0fac0c5120afa21c843a8c14...
If it doesn't I might've misunderstood the problem that you were describing :).
#8
Please report back if that fixed your problem. Otherwise I will deep a bit deeper into it :).
#9
Okay, first of all sorry for my delay.
I just patched template.php and had the same result, the region settings of my .info don't seem to have any impact on the regions shown. Possibly I'm still not getting the whole concept. I'm gonna update to alpha7 now and start over again.
Would you recommend not using the layout extension at first, as long as no different layouts are needed in different contexts?
On a different note: I always get the message: "The settings for this theme are currently served from a variable. You might want to export them to your .info file."
Is there any documentation how to set those settings from a info file?
Update: are Dummy Blocks supposed to show up to indicate regions that were disabled from your info php? I guess that might be what is confusing me all the time.
#10
I was also confused by the message about theme settings being served from a variable. I did some looking into it and found that "drush omega-export" can be used to export the settings from the database to your .info file, and "drush omega-revert" will delete the settings from the database. So I exported and then reverted the settings for my subtheme and the message went away.
#11
@dswier: You can also simply go "drush omega-export --revert" (exports and then reverts immediatly). Exporting theme settings is a nice feature for deploying your theme without having to worry about losing any theme settings. It's also a way to put the theme settings into version control.
@daniel: Are you saying you are using a layout? Because if you are using a layout then you have to specify the regions in the layout's info file (which is foo.layout.inc). The regions specified in the theme's .info file are only used if you don't use any layouts.
#12
Hey guys,
thanks for that tip about the drush command, sounds very cool to be able to put those settings under version control, gonna try it in the evening.
I didn't use layouts at the time posting but I didn't come any further. So what I did afterwards was creating a subtheme (using drush owiz), copy and rename the simple layout to my subtheme and started working from there on. Now everythings seems to work as expected, regions disabled in mylayout.layout.inc don't show up anymore, unless debugging blocks are enabled.
Edit: Talking about debugging blocks: is it desired behaviour that debugging blocks also show disabled regions? This was really confusing, even more as they can easily break your intended layout.
#13
@Daniel: Yes, that is _exactly_ what debugging blocks are for. Showing regions that have no blocks in them. So that you can start building the layout without having to put blocks into them. In the latest dev version this feature was enhanced so that you can now decide which regions you want to demo.
How do you disable regions btw.? "Disabling" (or rather 'removing') a region means that you entirely remove it from the .info file (don't put anything like regions[foo] = false in there or something) and that you remove it from the corresponding template file.
Drupal will only allow things to be rendered with blocks if the layout or native page.tpl.php has a region for it. It's really that simple. Could you maybe upload a screenshot of your entire subtheme file / directory tree and pastebin the contents of theme.info / layout.layout.inc and the corresponding template file? I can't figure out what might be wrong otherwise. It sure sound slike there is just a misunderstanding here.
Please try the latest dev version.
#14
I can also confirm some odd behaviour when disabling/adding regions (using latest 7.x-4.x-dev):
1) Disabling region bug:
Having created a new layout based on the included 'simple' layout, if I comment out a region in the layout's .inc file and in the .tpl.php file the region does disappear from 'Region demo mode' but continues to show in the block admin UI (though adding a block to the region does nothing in terms of display).
2) Adding region bug:
Attempting to add a new region to a subtheme layout appears to do nothing. I attempted to added an Omega-3-style 'postscript' region to my layout's .inc and .tpl.php files but it doesn't appear anywhere thereafter (blocks admin, region demo mode etc). I should add that adding a new region to the subtheme's .inc file (not the layout) seems to work as expected.
May I also take this opportunity to congratulate/thank you all on a very promising start to this new version of Omega. I'm very excited by the new possibilities. Top work!
#15
@danbohea: The list of regions defined in the .layout.inc file has no effect on the regions that are available globally. You still have to define the regions through the .info file of the theme. That's a technical limitation.
So: Declare region in .info file of the theme to make it available in the first place, then, in the .layout.inc file define that that particular layout uses that region. It's a bit frustrating that one has to do the region definition twice but it's really the only way. That reminds me that we still have to add a warning message to layouts that declare to require regions that are not defined in the .info file of the active theme. That will probably help with the confusion.
#16
Thanks for the info. I'll give that a whirl and reply shortly.
#17
That works very well. Can't believe I didn't try that myself, I guess it was getting too late. Thanks again.
#18
Great! Guessing we can set this to fixed now?
#19
Automatically closed -- issue fixed for 2 weeks with no activity.