[D7] SearchIndex Wipe

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)

Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).

I'm a robot and this is an automated message from Project Applications Scraper.

@Sagar Ramgade, thankyou for your contribution. As you have did three manual reviews but forget to add pareview bonus tag, so on the basis of that, this module priority come on top so here is my reviews.

Automated Review

Best practice issues identified by pareview.sh / drupalcs / coder. Yes, http://pareview.sh/pareview/httpgitdrupalorgsandboxsagarramgade2188697git reported few issues.

FILE: /var/www/drupal-7-pareview/pareview_temp/searchindex_wipe.module
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES
--------------------------------------------------------------------------------
28 | WARNING | Variable $table_name is undefined.
30 | WARNING | Variable $table_name is undefined.
--------------------------------------------------------------------------------

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and fragmentation.

Master Branch

(*) No: Follows the guidelines for master branch.

It appears you are working in the "7.x-1.x-dev" branch in git. You should really be working in a version specific branch. The most direct documentation on this is Moving from a master branch to a version branch. For additional resources please see the documentation about release naming conventions and creating a branch in git.

The following git branches do not match the release branch pattern, you should remove/rename them. See https://www.drupal.org/node/1015226

Licensing

Yes: Follows the licensing requirements

3rd party code

Yes: Follows the guidelines for 3rd party code.

README.txt/README.md

(*) No: Follows the guidelines for in-project documentation and the README Template.

Code long/complex enough for review

No: Follows the guidelines for project length and complexity. Will proceed with single project promotion.

Secure code

Yes. If "no", list security issues identified.

Coding style & Drupal API usage

1. (*) At the time of installation of this module getting fatal error
   Parse error: syntax error, unexpected '=>' (T_DOUBLE_ARROW) in C:\xampp\htdocs\drupal731\sites\all\modules\2188697\searchindex_wipe.module on line 28.

   It should be foreach ($schema as $table_name => $table) { instead of foreach ($schema => $table_name as $table) {.

2. hook_help() is missing in your module.
3. (+) In your Readme file, you are giving admin/settings/search which is incorrect path. it should be admin/config/search/settings

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

You should fix above issues first and get another review bonus by manual reviews of another 3 modules that would help speed up the process and make sure it gets on the review admins radar.

Thanks again!

Hi Sagar,

Git clone command that you mentioned above doesn't seem to be correct one.

git clone --branch 7.x-1.x-dev http://git.drupal.org/sandbox/SagarRamgade/2188697.git searchindex_wipe

Can you please check it.

Hi gaurav,
Thanks to notify us. I have replaced git clone link.

Updated issue summary.

Automated Review

Best practice issues identified by pareview.sh

Review of the 7.x-1.x branch (commit 3d104f0):

Remove all .idea files from your repository.
No automated test cases were found, did you consider writing Simpletests or PHPUnit tests? This is not a requirement but encouraged for professional software development.

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and fragmentation.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements

3rd party code

Yes: Follows the guidelines for 3rd party code.

README.txt/README.md

(*) No: Does not follow the guidelines for in-project documentation and the README Template.

Please add more detail about the module and how it functions to the README.txt

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

Yes. If "no", list security issues identified.

Coding style & Drupal API usage

No major issues identified during manual review, code looks clean and functioned properly in my test environment. Only 1 minor issue, the README.txt file, was identified.

1. (*) Major finding
2. Minor finding
3. (+) Release blocker
4. (*) Major finding

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.

This review uses the Project Application Review Template.

Note: consider adding more information to the project page as well. There isn't enough information there to help a user decide if this module is appropriate for their use. Ideally much of the information on the project page can be used in the README.txt file as well.

Hi @Sagar Ramgade
Thanks for your contribution

Automated Review

Best practice issues identified by pareview.sh / drupalcs / coder. There are still showing some of the warnings identified by the pareview Please see http://pareview.sh/pareview/httpgitdrupalorgsandboxsagarramgade2188697git

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and fragmentation.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements

3rd party code

No: Follows the guidelines for 3rd party code.

README.txt/README.md

Yes: Follows the guidelines for in-project documentation and the README Template.

Code long/complex enough for review

No: Follows the guidelines for project length and complexity.

Secure code

Yes.There is only single button provided by the module at the site search configuration page.No issues found.If "no", list security issues identified.

Coding style & Drupal API usage

1. Implement hook_form_formid_alter in place of hook_form_FORM_ID_alter() because it provides the form-specific alteration instead of the global hook_form_alter() IMHO

Thanks Again!!

This review uses the Project Application Review Template.

Getting review bonus would help speed up the process and make sure it gets on the review admins radar.

Today, I've made a revision

Some warnings detected by pareview:
http://pareview.sh/pareview/httpgitdrupalorgsandboxsagarramgade2188697git

Individual user account
Yes: Follows the guidelines for individual user accounts.

No duplication
Yes: Does not cause module duplication and fragmentation.

Master Branch
Yes: Follows the guidelines for master branch.

Licensing
No: You must follows the licensing requirements.

3rd party code
Yes: Follows the guidelines for 3rd party code.

README.txt/README.md Yes: Follows the href="https://www.drupal.org/node/161085">guidelines for in-project
documentation. You can improve in this subject taking a look to
href="https://www.drupal.org/node/161085#recommended_practices">Recommended
practices

Code long/complex enough for review No: Follows the href="https://groups.drupal.org/node/195848">guidelines for project
length.
1. (*) The project have less than five function or class method definitions
2. (*) The PHP/Javscript source code is less than 120 lines long (including comments and whitespace).

Secure code No: Follows the href="https://www.drupal.org/writing-secure-code">Writing secure
code.
1. (*) Take a look to href="https://www.drupal.org/node/28984">Handle text in a secure
fashion. You must use check_markup if you are using rich text.

@davidam: could you specify where exactly check_markup() should be used in the code? What licensing requirements are in violation, what should the applicant do?

@klausi: In the commit 65e3e4f645bc0d20ebf63388301079e02fb6bd60 @sagar-ramgade has added check_markup(), IMHO now is fine. In the licensing I was wrong about the process in drupal: I thought that the developer must add the license, but it seems that the license is added automatically, when the project becomes full project.

Hi,

My two cents to your work.
Don't forget to clean your git repository by adding in .gitignore the .idea folder.
And you should add a newline at the beginning of the README.txt file to avoid pareview warning.

Regards,
Antoine

Review of the 7.x-1.x branch (commit 032023b):

No automated test cases were found, did you consider writing Simpletests or PHPUnit tests? This is not a requirement but encouraged for professional software development.
Manual Review :
1)searchindex_wipe.module file : function searchindex_wipe_confirm_submit : Use $form_state['redirect'] = 'admin/config/search/settings'; instead of drupal_goto('admin/config/search/settings'); as this avoid a function call.
I have not found any release blocker.So setting this RTBC :)

As the git administers are busy in reviewing the applications.They will reach to your project application ASAP.I have added the Review bonus tag to your application so that it wil come in high priority list.
As your project needs to be published by manually by any git administer because it has code less than 120 lines including comments.

Assigning to myself for next review, which will be either tonight or tomorrow morning.

Automated Review

Review of the 7.x-1.x branch (commit 98ae065):

• No automated test cases were found, did you consider writing Simpletests or PHPUnit tests? This is not a requirement but encouraged for professional software development.

This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. You have to get a review bonus to get a review from me.

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

[Yes: Does not cause / No: Causes] module duplication and/or fragmentation.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements.

3rd party code

Yes: Follows the guidelines for 3rd party code.

README.txt/README.md

Yes: Follows / No: Does not follow] the guidelines for in-project documentation and/or the README Template.

Code long/complex enough for review

No: Does not follow] the guidelines for project length and complexity.

7 functions / 92 lines. Of the actual lines of code, there isn't much demonstration of the API to warrant an exception to single project promtion.

Secure code

[Yes: Meets the security requirements. / No: List of security issues identified.]

Coding style & Drupal API usage

I see no reason you can't put the menu path under admin/config/search/settings/. Maybe admin/config/search/settings/wipe?

(+) No need for the check_markup in searchindex_wipe_help(); that isn't user input.

(+) In searchindex_wipe_help(), don't split the string across lines just to appease PAReview. Split strings are harder to translate.

The starred items (*) are fairly big issues and warrant going back to Needs Work. Items marked with a plus sign (+) are important and should be addressed before a stable project release. The rest of the comments in the code walkthrough are recommendations.

Not seeing any blocking issues.

If added, please don't remove the security tag, we keep that for statistics and to show examples of security problems.

This review uses the Project Application Review Template.

Code too short

This project is too short to approve you as git vetted user. We are currently discussing how much code we need, but everything with less than 120 lines of code or less than 5 functions cannot be seriously reviewed. However, we can promote this single project manually to a full project for you.

Code too simple

This project does not demonstrate sufficient hook usage and/or API integration, therefore it is only eligible for a one-time promotion to a full project. You can find more info at Working with the Drupal API.

This is an important criterion so that code integrates well and can be improved over time. I encourage you to continue developing and gaining from the feedback available in the git approval process.

Thank you for you contributions and understanding.

This has been promoted: https://www.drupal.org/project/searchindex_wipe

Matthew,
I have not seen any release on the project page.Have you given all the rights to the @sagarramgade to create the new releases so that he will create the new releases of the module.

@sagarramgade is going to need to check that himself. That is not an explicit permission that I grant, but he should be able to add releases.

Ok Thanks! for letting me know.

Cool :) Seems good now.As you have also addressed #26

Multiple Applications

It appears that there have been multiple project applications opened under your username:

Project 1: https://www.drupal.org/node/2382569

Project 2: https://www.drupal.org/node/2338629

As successful completion of the project application process results in the applicant being granted the 'Create Full Projects' permission, there is no need to take multiple applications through the process. Once the first application has been successfully approved, then the applicant can promote other projects without review. Because of this, posting multiple applications is not necessary, and results in additional workload for reviewers ... which in turn results in longer wait times for everyone in the queue. With this in mind, your secondary applications have been marked as 'closed(duplicate)', with only one application left open (chosen at random).

If you prefer that we proceed through this review process with a different application than the one which was left open, then feel free to close the 'open' application as a duplicate, and re-open one of the project applications which had been closed.

I'm a robot and this is an automated message from Project Applications Scraper.