Jump to:
| Project: | Contact Forms |
| Version: | 6.x-1.5 |
| Component: | User interface |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
When I create multiple forms in contact_forms then link to them in primary navigation, everything seems to break with where it thinks the form should go. It breaks both the navigation and breadcrumb.
I have a link to /contact/Alamosa_County (it is under a few sub items Community Initiatives->Communities->Alamosa Conty->Contact) in primary_links.
Then I also have a link to the contact form /contact/Bent_County (it is under a few sub items Community Initiatives->Communities->Bent Conty->Contact)
Whenever I click to Alamosa county, it goes to the proper place on the navigation (though it doesn't highlight "Contact" as being the current page) and shows correctly in the breadcrumb. However, when I click on the contact from for Bent County, it shows in the navigation and breadcrumb as Alamosa County.
I am suspecting it is because it is treating /contact/ as the page and Bent_County as a variable, so it sees the first navigation Item in Menus as its proper place in drupal. However, to me, they are different pages. How would one remedy this?
Comments
#1
Hi Aaron,
You are correct in your diagnosis and I am not sure that there is a solution for you. You could try a url alias for each form but I don't think that will work. You may have to get creative and put the contact link to each form somewhere other than the primary links eg in a block (side or footer) that appears on relevant pages. Also have a contacts page with links to each form.
Ideally you want some way of overriding the "What page am I on" mechanism in Drupal. Somehow set which menu item is shown when you are on each contact form. Hmmm...
You might like to try adding a hook_menu to the module that might help drupal sort out the different pages. Something like this (not tested)
function contact_forms_menu() {$items['contact/%'] = array(
'page callback' => 'contact_site_page',
'page arguments' => array(1),
'access arguments' => array('access site-wide contact form'),
'type' => MENU_CALLBACK,
'file' => 'contact.pages.inc',
);
return $items;
}
Let me know how it goes.
Regards
Geoff
#2
This actually works perfectly as a modification to contact.module -- it fails on contact_forms.module because of the file=> attribute is set to something that exists in contact, but not contact forms. So basically adding this inside contact_menu in contact.module fixes it. I wonder if there is an elegant way to actually make this happen inside contact_forms.module?
$items['contact/%'] = array('page callback' => 'contact_site_page',
'page arguments' => array(1),
'access arguments' => array('access site-wide contact form'),
'type' => MENU_CALLBACK,
'file' => 'contact.pages.inc',
);
#3
Hi Aaron,
I think there might be. I had a look in "Pro Drupal Development" Second Edition and on page 79 and you can define paths in the menu system based on args with the hook_to_arg. So try this. Untested again. If this works I will add it to Contact Forms.
I don't know what the file attribute does so lets leave it out. :-o
function contact_forms_menu() {
$items['contact/%contact_form_path'] = array(
'page callback' => 'contact_site_page',
'page arguments' => array(1),
'access arguments' => array('access site-wide contact form'),
'type' => MENU_CALLBACK, // also try MENU_NORMAL_ITEM
);
return $items;
}
function contact_form_path_to_arg($arg){
return $arg ;
}
Regards
Geoff
#4
Geoff,
I think the idea behind this new code is good, but all it does is create blank pages for the contact_form. I think the file attribute is an important one. For contact.module the file attribute points to contact.pages.inc which actually does the brunt of the work. I wonder if we could somehow point 'file' to the contact.pages.inc of the contact module, currently it is looking inside contact_forms.module and not finding it (if I define it as contact.pages.inc inside the contact_forms_menu). Interesting little trickery, but once it is figured out, would definitely be nice to include in the next release.
#5
Hi Aaron,
I have come across all the problems that you have mentioned in the last couple of days. I have one more idea that may (not) work but it will be a few days before I get the time to try it. Will let you know.
Regards
Geoff
#6
See http://drupal.org/node/566222