Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.as promised, the patch for "merging" the feedback modules.
this patch is for the 4.6 version. but porting this code to head wouldn't be that hard i think..
i 've also edited the readme, changelog and the install file.
short summary of changes:
new features:
* flooding prevention
* a optional configurable list of categories, like the new contact module
* multiple feedback pages are easily configureable
stripped features:
e-mail address smtp validation.
this is planned to be reimplemented by using the smtp checker module for 4.7
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | feedback-280506.tar.gz | 7.02 KB | fago |
| feedback-module.patch | 34.31 KB | fago |
Comments
Comment #1
fagoi've updated the rewrite for drupal 4.7. with the update i changed data storage to a database table, so that the $conf-settings aren't used any more.
the extended smtp email validation is still missing, as I'm not aware of the current status of the smtp checker project (deleted?).
i also inclued a simple update for converting the settings to the new database storage. to use it go to your site's update page (http://example.com/update.php) and manually select the update to schema version 1 for
the feedback module.
I've attached the whole module
Comment #2
kbahey commentedHi
Thanks for the patch.
Why store data at all? Isn't that overkill for this?
It is just a contact form
Here is another idea worth exploring:
Why not use the new form API to add custom fields in the contact module?
So, feedback just becomes an admin/settings interface where extra fields are defined, and we validate the extra fields, log to watchdog, and that is it?
This way we get categories for free, no mail relay spam, ....etc.
Comment #3
fagofeedback stores still only its settings. however i changed it to not use variable_get() as all these variables are loaded every time drupal is loaded, and with multiple feedback pages the number of configuration variables is increasing with the number of pages...
why not using the contact.module form? - it's just one feedback page, this module features more..
i thought about the nice feature of the contact.module with auto-reply settings and feedback-email-address configurable for each category.
we could reuse it by listing its categories and letting a user select, which categories from contact.module he/she wants to include in his feedback form - but then we depend on contact.module, which isn't that nice, as contact.module automatically inserts its checkbox through hook_user into the user profile (perhaps I don't want personal user contact pages?)
so imho best would be to just reimplement it..
Comment #4
kbahey commentedCommitted for 4.7 and HEAD.
Thanks
Comment #5
(not verified) commented