Hi, a quick feature request. I am not sure what would be needed to implement this, if it is even possible, with the core contact.module.
Can't seem to get the target email addresses for contact form categories to export as features. There seems to be no strongarm setting for this. Regards.
| Comment | File | Size | Author |
|---|---|---|---|
| #39 | integrate_contact-1198102-39.patch | 3.53 KB | claudiu.cristea |
| #39 | interdiff.txt | 316 bytes | claudiu.cristea |
| #29 | features-integrate_contact_module_categories-1198102-29.patch | 4.24 KB | mohit_aghera |
Comments
Comment #1
hongpong commentedI think this more properly belongs with Strongarm than Features.
Comment #2
Grayside commentedThe Contact form settings are already exported by Strongarm, except for the Category settings which *cannot* be exported by Strongarm. Instead, the Contact module must have db-level features integration. This will need to go in the Features module, in a separate integration module, or be included in the http://drupal.org/project/contact module, though that module is intended for backport code only.
Comment #3
febbraro commentedIf someone wants to work up a patch for integrating Contact into the main Features module, I'll consider it. I have never used Contact though, so I will probably never get around to writing it.
Comment #4
mpotter commentedClosing this for lack of activity. Please re-open this issue if you can reproduce it in the latest version.
Comment #5
boombatower commentedIt's a feature request not a bug so should be reproducible since it doesn't exist, but since no one is implementing it can close.
Comment #6
webastien commentedAttached to this post, a code I've written today for exporting contact categories.
Would be probably better but it works for me.
It would be nice if features' maintainers include it into a next release, after community review.
Comment #7
fureigh commentedHere's a patch that incorporates the above (thanks, webastien, your code was extremely helpful to me today!) and adds another necessary change in features.module.
Comment #8
hefox commentedFile block needed
cid is a numeric key? :/
Assuming cid is a numeric automatically inc column, this won't work out as a site could have a contact category unrelated to that current cid.
Comment #9
fureigh commentedThanks, hefox.
Also, after further testing it appears that currently, only the first category gets imported.
Comment #10
mohit_aghera commentedFixed the few issues, working now. I can export both the categories now.
Comment #11
mohit_aghera commentedFew changes in the category display. Added category display name instead of category id
Comment #12
kristiaanvandeneyndeEdit: whoops, posted in wrong issue somehow.
Comment #13
ohthehugemanatee commentedNoting that the patch in #11 worked well for me.
Comment #14
jstollerSetting to Needs Review, to trigger testbot.
Comment #15
hefox commentedReuploaded patch to see if testbot responds o.O
Comment #16
hefox commentedNeeds to be against 2.x
Comment #17
hefox commentedTry 3
Comment #18
nevergoneI'm tested #17 and Features 7.x-2.0 and works well! Thanks!
Comment #19
hefox commentedcid is still being used -- that won't work for sites with existing but different categories, no?
Comment #20
mohit_aghera commented@hefox: thanks for pointing out the issue.
Now checking the last insert id and then inserting exported contact category. So there won't be any issue of duplication categoryid.
Let's test it again :)
Comment #21
mohit_aghera commentedComment #22
jstollerI just upgraded my site and applied the patch from #20. When doing a forced revert of a feature module containing contacts, I get the following error:
It seems like features is trying to add all the contact categories as new categories, even though they're already in the database, so it's getting an error because "Website feedback" already exists.
Comment #23
jstollerIt seems like you first need to check for an existing category with the same name as the one being reverted. If it exists, then update that cid and, if not, then add a new cid.
Comment #24
subhojit777Patch in #20 is working in normal installation (I mean normal Drupal site without upgrade).
Comment #25
mohit_aghera commentedUpdated patch and removing cid in export to avoid un-necessary issues.
Comment #26
edutrul commentedSorry the patch #25 is not working for me
Comment #27
mohit_aghera commented@edutrul
Can you please tell me which features module version you are using.
I tested with 7.x-2.x-dev branch and Drupal 7.34, seems working fine for me.
Update - working fine with 7.x-2.2 and Drupal 7.34 as well.
Comment #28
hefox commentedSome coding style/spacing issues.
db_* should likely be a bit more spaces, like the db_merges are all on one line and there's a db_select in a foreach -- hard to read
one db_select is before if () { } in _revert, but it insdie if cause useless db_select if that if is false
Comment #29
mohit_aghera commentedCode re-factoring as suggested in feedback.
Comment #30
claudiu.cristeaThank you!
Comment #31
mpotter commentedCommitted to f56b50e.
Comment #33
hefox commentedCommit was missing the inclusion of the new file :(
Anyhow, spotted at least one basic code style issues with the patch, (an if(, aka missing space), should be run through coder to catch any more.
Comment #34
pachabhaiya commented#33 +1
Comment #35
claudiu.cristeaNew patch fixing code standards issues and reading the missed file. RTBC per #30.
Comment #38
claudiu.cristeaOops! Wrong patch.
Comment #39
claudiu.cristeanitpick.
Comment #40
mpotter commentedSorry this took so long. A simple case of forgetting to "git add" the new file. Fixed in 01b103d.
Comment #43
forestmars commentedThanks @mpotter, this was really useful.