Closed (fixed)
Project:
Drupal.org security advisory coverage applications
Component:
module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
1 May 2012 at 04:01 UTC
Updated:
24 May 2012 at 21:40 UTC
Jump to comment: Most recent file
Comments
Comment #1
traviscarden commentedNote: PAReview gives two warnings:
They refer to
@link ... @endlinkcode, which as I understand should be all on the same line and is permitted to exceed 80 characters.I can't find this fact documented anywhere at present. I'll have it confirmed and then see if I can't get it noted in the standards. Then I'll put in an issue to update the Code Sniffer accordingly.Update: This has been confirmed to be a false positive. See #1559536: False positive/Support @link...@endlink standards.Comment #1.0
traviscarden commentedUpdated issue summary.
Comment #2
patrickd commentedwelcome,
As installation and usage instructions are quite important for us to review, please take a moment to make your project page follow the tips for a great project page.
You can retest your coding standards with http://ventral.org/pareview or even install it on your own computer.
We do really need more hands in the application queue and highly recommend to get a review bonus so we can come back to your application sooner.
regards
Comment #3
traviscarden commentedAdding tag.
Comment #4
scarer commentedI had a look through the code and it looks clean.
I passed the branch through Ventral and there's a couple of lines that exceed 80 characters: http://ventral.org/pareview/httpgitdrupalorgsandboxtraviscarden1552420gi...
I installed the module and looked at the output from the example. The vertical tabs are displaying a bit funny. I tried this in two of the default Drupal 7 themes. See attached screen shot.
Comment #5
traviscarden commentedThank you, @scarer.
The PAReview errors are false positives. See #1.
Vertical tabs always display that way in Bartik; it's not a function of my implementation.
Comment #6
targoo commentedHi
manual review:
1) Your using variables -> you got to remove them on hook_uninstall with variable_del()
Run a db_delete() against the variable table with LIKE checklistapi_checklist_%.
Best,
Comment #7
traviscarden commentedThank you, @targoo. I thought about that, but the variables won't belong to the API—they'll belong to the implementing modules. If I take responsibility for removing them in
checklistapi_uninstall()they may not always be properly removed. For example, suppose foochecklist.module and barchecklist.module both implement the API. If a user installs and uses both and then only uninstalls foochecklist.module, the API won't be uninstalled, sochecklistapi_uninstall()won't be executed and foochecklist.module's variables won't be deleted. If you have a good solution for this, I would most gladly hear it. Otherwise, maybe I just need to add a note to the documentation that it's the responsibility of implementing modules to delete their own variables onhook_uninstall().Comment #8
klausiLooks good to me. Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.
Comment #9
targoo commentedindeed. A note should do the trick then.
Comment #10
patrickd commentedNice one!
Thanks for your contribution and welcome to the community of project contributors on drupal.org!
I've granted you the git vetted user role which will let you promote this to a full project and also create new projects as either sandbox or "full" projects depending on which you feel is best.
Thanks, 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.
As you continue to work on your module, keep in mind: Commit messages - providing history and credit and Release naming conventions.
Thanks to the dedicated reviewer(s) as well.
Comment #11.0
(not verified) commentedUpdated issues ummary.