Domain Primary Links block has wrong title
| Project: | Domain Access |
| Version: | 6.x-2.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
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
#1
Sounds like a bug.
#2
Cannot 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.
#3
Hiya,
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;
<?php if($column_left): ?><?php print $column_left ?>
<?php endif; ?>
In admin/build/domain/conf/1 I have the settings (see image).
Not sure what else I should set.
My domain_conf.module says
* @param $domain_idThe 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;
function domain_conf_block($op = 'list', $delta = 0, $edit = array()) {watchdog('action', 'delta test');
watchdog('action', $delta);
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 :)
#4
I am using HEAD, and there are some new lines.
See line 503ff in rc9.
<?php$delta = variable_get($source, $string);
// Some domains can disable primary and secondary links.
if (empty($delta)) {
return;
}
?>
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.
#5
[ignore this]
#6
Will have to check tomorrow can't get to it from here, thanx!!
#7
Hi,
Well I delta'd function domain_conf_block as such;
#503
$delta = variable_get($source, $string);watchdog('action', 'test-delta-test');
watchdog('action', $delta);
// Some domains can disable primary and secondary links.
if (empty($delta)) {
return;
}
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
#8
Hmm 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;
array(15) {["site_mail"]=>
string(20) "mail@isp.domain"
["site_slogan"]=>
string(36) "This will be the slogan"
["site_mission"]=>
string(0) ""
["site_footer"]=>
string(0) ""
["site_frontpage"]=>
string(6) "node/3"
["anonymous"]=>
string(7) "Anoniem"
["site_name"]=>
string(0) ""
["admin_theme"]=>
string(10) "contentual"
["date_default_timezone"]=>
string(0) ""
["site_offline"]=>
string(1) "0"
["site_offline_message"]=>
string(149) "De site is momenteel niet beschikbaar wegens onderhoud. De site zou binnenkort weer beschikbaar moeten zijn. Bedankt voor uw geduld."
["language_default"]=>
string(0) ""
["menu_default_node_menu"]=>
string(13) "primary-links"
["menu_primary_links_source"]=>
string(1) "0"
["menu_secondary_links_source"]=>
string(1) "0"
}
Hope this helps in defining the problem...
Cheers
#9
What I don't understand is that in domain_conf.module in function domain_conf_block there is a variable_get that does the following;
$delta = variable_get($source, $string);//translates into $delta = variable_get('menu_primary_links_source', 'primary-links')
This looks up the variables in {variable} and not the domain specific variables stored in {domain_conf} or am I mistaken?
Cheers
#10
Been 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!
#11
Fixed the PS too... here's the patch.
Cheers
#12
You 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:
<?phpglobal $conf;
watchdog($conf[$source]);
$delta = variable_get($source, $string);
?>
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().
<?php$data = array();
$data = db_fetch_array(db_query("SELECT settings FROM {domain_conf} WHERE domain_id = %d", $domain['domain_id']));
if (!empty($data)) {
// ....
$conf[$key] = $value;
}
?>
Since the value is 0, !empty is FALSE. But that doesn't explain why its working correctly for me.
#13
But that isn't the problem, either. Here's the debug I get for a domain set to 'do not use primary links'.
<?phpprint '<pre>';
print_r($conf);
print '</pre>';
?>
Array
(
[domain_bootstrap_modules] => Array
(
[0] => domain_alias
[1] => domain_conf
[2] => domain_prefix
)
[site_mail] => 614@example.com
[site_slogan] =>
[site_mission] =>
[site_footer] =>
[site_frontpage] => node
[anonymous] => Anonymous
[site_name] =>
[admin_theme] => 0
[date_default_timezone] =>
[cache] => 0
[cache_lifetime] => 0
[page_compression] => 1
[site_offline] => 0
[site_offline_message] => Drupal 6.14 is currently under maintenance. We should be back shortly. Thank you for your patience.
[menu_default_node_menu] =>
[menu_primary_links_source] => 0
[menu_secondary_links_source] => 0
)
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.
#14
The domain_bootstrap_modules in {table} is a serialized array containing this
array(3) {[0]=>
string(12) "domain_alias"
[1]=>
string(11) "domain_conf"
[2]=>
string(13) "domain_prefix"
}
When i do this in domain_conf.module/domain_conf_block()
<?phpglobal $conf;
print '<pre>';
print_r($conf);
print '</pre>';
?>
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!
#15
Right, 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
#16
They 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
#17
Ah-hah. You are having an execution problem.
Is your settings.php configured correctly? Are you seeing any error messages?
#18
Disabling and uninstalling modules didn't do anything.
No error messages so I'll check the settings.php, maybe my changes got overwritten?
Cheers
#19
Hmmz, I had this;
/*** Add the domain module setup routine.
*/
include './sites/all/modules/domain/settings.inc';
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...
:'(
#20
Why do you have two settings folders? That may be your problem.
#21
It'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
#22
I 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.
#23
Just put an IF conditional in default/settings.php to load the proper db based on server env.
#24
Can'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
#25
Forgot to close
#26
Hi 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;
$menus = menu_get_menus();$string = str_replace('domain-', '', $delta);
$source = 'menu_'. str_replace('-', '_', $string) .'_source';
$delta = variable_get($source, $string);
// Some domains can disable primary and secondary links.
if (empty($delta)) {
return;
}
$data['subject'] = check_plain($menus[$string]);
$data['content'] = menu_tree($delta);
return $data;
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;
echo $string."+++";echo $delta."+++";
var_dump($menus);
$data['subject'] = check_plain($menus[$string]);
$data['content'] = menu_tree($delta);
Which results in:
primary-links+++primarymenu--3+++array(5) {["menu-primarymenu--3"]=>
string(11) "Algemeen--3"
["menu-secondarymenu--3"]=>
string(17) "Huisartsenzorg--3"
["secondary-links"]=>
string(13) "Hulpverleners"
["navigation"]=>
string(9) "Navigatie"
["primary-links"]=>
string(8) "Over ons"
}
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
#27
Yes, 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.
#28
Hi,
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
#29
That 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.
#30
I 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
#31
Not a problem.
#32
Of 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.
#33
Ah, I'll rewrite the patch to bypass if the machine-readable name of the menu is 'navigation'.
Cool?
Cheers
#34
Not 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.
#35
Could you please point me in the right direction to dynamically load this?
Cheers
#36
Was this the case without my patch then? Just wondering...
Cheers
#37
Without your patch, we used 'Primary Links', which is a static string that the user can edit.
#38
Hi,
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
#39
I'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.
#40
Hi,
Ok... Will wait for your reply.
Cheers