Forking is generally frowned upon: updates to Webform won't be applied to your module automatically, it confuses potential users, and goes against the spirit of collaborative open-source projects. Check out the handbook pages on Joining Forces With Others and the CVS Usage policy.

Rather than forking the entire Webform module, could the bits you need be abstracted and provided as a module that depends on Webform? Consider modules like Webform Block and Webform Validate.

Comments

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

subscribe.

sreynen’s picture

sreynen commented

For context, this looks to have come out of #428982: New hooks for additional token replacements. This still seems like a bad idea with that context.

fizk’s picture

fizk commented

amorfati,

I waited a long time before doing this, because I know all the points that you raised.

I forked because the current maintainer of webform isn't enthusiastic about seeing token support in webform 6x any time soon, mainly for performance reasons.

I promise that, as soon as webform has token support, this module will be deleted, assuming that it hasn't grown beyond a few simple patches by that time.

...could the bits you need be abstracted and provided as a module that depends on Webform?

That's an excellent idea, but again, you'll have to convince the current webform maintainer that it's worthwhile for him to add a new hook into webform that, at this point, only people using token module would use.

I have doubts he'd be interested in doing that because he said there should only be one token system being used in webform.

Anyway, this module is for all the non-programmers out there that are dying for token support yesterday.

I could easily maintain my own patches, as I already do for a other modules, but I'm sure there are plenty of others that wish they could simply download a working version of webform with token support.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

You could have easily made a project in your CVS sandbox that wouldn't have a public project page but people could still access. I don't think it was appropriate to create the fork. Your patches also tried to lump in a bunch of other module tokens when those should be issues for token.module, not webform, so there was never a chance the current patches would be accepted.

sreynen’s picture

sreynen commented

That's an excellent idea, but again, you'll have to convince the current webform maintainer that it's worthwhile for him to add a new hook into webform that, at this point, only people using token module would use.

I don't believe a new hook is needed at all. The function you patched, _webform_filter_values, is only called within Form API functions, so you could apply token in the same places with only form_alter.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

I think this could be implemented completely as form_alters. That's the proper way to do something like this rather than make a whole copy of the code.

What is the problem? The problem is that now people will be confused as to which module is the best to use - this one or the main one - and it creates duplicate work. Now you have to apply every webform patch also to this module or else your users will fall behind. Are you ready to do that?

fizk’s picture

fizk commented

Dave,

I replied here.

sreynen, greggles,

I looked at the code and didn't see how it could be done, but if either of you could create a working patch, that would be fantastic.

sreynen’s picture

sreynen commented

fizk, the form_alter approach would be a single-purpose add-on module, not a patch to Webform (nor your fork of Webform). Someone who actually wants to use token support in Webform (e.g. you) should write the code, so they'll be around to maintain it.

I'd be happy to help with specific questions, but "didn't see how it could be done" is pretty vague. What exactly are you unsure about? Are you unfamiliar with hook_form_alter?

mark trapp’s picture

mark trapp
he/him
Primary language English
commented

Notwithstanding all the excellent points others have made here, on the project page, you said:

I promise that, as soon as webform has token support, this module will be deleted[...]

I have doubts he'd be interested in doing that because he said there should only be one token system being used in webform.

Anyway, this module is for all the non-programmers out there that are dying for token support yesterday.

I could easily maintain my own patches, as I already do for a other modules, but I'm sure there are plenty of others that wish they could simply download a working version of webform with token support.

But at the same time, you say here:

[...] assuming that it hasn't grown beyond a few simple patches by that time.

and on the project page:

Developers

If you have any patches waiting in the webform issue queue that may not be accepted for a long time, or not at all,
please send us your patch and we'll try to add it to this module.

I could easily maintain my own patches, as I already do for a other modules, but I'm sure there are plenty of others that wish they could simply download a working version of webform with token support

The last part is disingenuous. Webform does work for thousands of people, and as you already said, it includes its own token support: it's just not done in the way you wanted it implemented. Based on this and the other things you said, it doesn't seem like this is just about adding Token support for Webform, but a concerted effort to fork the project itself.

But if you are sincerely interested in providing Token support to Webform in a module, you should take a look at one of my modules, Date Popup Authored, which is a module that extends another via hook_form_alter.

fizk’s picture

fizk commented

sreynen,

fizk, the form_alter approach would be a single-purpose add-on module...

Yes, that's what I meant.

Someone who actually wants to use token support in Webform (e.g. you) should write the code, so they'll be around to maintain it.

If someone submits code that can do this via form alter, great. Don't try to force or coerce me to do it, because it seems like "it's either you right a form alter or webform patched will be deleted."

mark trapp’s picture

mark trapp
he/him
Primary language English
commented

I don't think anyone is trying to force or coerce you to do anything, fizk. I think we're interested in understanding why one of the most drastic steps you can take in an open-source project, a fork, was taken when there are reasonable alternatives available. If you're not interested in collaborating with the rest of the community, why host your fork on Drupal.org at all?

fizk’s picture

fizk commented

amorfati,

The last part is disingenuous.

If it's grown beyond a few simple patches because other developers have submitted patches to me that aren't accepted into webform and people want those added features today, then I probably shouldn't just delete this module if/when token support is included in webform.

...it's just not done in the way you wanted it implemented.

No, webform does not support the token module at all. This is about adding support for token module.

Based on this and the other things you said, it doesn't seem like this is just about adding Token support for Webform, but a concerted effort to fork the project itself.

No, please see above.

...you should take a look at one of my modules, Date Popup Authored...

I'll check it out, thanks.

fizk’s picture

fizk commented

amorfati,

If I wasn't interested in collaborating with the open source community, I wouldn't be answering any questions here, I wouldn't have submitted the patch to webform, I wouldn't have discussed the patch with the webform maintainer, I wouldn't have waited so long until finally creating this project, and I wouldn't be typing this sentence that is really too long.

mark trapp’s picture

mark trapp
he/him
Primary language English
commented

You say this is just about adding Token module support, but you've made several statements here and on the project page that imply the current maintainer of Webform is either not using correct judgement in determining what gets into the module or is being too slow to add features. That's the rationale behind the kind of fork that is harmful to an open-source project.

If you merely want to get Token module support into Webform, that's fine: I think we've provided enough information to get you started in creating a module that does just that without forking the Webform project.

But if you want to fork the project because you don't like how the maintainer handles the project, that's a different discussion, and isn't something that I think the Drupal community wants to see in general. There are resources available that can help you through disputes like that in the handbook. Check out How to be a Good Maintainer and Tips for contributing.

These are two separate issues: please don't try to get one in under the pretenses of the other.

fizk’s picture

fizk commented

amorfati,

I understand what you mean now. I'll remove the part about accepting other patches.

I'm still leaving this module as is until someone, possibly me, creates a method that uses form alter.

OK, I think this is all that I can say on this issue.

fizk’s picture

fizk commented
Status: Active » Closed (fixed)

If anyone would like to submit code that uses form alter, please create a new issue.

Marko B’s picture

Marko B commented

fizk, i liked that you made this module. sometimes drupalers are overcomplicating things, if this is a working solution why not share it and then when there is time just build better. And seems that it is now 2012 and still there is no better solution so good call. :-) Webform is **** without tokens and if you want to build something good with WF you need them.