Extending webform components with hook_load_webform_components
jp.stacey - November 28, 2008 - 15:24
| Project: | Webform |
| Version: | 5.x-2.3 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Description
Rather than dropping .inc files into webform/components , with the attached patch you can create a module with its own components subdirectory e.g. mymodule, containing the implementation of the hook_load_webform_components hook:
<?php
function mymodule_load_webform_components() {
return webform_load_webform_components('mymodule');
}
?>The default behaviour is still the same, so it could go into 5.x-2.x .
| Attachment | Size |
|---|---|
| webform_extended_components.patch.txt | 2.43 KB |
#1
Nice! This looks great and I would've done it exactly the same. It's a bit unfortunate this will effectively "lock" the APIs though, but it seems like they're already pretty well cemented with users creating or using custom .inc files anyway. The Webform API has intentionally been closed because it makes it possible to make improvements internally without breaking dependent modules. So I'm fine with this patch, despite it's repercussions. We'll just need to really lock all APIs until a new 3.x version of the module is released.
#2
Glad you like it :) As you say, I think the API has been effectively locked by users anyway, and at least this means that people can stash their component files elsewhere and be able to upgrade webform with minimal fuss. It doesn't in itself make any new promises about the API changing...!
How do we move this code forward, to being included in the 2.x branch? I'm a newbie to the process generally.
#3
Commit it! :D
#4
Since 3.x is proposed to be built with Form Builder in the front, can we lock the api for 2.x and get this rolled into dev? I'm really interested in helping release my nodes & ajax select components.
#5
This patch needs to be rerolled for Drupal 6. It applies fine to Drupal 5. I plan on releasing 2.4 shortly as a bug fixing release. Lastly I want to commit #132279: Pager results page before "officially" locking the API. So we can expect this in 2.5.
#6
Hi All!
This patch is really, really useful. Nice job! Is there a 5.x (dev) release available with it already applied? If not, is there anything I can do to help out?
I developed a module that adds 2 new components that I ALWAYS find myself needing; pre-populated state and country select boxes. It works great but is dependent on the webform_load_webform_components hook. I'll gladly release my module but would like to wait until it isn't dependent on a webforms patch.
Again, thanks to everyone for all their great work on this module!
#7
Is the supplied patch above supposed to work with 2.6 version?i cant seem to apply the patch ...
#8
Hi,
I was hoping to upgrade to 2.6 but it's not clear if my patch above has been applied yet or not. From @pan0s' comment, apparently not.
@quicksketch, has the patch been applied prior to 2.6? I need to upgrade because of a bug in webform_get_submissions (no ordering means
if ($row->sid != $previous)sometimes kills my data)J-P
#9
This patch has not been applied to any version yet, hence why this issue is marked "needs work" and not "fixed". I've stopped supporting Drupal 5 since my last comment, and this will no longer be applied to that version even if it is made ready. All new features are now going into the 3.x branch for Drupal 6 only.
#10
If anyone still cares, I manually applied these changes to the 2.7 version and created a new patch.
#11
@bart.vandendriessche thanks for that. The patch looks like it was exactly the same between versions, but the hunks have moved considerably in line number so patch would fail. I've attached a rewrite myself for 2.7 .
This is a really straightforward change, that people here have tested and want. It's a real shame that it can't at least go into the D5 version of the module so that we don't have to re-patch when security fixes are rolled out.
#12
The patch in #10 applied for me, but #11 failed.