Closed (fixed)
Project:
Webform
Version:
7.x-4.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
10 Aug 2013 at 14:34 UTC
Updated:
11 Sep 2013 at 20:21 UTC
Jump to comment: Most recent file
Now webform_node_types store all enabled content type in a single array, so difficult to use features to manage it per individual content type.
Similar as diff_form_node_type_form_alter, we can move the enabled content type from admin/config/content/webform to admin/structure/types/manage/*, so replace webform_node_types as webform_node_* per content type.
P.S. Related patch files for other projects:
All similar 3rd party modules patch with same idea as this issue:
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | webform_node_types-2062235.patch | 19.61 KB | quicksketch |
| #10 | webform_node_types-2062235.patch | 17.61 KB | quicksketch |
| #9 | webform_node_types-2062235.patch | 17.63 KB | quicksketch |
| #6 | webform-node_types-2062235-6.patch | 18.09 KB | hswong3i |
| #5 | webform-node_types-2062235-5.patch | 18.15 KB | hswong3i |
Comments
Comment #1
hswong3i commentedComment #2
quicksketchHi @hswong3i, thanks for the patch!
I think splitting up the variable into separate ones is a good idea. It makes it easier to manage via features this way. However, I'm on the fence about putting the Webform-enabled setting on the individual content type forms, as I mentioned in this very similar issue: #1963870: Expose Webform settings in content type form .
Instead of having two issues for the same thing, could you review that patch and merge in your different changes (if any) into it?
Comment #3
hswong3i commentedUpdate since #1:
P.S. I don't think we should merge all progress from #1963870: Expose Webform settings in content type form because that issue suggest a duplication of enable/disable webform per content type on multiple pages, which may confluse end user.
Comment #4
berliner commented@hswong3i: Your second patch file contains distinct consecutive diffs. That makes it unnecessary difficult to follow the changes.
Comment #5
hswong3i commentedAs per requested, detail commit history goes to https://github.com/pantarei/drupal-webform/tree/7.x-4.x-2062235 ;-)
Comment #6
hswong3i commentedChangeset goes to https://github.com/pantarei/drupal-webform/commit/5a6954d43b5de5e05c5a87..., include:
Up to this point I have already consolidate all similar 3rd party modules patch with same idea into this issue:
Final patch attached already applied to DruStack for more than a week, and perfectly handle my initial request on this issue with numbers of client's project:
Please feel free to improve this issue according to overall project design concern (which always a weakness for a contributor besides original author), and it is my pleasure to remove the manual patch within distribution once changes goes into mainstream. Thank you very much and looking for any good news ;-)
Comment #7
barrapontoI generally agree with the ideas presented on this issue, I'll review the patch as soon as I can (no sooner).
Comment #8
quicksketchWhile testing this out I found a significant flaw in the update hook:
This will always produce a non-sensical array that uses the numeric keys as the values. i.e.
array(0, 1, 2). I think it should just be:Comment #9
quicksketchThis patch updates the update hook and makes the Vertical Tabs integration a little more explicit. It now says "Disabled" if the checkbox for enabling Webform isn't enabled.
Comment #10
quicksketchOne more change. I made webform_node_types() return an unkeyed array, rather than keying by content type. That makes it consistent with the previous variable by the same name. $key => $key arrays always seem unnecessary to me.
Comment #11
hswong3i commented@quicksketch: seems missed out the js/node-type-form.js from #10?
Comment #12
quicksketchAh, yes most likely. I made some changes to that file too. I'll reroll tomorrow.
Comment #12.0
quicksketchAdd related project patch links
Comment #13
quicksketchI'll reroll tomorrow.Well I'll reroll it soon at least. :P
Comment #14
quicksketchHere's the patch with the node-type-form.js file included.
Comment #15
quicksketchWell, even though I'm not particularly a fan of this approach, an informal survey of my peers resulted in everyone thinking it made sense to move the settings. I can't find any problems with the patch and everything works for me, so I've committed it to the 7.x-4.x branch.
Comment #16.0
(not verified) commentedAdd more reference links