[D7] Drop Down Login

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.

Hi Sandeep,
Your module looks nice.

I have taken an overview and it need little tweaks.

1. Showing following error for logged out user :
   Strict warning: Only variables should be passed by reference in drop_down_login_dropdown() (line 70 of /Applications/MAMP/htdocs/myproject/sites/all/modules/custom/drop_down_login/drop_down_login.module).
2. To escape from the above error :
   change render(drupal_get_form('user_login')) to $login_form = drupal_get_form('user_login'); render($login_form);.
3. For README.txt file follow the ReadMe Standards.

Moving this to Needs Review then.

There are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxnashkrammer2367405git

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

Multiple Applications

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

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

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

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.

Automated Review

Best practice issues identified by pareview.sh seems to be clean.

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and/or fragmentation.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements.

3rd party assets/code

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

README.txt/README.md

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

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

Yes: Meets the security requirements.

Coding style & Drupal API usage

List of identified issues in no particular order. Use (*) and (+) to indicate an issue importance. Replace the text below by the issues themselves:

1. Just a recommendation: In your .info file you have mentioned package as Package Name you should keep it blank until and unless there is matched package available there for your project.
2. Since there is no security issue in your module and it seems you have mistakenly added it to your module, I'm removing that tag. Instead of that I'm attaching this project to Single project promote tag.

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.

While different enough to potentially justify a new project, it's worth noting all of the similar modules and explaining what makes this one different.

https://www.drupal.org/project/modal_forms
https://www.drupal.org/project/betterlogin
https://www.drupal.org/project/ajax_register
https://www.drupal.org/project/bootstrap_login_modal

Hi Kreynen,

Thanks for suggestion. I have added modules you have mentioned under similar modules list in description. Drop down login is different from them in UI and does not have any dependency.

As per my last comment, I'm updating status to needs-review.

Automated Review

Git default branch is not set, see the documentation on setting a default branch.
Review of the 7.x-1.x branch (commit d6b0dbd):

• 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.

Source: http://pareview.sh/ - PAReview.sh online service

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and/or fragmentation.

Master Branch

No: Does not follow the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements.

3rd party assets/code

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

README.txt/README.md

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

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

Yes: Meets the security requirements.

Coding style & Drupal API usage

1. * Drupal behaviors are inproperly used. See https://www.drupal.org/node/756722. For example, please use context.
2. You can use jQuery.toggleclass instead of adding and removing a class.
3. It's better to prefix block IDs with module name.
4. It's better to return a render array with #attached property set instead of adding JS/CSS via drupal_add_js/drupal_add_css(). See hook_block_view() comments.
5. + It's better to redirect user using $form_state['redirect'] property in hook_form_submit(). Otherwise, you can break other validate/submit handlers.
6. Use theme functions to render HTML instead of concatinating '' and so forth. See hook_theme.
7. * All strings should be wrapped in t() function to properly handle translation

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.

Automated Review

Best practice issues identified by pareview.sh is clean.

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and/or fragmentation.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements.

3rd party assets/code

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

README.txt/README.md

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

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

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

Coding style & Drupal API usage

List of identified issues in no particular order. Use (*) and (+) to indicate an issue importance. Replace the text below by the issues themselves:

1. None

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.

As there is no blocker found, I'm moving this project to RTBC. Thanks for your contribution.

Automated Review

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

• 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.

Source: http://pareview.sh/ - PAReview.sh online service

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and/or fragmentation.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements.

3rd party assets/code

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

README.txt/README.md

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

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

Yes: Meets the security requirements.

Coding style & Drupal API usage

[List of identified issues in no particular order. Use (*) and (+) to indicate an issue importance. Replace the text below by the issues themselves:

1. (+) It's incorrect to use HTML in t()
2. For such non-complex template it's better to use Render array as a block' output instead of theme function. For instance here
   a html_tag can be used
3. I suggest moving template file to 'theme' folder or creating additional 'templates'
4. Javascript is incorrectly formatted. See https://www.drupal.org/node/172169

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.

Hi k0teg,

Thank You for the review. I have fixed the issues you have mentioned as follows,
1) removed html from t().
2) Moved template file to the theme folder as suggested.
3) fixed javascript formatting.

Updating status to need review.

Automated Review

• 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.

Source: http://pareview.sh/ - PAReview.sh online service

Manual Review

Individual user account

Yes: Follows the guidelines for individual user accounts.

No duplication

Yes: Does not cause module duplication and/or fragmentation.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements.

3rd party assets/code

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

README.txt/README.md

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

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

Yes: Meets the security requirements.

Coding style & Drupal API usage

1. There should be a space after comma between when you call Javascript functions.
2. I suggest using a render array instead of templates.

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.

The module looks RTBC for me.

Automated Review

Git default branch is not set, see the documentation on setting a default branch.
Review of the 7.x-1.x branch (commit 08783b7):
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/or fragmentation.

Master Branch

Yes: Follows the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements.

3rd party assets/code

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

README.txt/README.md

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

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

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

Coding style & Drupal API usage

[List of identified issues in no particular order. Use (*) and (+) to indicate an issue importance. Replace the text below by the issues themselves:

1. Do not use underscores in your template file name, Ideally it should be drop-down-login.tpl.php
2. Your validation doesn't resepect the ?destination parameter, if validation failes it takes the user to destination path not /user path.
3. You should use template_preprocess_drop_down_login to define login form and others in a variables to optimize the code in your tpl.php
4. You may rename dropdown_login.js to drop_down_login.js, similarly for css file.

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.

Manual Review :
drop_down_login.info : No need to define the package if the package is other.
drop_down_login.module :

1. Correct comment above function drop_down_login_block_info to hook_block_info
2. Add a empty line after this function drop_down_login_theme
3. (+)Not found the template file inside the theme folder as defined in theme folder.
4. (*)Add hook_help.

Thanks!
Not found any release blocker. Setting this to RTBC :)
The project has more than 5 functions so removing the "PAReview: Single project promote" tag.

@naveenvalecha, for future reviews, not having a hook_help() isn't a blocking issue. I would make it a (+) one.

Assigning to myself for next review.

Thanks @mpdonadio!
Would u do let me know where the priority of issues is specified.Whether its blocker or not ?

@sandeep.kumbhatil,
Few minor tweaks :

function drop_down_login_dropdown() {
  global $user;
  $login_form = array();
  if ($user->uid == 0) {
    $login_form = drupal_get_form('user_login');
  }
  return theme('drop_down_login', array('login_form' => $login_form));
}

This is handled here that we need to display the login form to anonymous users only.So It seems that we don't need to do the same checks in drop-down-login.tpl.php

if ($user->uid == 0):
?>
  <!-- Drop-down mark-up for a logged-out user. -->
  <div class="dropdown">
<?php
    print render($login_form);
?>
  </div>
<?php endif; ?>

This is not application blockers.Still RTBC

Thanks!
One thing I missed in the above review.
you need to define the describe the all variables in the template http://cgit.drupalcode.org/sandbox-nashkrammer-2367405/tree/theme/drop-d...
like it is in http://cgit.drupalcode.org/uc_wishlist/tree/uc_wishlist_user_display.tpl...

Still +1 for RTBC.

Sorry for the delay, life (and some D8 work) got in the way...

Automated Review

pareview.sh http://git.drupal.org/sandbox/nashkrammer/2367405.git

Git default branch is not set, see the documentation on setting a default branch.

Review of the 7.x-1.x branch (commit 2e8a176):

• 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. There are multiple people in the commit logs, but the majority of the commits are from the applicant.

No duplication

Yes: Does not cause module duplication and/or fragmentation. Addressed.

Master Branch

Yes: Follows the guidelines for master branch, but still need to set the default branch on the project.

Licensing

Yes: Follows the licensing requirements.

3rd party code

Yes: Follows the guidelines for 3rd party code.

README.txt/README.md

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

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

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

Coding style & Drupal API usage

(+) I don't see the purpose for drop_down_login_validate_login(). Validation functions should just validate the form, and not do anything else.
I think this needs to be a submit handler?

(+) drop_down_login_block_view() should use a proper render array and not a #markup element.

(*) This needs a round of polishing. The template has too much logic/code in it. I think you could get rid of the .tpl.php, and just
build up a render array with two elements, the link and the login form. drop_down_login_block_view() should do the logged in/out
check (see user_is_anonymous istead of checking $user->uid), and then build up the proper element. drop_down_login_block_info() also likely
needs to set `'cache' => DRUPAL_CACHE_PER_ROLE`, to work properly.

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.

Hi @mpdonadio,

Thank you for taking time to review the module. I have implemented following fixes as you have suggested.

1. Added a render array instead of theme for login/logout links and block, hence removed the tpl.

2. The drop_down_login_validate_login() is to redirect the user to "/user" page for unsuccessful attempt to login, Just like the twitter and facebook style. If I put same code in submit handler it does not redirect since the core submit handler redirects first to current page with error message. Same way for a successful login user should go to the current page which works in submit handler drop_down_login_submit_login().

3. 'cache' => DRUPAL_CACHE_PER_ROLE this is default for hook_block_info() please suggest otherwise.

Updating to needs review.Thank You.

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

• 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:

• drop_down_login_validate_login(): why do you call drupal_redirect_form() here? This will break all other validation handlers that run after yours, because the redirect is issued immediately? Please add a comment.

But otherwise looks RTBC to me. Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.

Assigning to heddn as he might have time to take a final look at this.

@klausi thank you for reviewing.

As per your suggestion,

drop_down_login_validate_login(): why do you call drupal_redirect_form() here? This will break all other validation handlers that run after yours, because the redirect is issued immediately? Please add a comment.

-The functionality required is to take user to detailed user login page (/user) after a failed sign in attempt from any other pages like facebook and twitter style. Submit handler does not redirect since the core submit handler redirects first to current page with error message. Hence drupal_redirect_form() is added to validation handler which will redirect to /user , only in case of a invalid sign in attempt. If there user adds proper credentials all other validation and submit handlers should work.

I am looking any other method or work around to achieve this functionality, please suggest the same.
Thank You,

I should have a chance to look at this next.

no objections for more than a week, so ...

Thanks for your contribution, nashkrammer!

I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.

Here are some recommended readings to help with excellent maintainership:

• Dries' post on Responsible maintainers
• Best practices for creating and maintaining projects
• Maintaining a drupal.org project with Git
• Commit messages - providing history and credit
• Release naming conventions.
• Helping maintainers in the issue queues

You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!

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.

Thanks to the dedicated reviewer(s) as well.