Different Info per category (Possible Solution)
sovietfunk - July 9, 2007 - 14:32
| Project: | Contact Forms |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
Description
For this module to be truly useful (and user friendly), I think you should add the possibility to customize the "Additional Information" headings per category.
As it is, this heading must be formulated in general (for all categories), while the form itself is specified (only one category).
Also, shouldn't the text at the top of the "contact list" ('Who would you like to contact?') be editable in settings, not "hard" coded in the module?
#1
Sorry, perhaps I was a bit quick to post this. After some more thought, I decided that the best way for me to deal with this is to remove all text from the "Additional Information" field, and create content-top blocks for each category. This way I can also bypass any issues with internationalizing the information. But I'll leave it to someone else to close the issue, just in case the feature I requested is interesting to others.
And I still think that the line 'Who would you like to contact?' should be editable. (Yes, I can change it in the code, but a too-swift module update could delete my changes.)
#2
Thanks for your thoughts.
I agree that it would be good to have editable information for each category. The reason I didn't go that far was because it would mean having an extra database table and making my module more complex than I thought was necessary. Now you have got me thinking that I could have a two level feature system where you could have different info for each category but if you left it blank then you would get the standard info.
Maybe a rewrite is in order soon.
One of the reasons I didn't make 'Who would you like to contact?' editable was I was getting too many editable fields on the settings page and thought it was getting confusing.....and that line can be changed with the Localisation module.
Regards
gpdinoz
#3
I was also thinking that this feature would be useful, but as the original poster pointed out, it can be achieved with a block. That's a good solution IMHO, as it allows for anything to be posted as the header text. Plus it keeps this module small and quick - just the way we like our modules :)
Thanks for a great module.
#4
This has been transfered from Contact List
#5
Hi,
Possibly there's newer posts relating to this, but this one describes exactly what I was needing, I had a good search and can't find many postings that talk about this, or any solutions, just a lot of talk about cck etc.
I only have two or three contact forms, eg Press and Bookings, that just need to be the simple default ones you get with Drupal as standard that unsigned-in visitors can use to email various people. I have the Contact Form module which gives me for my categories site.com/contact/bookings and site.com/contact/press, brilliant! Really easy to set up, thank you, just what I need on most sites.
It would be really useful to be able to put "To make a booking blah blah" at the top of the bookings page *under* the title Bookings. I just created a block, put it in 'Content Top' and set to display only on the page contact/bookings and the text appears above the title. I could hide that title with css and put in a block title, unless theres another way I don't know about, but its a bit of trickery that feels unnecessary?
A text box on the contact settings page for each category where I can put in custom contact info would be quick, simple and easy :)
#6
OK, ignore what I said about the title - just noticed the Contact Form Title field in the settings, so will jut have this blank and put in the block title, but would still prefer the info text to be here and not have to create a block for every contact form.
#7
nope, it requires a title!
#8
Hi Neil,
I agree that being able to add extra info per contact form would be ideal however it would require a lot more programming and an extra table in the database and I don't have the time to do it.
If I only have a few contact forms I use the webform module. It does everything you want.
Regards
Geoff
#9
I actually did this on my own to this module without adding any DB tables just using the variable_set/get functions (the idea of which I got from the Menu Block). All that's needed are a few extra lines of code. I'll post a patch later but for now here is the relevant code that I added
<?php
function contact_forms_form_alter(&$form, $form_state, $form_id) {
//code...
// Alter all contact forms except for /contact
if ($form_id == 'contact_mail_page' && $path != 'contact') {
//more code....
//changed the #value attribute to get the category specific info and if that's not present the default category message
$form['contact_information'] = array(
'#type' => 'markup',
'#value' => t(variable_get("contactform_{$categories_data['cid']}_info",variable_get('contactforms_information' , 'You can send !category a message using the contact form below.')) , array('!category' => $categories_data['category'])),
);
//some more code....
}
//Alter the contact Category add/edit Forms
if($form_id == 'contact_admin_edit'){
$cid = $form['cid']['#value'];
$form['contactforms_cat_information'] = array(
'#type' => 'textarea',
'#title' => t('Category Page Information'),
'#weight' => 0,
'#default_value' => variable_get("contactform_{$cid}_info", ''),
'#description' => t('Information to show on the individual contact page.'),
);
$form['category']['#weight']='-1';
$form['#submit'][] = 'contact_forms_admin_edit_form_submit';
}
//the rest of hook_form_alter
}
// the submit function for the Category add/edit form added on to the end of the module
function contact_forms_admin_edit_form_submit($form, &$form_state){
$cid = $form_state['values']['cid'];
variable_set("contactform_{$cid}_info", $form_state['values']['contactforms_cat_information']);
}
?>
That's it. Those couple lines of code will create the ability to category specific info. Now in practice you should also implement hook_uninstall(inside a contact_forms.install file) to remove the variables from the DB if this module is uninstalled but that would be fairly easy also
<?phpfunction contact_forms_uninstall() {
$sql = 'SELECT cid FROM {contact}';
$result = db_query($sql);
while($contact = db_fetch_object($result)){
variable_del("contactform_{$contact->cid}_info");
}
}
?>
Anyway I can throw a patch up for this if you want or you can just grab the code for this straight out of here.
#10
Also I have actually tested and used the above on a site, without any problems so far. I can't see any issues that might arise either.
#11
Looks interesting, I'm having a go at it. What version are you using? A patch would be great, thanks
#12
I have patched this against HEAD for the maintainers ease in adding it to the code if they wish to do so (I think it would be a great idea). So be warned that that is what this should be used against. I added a patch for the DRUPAL-6--1 branch also, for those of you that want to patch it against that version, although using HEAD is probably the best idea.
A few comments on this patch . I also added a few other improvements that I have made to my version of this module
Changes
#13
Hi arcaneadam,
Thanks for supplying this patch and solution. I know there will be people who will want to use this. It is a clever solution and technically I don't see any problems however I am reticant to add a solution to my module that uses the variable table to store content.
I would like to see a column added to the core contact table to add this feature. That would be the best solution. Second best would be for Contact Forms to have it's own table to store the additional info for each category and maybe over christmass/Jan break I will add it. Until then it is great that your solution is available for anyone who wants to use it. It is clever, simple and shouldn't cause any problems.
Regards
Geoff
#14
Okay, I just went ahead and spent the few minutes to implement it the way you want. Here is what this patch adds:
I hope this is works for you. I think this will really put this module over the top and make it one of the more useful modules.
#15
Thanks arcaneadam, This looks really good. Not only is it a great solution but you have pushed my Drupal knowledge up a notch. I will work on getting this published.
Regards
geoff
#16
Just a thought, but I wouldn't mind being a co-maintainer of this module. I use it pretty often and wouldn't mind working on it with you.
#17
#18
Added to the module.
Again thanks arcaneadam
Regards
Geoff
#19
Sorry we were adding comments at the same time. I didn't see yours.
The problems with porting this to D5 is hook_schema_alter was introduced in D6 so we would have to use some other devious method.
Which brings us back to your original idea.
geoff