Hi,
I'm not sure if what I'm doing is correct, but it isn't working as I thought it would.
I have the following modules installed on top of the latest D6 release;
- Domain Access 6.x-2.0-rc9
- Domain Alias 6.x-2.0-rc9
- Domain Bonus: Login restict 6.x-1.x-dev
- Domain Configuration 6.x-2.0-rc9
- Domain Content 6.x-2.0-rc9
- Domain Navigation 6.x-2.0-rc9
- Domain Prefix 6.x-2.0-rc9 (haven't had to need to prefix so far)
- Domain Source 6.x-2.0-rc9
- Domain Theme 6.x-2.0-rc9
- Domain Views 6.x-2.0-rc9
I've got a primary domain and one subdomain setup both using the same theme
Now in admin/build/block I have assigned the the following blocks to my left region;
- Domain primary links
- Domain secondary links
Then in admin/build/domain/conf/1 under [menu settings] I changed to following;
Primary links menu: Do not use for this site
Secondary links menu: Do not use for this site
Cleared cache and all but when I surf to sub.mydomain.com I still see the Primary links menu (well just the menu items that have been published to all affiliates but still).
I expected no menu since I selected: Do not use for this site.
Are my expectations wrong and is this by design?
Have I to set some other variables somewhere?
Any help is greatly appreciated as the deadline is breathing down my neck....
Cheers
| Comment | File | Size | Author |
|---|---|---|---|
| #26 | domain_conf.module.domain-menu-title-as-block-subject.patch | 425 bytes | bartezz |
| #11 | domain_conf.module.patch | 1.08 KB | bartezz |
| #10 | domain_conf.module.patch | 916 bytes | bartezz |
| #3 | menu-settings-secondary-domain.gif | 6.22 KB | bartezz |
Comments
Comment #1
agentrickardSounds like a bug.
Comment #2
agentrickardCannot replicate. The setting and block works fine as far as I can see.
Make sure you are using the Domain Primary Links block and not the default Drupal Primary Links block. (Also make sure the blocks are set correctly for the themes on each domain.)
For debugging on each domain, check the value of $delta in line 553 of domain_conf.module. If your domains setting is "Do not use primary links" then this value should be zero.
Comment #3
bartezz commentedHiya,
Both my primary and secondary domain use the same theme.
For my region I have the following blocks (both on mydomain.com/admin/build/block and on sub.mydomain.com/admin/build/block);
Domain primary links
Domain secondary links
In my template I have;
In admin/build/domain/conf/1 I have the settings (see image).
Not sure what else I should set.
My domain_conf.module says
The only $delta I could find in the .module file is in the function domain_conf_block on line #488.
I've added some code here for debugging purposes;
Which results in these logs;
actie 2009-10-14 17:20 domain-secondary-links moderator
actie 2009-10-14 17:20 delta test moderator
actie 2009-10-14 17:20 domain-primary-links moderator
actie 2009-10-14 17:20 delta test moderator
But the difference in line numbers in our modules worries me, my domain_conf.info says;
; Information added by drupal.org packaging script on 2009-08-23
version = "6.x-2.0-rc9"
Thanx again for helping mate!
PS. what a big a$$ tree you had in your house man, made me think to take down the tree in my backyard as a precaution... yet I do love it's walnuts :)
Comment #4
agentrickardI am using HEAD, and there are some new lines.
See line 503ff in rc9.
Watchdog that $delta. And also check to see that your other domain-sensitive variables are working correctly. I suspect that domain_conf may not be loading properly.
Comment #5
agentrickard[ignore this]
Comment #6
bartezz commentedWill have to check tomorrow can't get to it from here, thanx!!
Comment #7
bartezz commentedHi,
Well I delta'd function domain_conf_block as such;
#503
This returns the following (09:46 is a page reload on primary domain / 09:47 is a page reload on secondary domain);
actie 2009-10-15 09:47 secondary-links Anoniem
actie 2009-10-15 09:47 test-delta-test Anoniem
actie 2009-10-15 09:47 primary-links Anoniem
actie 2009-10-15 09:47 test-delta-test Anoniem
actie 2009-10-15 09:46 secondary-links Anoniem
actie 2009-10-15 09:46 test-delta-test Anoniem
actie 2009-10-15 09:46 primary-links Anoniem
actie 2009-10-15 09:46 test-delta-test Anoniem
Does this info help?
Cheers
Comment #8
bartezz commentedHmm I altered the database table {domain_conf} a bit for debugging purposes (kinda hard to read a blob so I've changed it to longtext).
The serialized array that was saved into that is as followed;
Hope this helps in defining the problem...
Cheers
Comment #9
bartezz commentedWhat I don't understand is that in domain_conf.module in function domain_conf_block there is a variable_get that does the following;
This looks up the variables in {variable} and not the domain specific variables stored in {domain_conf} or am I mistaken?
Cheers
Comment #10
bartezz commentedBeen doing some exploring and I'm not sure if what I changed is ok or if it will cause more problems but it seems to work now.
I have attached a patch...
Let me know if my changes are ok?!
Cheers
PS. Hmmz on second thought we aren't there yet, yes it will load the correct menu for the secondary domain, but it uses the title of the menu from the primary domain as title for it... I'll look into that if you have a clue as to why please let me know!
Comment #11
bartezz commentedFixed the PS too... here's the patch.
Cheers
Comment #12
agentrickardYou shouldn't need to use domain_conf_variable_get() here. I tested that.
variable_get() reads from the initialized $conf array, not from the database, at this stage in the code. (Unless you're having a cache flush issue, but $conf should be initialized, and if $conf[$source] is empty, we fall back to $string.)
A better debug is to do this:
The question is: Why is the domain-specific variable not loading for you. The problem may be back up the stack in domain_conf_domain_bootstrap_full().
Since the value is 0, !empty is FALSE. But that doesn't explain why its working correctly for me.
Comment #13
agentrickardBut that isn't the problem, either. Here's the debug I get for a domain set to 'do not use primary links'.
Check the 'domain_bootstrap_modules' value in your {variable} table. It should include domain_conf, as in the above output. If not, this variable routine never runs.
Comment #14
bartezz commentedThe domain_bootstrap_modules in {table} is a serialized array containing this
When i do this in domain_conf.module/domain_conf_block()
I get a very large array with variables under which;
[menu_default_node_menu] => primary-links
[menu_primary_links_source] => primary-links
[menu_secondary_links_source] => secondary-links
Argh!
Comment #15
agentrickardRight, and these values should change when you switch domains, to whatever is set under Domain Conf:
[menu_default_node_menu] => primary-links
[menu_primary_links_source] => primary-links
[menu_secondary_links_source] => secondary-links
Comment #16
bartezz commentedThey don't... tried changing the slogan but it doesn't change either...
Am now completely removing the modules and installing it and setting it up again to see if that does anything!
Cheers
Comment #17
agentrickardAh-hah. You are having an execution problem.
Is your settings.php configured correctly? Are you seeing any error messages?
Comment #18
bartezz commentedDisabling and uninstalling modules didn't do anything.
No error messages so I'll check the settings.php, maybe my changes got overwritten?
Cheers
Comment #19
bartezz commentedHmmz, I had this;
in the settings.php of [default] but in the settings.php of [mydomain.com] it was gone (maybe wrong revision, dunno?)
Now that I put it back in there it still doesn't work...
:'(
Comment #20
agentrickardWhy do you have two settings folders? That may be your problem.
Comment #21
bartezz commentedIt's because I work locally for development and then have a copy running on a shadow location for the client to look at, every x days I upload the whole lot to the shadow location. With 2 settings folders I don't have to change the settings.php in [default] all the time...
I removed the whole dir [mydomain.com] from [sites] now but it still doesn't work (settings.php in [default] is correct).
Won't it work cause I've had this dir in there all the time??
Cheers
Comment #22
agentrickardI don't know. I can't help on this anymore. The problem is possibly that subdomains are not finding the 'right' settings.php file. This is especially true if you use domains like these:
oneexample.com
thiseexmple.com
Instead of:
one.example.com
this.example.com
This is all configuration error.
Comment #23
agentrickardJust put an IF conditional in default/settings.php to load the proper db based on server env.
Comment #24
bartezz commentedCan't work out whre things have gone wrong... tried almost everything to no avail.
Have started with a clean install and configuring everything all over... gonna be along weekend!
Cheers and many thanx for your help!
Bartezz
Comment #25
bartezz commentedForgot to close
Comment #26
bartezz commentedHi agentrickard,
Sorry to open this one again... came accross another problem with the menu title being used as block->subject.
in domain_conf.module function domain_conf_block the menu blocks are being build like this;
As you can see $data['subject'] is set with $menus[$string]
Because this was returning unexpected values (the title of the primary and secondary menu for the main domain) I echoed some values;
Which results in:
So as you can see $menus[$string] will return $menus['primary-links'] => 'Over ons'.
I'm not sure if this is by design but I've changed it to $data['subject'] = check_plain($menus[$delta]);
and now I'm getting the correct block->subject printed.
I'm sure it's not caused by multiple settings folders as first was the case :)
I rebuild the whole website since then....
Cheers
Comment #27
agentrickardYes, but regardless of the source, this _is_ the Primary Links block, so that is the appropriate title. If you want a different menu block, you just use the one provided by core.
Comment #28
bartezz commentedHi,
I don't understand, I don't (think) I want a different menu block, I would like each subdomain to have their own custom menus shown in the same spot as the primary domain,
#1 - For each subdomain I create a new alternative primary and an alternative secondary menu.
#2 - Under admin/build/domain/conf/3 I tell the module to use menus I've created for domain 3 as the primary and secondary menus.
#3 - in blocks I'm using [Domain primary links] and [Domain secondary links] blocks
[Domain primary links] and [Domain secondary links] will look at my setting made in #2 and load the corresponding menu_tree, then why show the title of a different menu and not of the corresponding menu?
Cheers
Comment #29
agentrickardThat makes sense. The original intent was simply to make the 'Primary links' block domain-sensitive. In that respect, the title is always 'Primary Links' because that is the semantic name of what the block is displaying.
The question is, do we want the semantic name or the human-readable menu name? Probably the latter, as you suggest, because people could just override the block title if they want to use the same name for all instances of this block.
Comment #30
bartezz commentedI think we should send the human-readable name to use as the block-subject, this is what one expects to happen I suppose (at least i did :) )
The override option is a perfect solution for people who want to show all menus for all domains with the same title (within the theme as this block config is theme specific).
Sorry to be so time consuming :)
Cheers
Comment #31
agentrickardNot a problem.
Comment #32
agentrickardOf course, this opens up a new problem, since the 'Navigation' menu is supposed to use the user name as the title, and this approach doesn't solve that.
Comment #33
bartezz commentedAh, I'll rewrite the patch to bypass if the machine-readable name of the menu is 'navigation'.
Cool?
Cheers
Comment #34
agentrickardNot sure that's the best way. You might have to dynamically load the "real" block title. Hardcoding a work-around is never a good idea.
Comment #35
bartezz commentedCould you please point me in the right direction to dynamically load this?
Cheers
Comment #36
bartezz commentedWas this the case without my patch then? Just wondering...
Cheers
Comment #37
agentrickardWithout your patch, we used 'Primary Links', which is a static string that the user can edit.
Comment #38
bartezz commentedHi,
In regards to #32; I'm using my patch right now and the username is actually being used as the title of the navigation-menu-block?
In regards to #37; Would this be a solution
$data['subject'] = t(check_plain($menus[$delta]));Am trying to finish the website to meet the deadline.
With your feedback I'll rewrite my patch and post it a bit later, ok?
Cheers
Comment #39
agentrickardI'll have to double-check, but I would swear it used 'Navigation' as the block title when I tried it.
t() is redundant here. check_plain() is enough.
Comment #40
bartezz commentedHi,
Ok... Will wait for your reply.
Cheers
Comment #41
agentrickardSince no one else weighed in, I'm going to leave this unchanged.