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:

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 .

CommentFileSizeAuthor
#13 webform_component_api3.patch70.46 KBquicksketch
#11 webform_2.7_extended_components.patch_rehunk.txt2.43 KBjp.stacey
#10 webform_2.7_extended_components.patch2.19 KBbart.vandendriessche
webform_extended_components.patch.txt2.43 KBjp.stacey
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

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.

jp.stacey’s picture

jp.stacey CreditAttribution: jp.stacey commented

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.

Chris Charlton’s picture

Chris Charlton
Primary language English
Location Los Angeles
CreditAttribution: Chris Charlton commented

Commit it! :D

Chris Charlton’s picture

Chris Charlton
Primary language English
Location Los Angeles
CreditAttribution: Chris Charlton commented

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.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Status: Needs review » Needs work

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.

ngmaloney’s picture

ngmaloney CreditAttribution: ngmaloney commented

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!

pan0s’s picture

pan0s CreditAttribution: pan0s commented

Is the supplied patch above supposed to work with 2.6 version?i cant seem to apply the patch ...

jp.stacey’s picture

jp.stacey CreditAttribution: jp.stacey commented

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

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

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.

bart.vandendriessche’s picture

bart.vandendriessche CreditAttribution: bart.vandendriessche commented
FileSize
webform_2.7_extended_components.patch2.19 KB

If anyone still cares, I manually applied these changes to the 2.7 version and created a new patch.

jp.stacey’s picture

jp.stacey CreditAttribution: jp.stacey commented
FileSize
webform_2.7_extended_components.patch_rehunk.txt2.43 KB

@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.

omerida’s picture

omerida CreditAttribution: omerida commented

The patch in #10 applied for me, but #11 failed.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Version: 5.x-2.3 »
Status: Needs work » Fixed
FileSize
webform_component_api3.patch70.46 KB

Well this never happened due to a lack of a patch that worked in both D5 and D6. Development on 2.x has stopped, so it's unlikely this will happen in the 2.x version. I've extensively reworked the component system so that it is pluggable in this new approach for 3.x. It also cleans up a few function names and changes our definitions.

Summary of changes:

  • New hook_webform_component_info() allows any module to define components
  • This hook now translates component names and provides descriptions (removing the need for _webform_help_component()).
  • Renamed _webform_analysis_rows_component to _webform_analysis_component
  • Renamed _webform_table_data_component to _webform_table_component
  • Moved all documentation to a dedicated webform_hooks.php file
  • All Webform hooks now provide return values instead of passing things by reference
  • Since we had to rework the admin configuration for enabling/disabling components, I moved all admin settings to webform.admin.inc for efficiency.
  • All Webform component callbacks are now run through webform_component_invoke(), providing a central place we can add new hooks if desired.

Overall the whole system is much more efficient, since we only load component.inc files as needed instead of blinding loading all components when we only need one of them. Our APIs are still fluid in the 3.x version and I expect a few more changes here and there. Specifically we'll probably change the way that e-mails are done, since we can re-use the e-mail formatting for #181077: Printable page for webform submissions also.

I've committed this patch to help continue the improvements to the 3.x version.

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Title: Extending webform components with hook_load_webform_components » Provide hook_webform_component_info() to allow 3rd-party components

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jp.stacey’s picture

jp.stacey CreditAttribution: jp.stacey commented
Version: » 6.x-3.0-beta6

@quicksketch - I took my eye off this once it closed, as we'd moved onto different work that didn't involve heavy webform use, so I never got back to you on this to thank you.

I'm currently converting our hacked 2.x webform to 3.x-beta6 in preparation for an upcoming new site, and with a few tweaks the 3.x API is all working brilliantly. In fact, it all makes a lot more sense than when I was just hacking out existing *.inc files and gutting them. While I appreciate it's all still a beta, it's nonetheless currently doing exactly what we want it to with our legacy collection of custom fields.

Thanks again!