CVS edit link for barrya

I will mostly be looking to share some of the modules I have written that I feel may be of benefit to the drupal community.

The first module I would like to share is called webform_userpoints. It integrate the userpoints system with the webform module and allows individual webform submissions to award points to the submitter. With the upgrade of Webform to v3, the ability to include PHP code within the form submit process was removed and placed into a seperate module (webform_php). Whilst the functionality of the module I have created can be replicated using webform_php, it is not recommended to use this method as it opens up security issues - such as allowing php code to be run from a textfield - something the author is strongly against.

The webform_userpoints module simply adds an admin item to the webform config page allowing the webmaster to manage userpoint allocations without the need to include php code or install modules that may increase the security risk.

Comments

barrya’s picture

Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new9.68 KB

Initial build of the module webform_userpoints

avpaderno’s picture

Issue tags: +Module review

Hello, and thanks for applying for a CVS account. I am adding the review tags, and some volunteers will review the code, pointing out what it needs to be changed.

barrya’s picture

StatusFileSize
new9.67 KB

Ignore the previous upload, I misnamed some of the function names in the .install file. Serves me right for using webform_php as my reference.

pcambra’s picture

Hi barrya!

Thanks for submitting the module, I think it could be very useful, here is what I found reviewing the code:

  • Please remove License.txt file, Drupal has its own licence that modules can't override.
  • In the install file you are adding files to the webform table, are you sure that this is the way to go? I would say that managing this in a sepparate table would fit better.
  • You've missed the headers of the files for CVS management in drupal ($Id), please take a look to this handbook page: http://drupal.org/node/546
  • Make sure you pass your code through coder module to avoid little formatting issues and coding standards http://drupal.org/project/coder
  • I think that you could do a general userpoint settings for all webforms in addition of configuring it for each webform node, what do you think?
pcambra’s picture

Status: Needs review » Needs work
Issue tags: -Module review
pcambra’s picture

Issue tags: +userpoints, +webform, +Module review
barrya’s picture

Status: Needs work » Needs review
StatusFileSize
new2.85 KB

Updated the module.

Cleaned the code as requested, added cvs headers, removed license.txt.

I have left the .install file adding fields rather than creating a new table for the moment. This is mainly due to another webform module I spotted that did this and I wanted to maintain consistency. My usual thought would be to seperate this into a seperate table - so this isn't a problem.

As for a universal webform settings page, what do you have in mind for this? Would this allow default settings that would prepopulate new webforms?

Scyther’s picture

Status: Needs review » Needs work

You should have a seperate DB table for your module and have a "connection" between your table and the 'webform' table.

And then clean up the webform_userpoints_configure_form_submit() and use drupal_write_record instead.

pcambra’s picture

Status: Needs work » Needs review

I don't think that those two issues are compulsory for getting the module commited, only a "nice to have", maybe opened as issues when the project is created

svendecabooter’s picture

There is still a normal warning and a few minor ones when running the module through coder.module, and the schema_alter could indeed be avoided, but apart from that this looks ready to go

pcambra’s picture

Status: Needs review » Needs work

What do you say barrya? do you think that using a sepparate table for the module data could be done prior to commiting the version to CVS?

avpaderno’s picture

Issue tags: -userpoints, -webform

http://drupal.org/node/539608 reports what is considered an application blocker.
Having a separate database table is not one of them, but the module should implement hook_schema_alter().

When a module alters a database table defined from another module, it should also implement hook_schema_alter(), in order to allow the other module to correctly work.

barrya’s picture

@svendecabooter - Which lines are still reporting an error. i still see an error on line 88, but i've ignored that for what I hope are obvious reasons. Other than this I am not seeing any errors with the latest coder beta.

barrya’s picture

Status: Needs work » Needs review

@pcambra

as @kiamlaluno states, amending an existing table is acceptable as long as hook_schema_alter() is implemented. As it is I am going to leave this as it stands for the moment. It should not stop the module from being released in its current form. Thinking about it, having this information in a seperate table may cause more problems than it is worth as there will be additional overhead from the additional join that would be needed by this module.

I'm still open to discuss the merits for moving this to a seperate table, as I said this was going to be my original route, but should be raised as in issue once the module is published.

pcambra’s picture

Status: Needs review » Needs work

barrya, ok then I think hook_schema_alter belongs to module file and not to install one? https://drupal.org/node/51220, note that you have documented it as hook_schema and not hook_schema_alter.

juankvillegas’s picture

I guess that if the schema modification is done just one time, like in this case, it must be in example.install

But if you modify database tables dinamically, like CCK, it would be in example.module

pcambra’s picture

Thanks juankvillegas, do you know if this is documented somewhere?
In that case, hook_schema_alter should be documented properly and we'll ready to go :)

avpaderno’s picture

drupal_alter('schema', $schema) is normally called inside drupal_get_schema(), after module_load_all_includes('install').

The hooks that should go in the installation file are hook_enable(), hook_disable(), hook_install(), hook_schema(), hook_uninstall(), and hook_requirements(); other hooks should go in the module file.

barrya’s picture

StatusFileSize
new8.25 KB

According to Pro Druapl Development By John K. VanDyk

the .install file should include hook_schema_alter(). Page 105-106.

I have also seen it used this way elsewhere. It makes more logical sense for it to be here than anywhere else.

I have attached a new version of the module with the function documented correctly.

barrya’s picture

Status: Needs work » Needs review
pcambra’s picture

This is very curious, but I can't find any docs that refer on where to call the hook_schema_alter function, it would make sense to call it in the install file, but is not included in the "usual install file functions set", also would be the only alter function called in this file, bear in mind that alter functions are invoked by drupal_alter function.
It would be great to clarify and document this for the future

avpaderno’s picture

Status: Needs review » Fixed

Thank you for your contribution! I am going to update your account.

These are some recommended readings to help with excellent maintainership:

You can find more contributors chatting on the IRC #drupal-contribute channel. So, come hang out and stay involved.
Thank you, also, for your patience with the review process.
Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

I thank all the dedicated reviewers as well.

avpaderno’s picture

Assigned: Unassigned » avpaderno

Status: Fixed » Closed (fixed)
Issue tags: -Module review

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

avpaderno’s picture

Component: Miscellaneous » new project application
Issue summary: View changes
Status: Closed (fixed) » Fixed

Status: Fixed » Closed (fixed)

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