Hi guys.

Terrific module - many thanks guys. I had a query that I thought was a bug, and still might be, but thought I would post this in case anyone else has also spent several hours grappling with the same issue.

The query is: Should the Available Menus core functionality be working fine with the glorious Domain Access module/s? Or does the module deliberately purge this ability in favor of the custom override menu options setting at domain/admin/structure/domain -> domain -> settings (e.g. domain/admin/structure/domain/view/2/config)?

If it's the latter shouldn't default Available Menus be greyed out (or the admin message warn that the default menu options need to be configured elsewhere?

At present, when editing the Menu Settings on content type at domain/admin/structure/types/manage/page -> Menu Settings -> Available Menus, we can select an additional menu and hit 'Save Content Type' which generates the standard OK message "The content type Basic page has been updated" - but try and update a node or re-edit the basic page settings (in the usual way) and they always revert to the default 'Main Menu' option even if de-selected and another is chosen instead.

The site build uses core 7.36 (although 7.35 was the same), Omega, Context and all the usual Domain Access modules/submodules but whatever we do after updating the settings, in terms of clear cache, running CRON, rebuilding permissions, etc and the Available Menus always revert to the default 'Main Menu'. We have tried but can't find any issues/blogs or documentation talking about this.

Alternatively, let me know if you need some draft text/copy that could go into the documentation around 'Menus' - although I'm not sure we know enough about the whole module to write it all.

Hope that helps someone else at least.

Thanks.

Q.

Comments

quantos’s picture

Update: Actually, we still have the same problem. What we've got is a continental travel site (South America) as an example with multiple regional (country) domains working under Domain Access. For each regional (country) site we want to assign content to different Where To Go regional landing page. E.G. Where to Go in Chile. At present, with the above Available Menu problem, we can't assign regional content to the regional menu simply because Drupal core's default Menu Settings aren't accepting multiple menu at the Content Type level on the two Domain Access sites. So I presume this must be bug and is not working as intended.

Any ideas what/why could be causing this. Site build as above (essentially D7.36, Omega, Context, Domain Access).

Any help/pointers much appreciated.

Q.

quantos’s picture

Update: I'll try and resolve this if I can ;-)

meantime and after rolling back to earlier install and through more testing I've discovered that:

  1. The problem doesn't exist on new Domain Access builds (with the same Omega, Context, Domain Access build).
  2. i.e. I can edit and save the Available Menus (i.e. checkboxes at admin/structure/types/manage/), but
  3. I haven't added any new domains yet
  4. I'll keep adding back modules until I find the culprit

Watch this space...

Q.

quantos’s picture

Well, damn it, another 3-4 hrs on and I can't reproduce this glitch. Have now been through every module combination used listed below in case handy for anyone or the glitch comes back but key modules/tested include:

1. Drupal core 7.36 + the usual Ctools, Views, etc
2. Content 7.3.6
3. Breakpoints 7.1.2
4. Domain Access 7.3.11
5. Domain Blocks 7.3.11
6. Domain Context 7.3.11
7. Node Export 7.3.0 (but not Node Export Dependency which may have been running earlier)
8. Metatag 7.1.0beta9
9. UUID 7.1.0alpha6

Do please let me know if you have come across the glitch and know what it might be - in case handy for others later - thanks.

Q.

quantos’s picture

Priority: Normal » Minor

Downgraded to Minor priority in the absence of being able to reproduce the damn problem! :-)

quantos’s picture

Priority: Minor » Normal
Issue tags: +domain access

Damn. The problem's back - after nearly two solid days extra work on the site. The only modules added since the time I couldn't reproduce the bug is Taxonomy Manager 7.1.0, Node Export 7.3.0 and the related UUID 7.1.0alpha6 modules + lots of configuration work.

I could still *ideally* do with hearing from anyone else who has seen and preferably killed-off this problem.

I'll separately roll-back and see if either of the above modules are the culprit.

Q.

quantos’s picture

Category: Bug report » Task
Priority: Normal » Minor

SOLVED (kind of).

If someone can point us in the right direction I'll gladly help with writing up some simple extra Documentation notes for this but it seems we can easily fix this problem by following the simple advise below and updating the Menu Settings at

A. admin/structure/domain/view/3/config instead of attempting to update the Content Type directly at
B. admin/structure/types/manage/content-type -> Menu Settings

This is actually the opposite of the Warning text on both pages where A. tells you that "This is your default domain. Use of this form is discouraged. Set these values through the standard interface" and B. says "This form submits changes to your default configuration."

The point is that updating the Menu Settings on the 'standard interface' content type is ignored and you get a confirmation message to the contrary too: "The content type CONTENT-TYPE has been updated" - when it hasn't!

THE SOLUTION, it seems, is to ignore the above warnings and edit the Menu Settings direct using Domain Access's config screens at /admin/structure/domain/view/1/config, etc.

Final caveat, I somehow I suspect that the standard interface should be working but this has been a wild goose chase getting to this point - and I could have swarn I tried updating the Menu Settings (at B.) first without success.

I hope that helps any other fools out there (like me) struggling with the same issue.

PS Thanks to 'the' for the final tip-off at http://stackoverflow.com/questions/7984669/drupal-7-unable-to-update-ava...

Q.

Frosty29’s picture

Thanks Quantos, I had same issue, very helpful to immediately find work around here.