Block Commenter

Automated Review:
An automated review of your project has found some issues with your code; As coding standards make sure projects are coded in a consistent style we please you to have a look at the report and try to fix them. Anyway, note that issues found are possibly false positives and fixing all issues is not a requirement for getting through the application process.

You can find the results of the automated report at http://ventral.org/pareview/httpgitdrupalorgsandboxsanchigirotra1673292git.

Putting status to needs work.

Removing review bonus tag, you did only one manual review out of 3 reviews. Please take a look at the actual source code of the projects. When finishing your review comment also set the issue status either to "needs work" (you found some problems with the project) or "reviewed & tested by the community" (you found no flaws).

Reviewed module with #comment-6211658

manual review:

1. "variable_get('bc_radio', 0),": bc_radio is a bad variable name, it should be more self-explaining what is in it.
2. block_commenter_uninstall(): deleting all variables starting with "bc_" looks a bit dangerous to me. Better use your full module name for your variables to avoid any name clashes with other modules.
3. block_commenter_admin_settings_submit(): do not use the raw $form_state['input'], use $form_state['values'] instead.
4. block_commenter_admin_settings(): this will not scale for large sites where you want to block many users. Your variable will get really big over time. Why can't you use the blocked property of the user module that completely disables user accounts? Or do you want spam users to able to login and use the site in the future?

Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.

Adding project reviewed manually and removed the automated reviews.

manual reivew:

1. block_commenter_admin_settings(): this is still a scalability problem. If I have 100 blocked users they will surely not fit into this one textfield.
2. block_commenter_admin_settings_submit(): similar here: if I have 100 users to block with 100 comments each you will have to run the comment action on 10,000 comments in one request. PHP will just stop with a timeout or memory exhaustion.
3. block_commenter_node_view(): why is the foreach() loop needed? It doesn't do anything?

Anyway, that are not application blockers, so this looks RTBC to me. Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.

@sanchi.girotra when you applying for PAReview: review bonus I will post my review. I will wait.

@drupwash: do not set issues to "needs work" if there is nothing wrong with the application.

manual review:
When I choose any user as Unpublish or delete for a particular content type to block commenting its work but there is no option to post comments again. Means if user x has blocked to post comments then x will never be able to post comments if admin think that x user should able to post comments, so x user needs to unblock.

Still RTBC to me.

Your project page is not very detailed, please have a look at the tips for a great project page, you may also use HTML-tags for better structure.

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.