This module implements a way to use the vCita online scheduling and appointment booking widget from within Drupal. vCita LiveSite(TM) creates a central, cloud-based facility for customers to connect via messaging or requests for appointments. It integrates with calendaring applications for free/busy time negotiations and appointment confirmations. With its contact management and email campaign facilities, it can act as a simple CRM solution.

The runtime integration is done using a javascript widget that will show a contact / scheduling form to site visitors. A vCita account is needed and can be created from the configuration page (admin/config/services/vcita).

Cloning the Code

Clone the 7.x-1.x branch:

git clone --branch 7.x-1.x http://git.drupal.org/sandbox/klausson/2335843.git vcita
cd vcita

Project sandbox: https://www.drupal.org/sandbox/klausson/2335843

Reviews of Other Projects

https://www.drupal.org/node/2291367#comment-9161263
https://www.drupal.org/node/2151429#comment-9161237
https://www.drupal.org/node/2273271#comment-9152927
https://www.drupal.org/node/2339243#comment-9161275
(still working on more)

Initial PAReview.sh

http://pareview.sh/pareview/httpgitdrupalorgsandboxklausson2335843git-7x-1x

Comments

PA robot’s picture

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.

klausson’s picture

Issue summary: View changes
dbt102’s picture

Hi @klausson,

I've taken a look at your project application and it looks good so far. I notice your are using web services, and I'm not a security expert, so I defer to others for additional review of that portion or your code. Using the review checklist I've gone thru and make the following comments...

1.1 The application issue does contains a project page and the “git clone” command there works just fine.

1.2 Looks like your project is the only one that connects into the vCita service.

1.3 There is not multiple applications open.

2.1 The repository does actually contain code. The code also meets the complexity requirements as described at https://groups.drupal.org/node/195848 .

2.2 Git Status returns “Your branch is up-to-date with ‘origin/7.x-1.x'.” This is a version specific branch which is what is required.

3.1 Pareview automated review returns no Security errors or warnings. However, since security is such an important issue, and since you are importing so much from a third party source I highly recommend reading through the documentation and double check your use of $form[] per examples at https://www.drupal.org/writing-secure-code

4.1 Your repository does not include a LICENSE.txt file. This is right.

4.2 The repository does not contain any 3rd party (non-GPL) code, which it shouldn't.

5.1 Project pages are helpful.

5.2 The repository does contains a detailed README.txt. This file does contain a basic overview of what the module does and how someone may use it. It looks like it follows the guidelines for in-project documentation and is based upon the README.txt Template.

5.3 The code contains a well-balanced amount of inline-comments.

6.1 Automated review does not show any major issues.

7.1 Looks like a nice job using Drupals API correctly.

klausson’s picture

Hi dbt102,

Thanks for the review! On the security / web services comment: I think you are referring to the fact that the module imports the javascript widget from an external website (vcita.com) to render the customer engagement form. The only risk I could see there is the code that gets rendered by vcita - the request originates from the drupal site so there is no opening for a cross-site scripting attack. Also, this appears to be common practice for similar integrations: Most live chat services operate using the same technique and technically, even Google Analytics and Quantcast do the same thing, even though they only render a single pixel.

Again, thanks.

Klaus

gaurav.pahuja’s picture

Status: Needs review » Needs work
FileSize
10.38 KB

Automated Review

Best practice issues identified by pareview.sh / drupalcs / coder.

No issues reported.

http://pareview.sh/pareview/httpgitdrupalorgsandboxklausson2335843git

Manual Review

Individual user account
Yes: https://www.drupal.org/u/klausson Follows the guidelines for individual user

accounts

.
No duplication
Yes. Havent found any similar module.: 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
Yes: Follows the guidelines for in-project documentation and the

href="https://www.drupal.org/node/2181737">README Template

.
Code long/complex enough for review
Yes: Follows the guidelines for project length and complexity.
Secure code
Yes. external Javascript files have been included which is a standard parctice. If "no", list security issues identified.
Coding style & Drupal API usage
  1. Minor finding: Not getting images properly. (Issue is coming only when base_path is not set to '/'
    VCita Error

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.

klausson’s picture

Hi Gaurav,

Thanks for the review! Quick question on the image issue: Could you show the path that the image tag is looking for? (trying to find ways to fix this - I'm using drupal_get_path to set the src tag to a directory inside the module at the moment).

Thx

Klaus

klausson’s picture

Status: Needs work » Needs review

Ah, never mind - I think I know what is going on. I just changed the way the path is generated to what should be a safer method using base_path() prepended to the path of the module. Can you please check whether this works in your install?

nostop8’s picture

FileSize
8.69 KB

Automated Review

No issues found with PA Review

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
Yes: Follows 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.
Coding style & Drupal API usage
  1. (*) Module's admin form: found a lot of custom URLs, that aren't wrapped with the Drupal url() function
  2. (*) vCita callback url should be wrapped with the url($callback_url, array('url' => 'absolute')) method and afterwards urlencoded, because it is used inside outgoing url as a parameter
  3. (*) User roles visibility function does not work properly
  4. (*) Pages visibility function does not work properly
  5. (*) Visibility never changes inside admin form after hitting save, because form element uses different name than DB variable
  6. (*) Visibility value 2 is never used
  7. (+) No need for watchdog 3 parameter $_GET. It should be NULL instead, because there are nothing to replace inside 2 parameter (message)

I'm also attaching patch which will fix all those issues mentioned above. It should help to fix the issues for you quickly. Simply apply it and see all the code that is providing issues and see how it should it be on my opinion.

klausson’s picture

Added fixes for the issues identified by Volodymyr - Thank you!

mpdonadio’s picture

Assigned: Unassigned » mpdonadio

Assigning to myself for next review.

mpdonadio’s picture

Status: Needs review » Needs work
Issue tags: +PAReview: security

Automated Review

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

  • Coder Sniffer has found some issues with your code (please check the Drupal coding standards).
    
    FILE: /home/matt/PAR/pareview_temp/vcita.module
    --------------------------------------------------------------------------------
    FOUND 1 ERROR AFFECTING 1 LINE
    --------------------------------------------------------------------------------
     80 | ERROR | Inline comments must end in full-stops, exclamation marks, or
        |       | question marks
    --------------------------------------------------------------------------------
    
    Time: 273ms; Memory: 7.5Mb
    
  • 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
Unknown: Follows the guidelines for individual user accounts. User pages on D.O. are throwing errors today, so I can't check this..
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.

(*) Unless you can point me to a place where it says usage is OK, the vcita_logo.png image has to be removed as it is third-party.

README.txt/README.md
Yes: Follows 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
No. If "no", list security issues identified.

(*) vcita_page_alter() uses vcita_account directly in a URL. This is user input, so it is possible for a user with the 'administer vcita' to inject something
naughty on the page. You need to check_plain() this. However, you should really use #attached to add this to the page. This supports
external scripts, and you can also do your protocol logic. #attached will sanitize the src via drupal_attributes() inside of the theme_html_tag() that eventually gets called.

Coding style & Drupal API usage
(+) Remove the .gitignore from the repo

You don't need to variable_set in a hook_install(); just use default values in your variable_get() calls.

Avoid directly using $_GET['q']. See request_uri() and friends (see the first comment on the API page.

(+) _vcita_user_visible() should not do role detection. Make a separate permission for this.

(+) The error message in vcita_callback() has an untranslated string. So does vcita_admin_settings_form() Double check the module.

vcita_admin_settings_form() should use API calls for making links, and #prefix / #suffix markup for the divs. I would also suggest using CSS background images instead of img elements.

In vcita_admin_settings_form(), why the `unset($form['actions']['submit']);`. Comment needed?

(+) Avoid breaking translatable strings across lines. This warning in pareview can be safely ignored.

(*) Where did that invite code in vcita_admin_settings_form_submit() come from?

(+) You are building the callback URL improperly in vcita_admin_settings_form_submit() and _vcita_link_account(). The $options parameter to drupal_goto will let you set request variables, which will also escape/encode them. However, you shouldn't drupal_goto from inside a submit handler. You should use $form_state['redirect']; see the comments to https://api.drupal.org/api/drupal/developer!topics!forms_api_reference.h...

In vcita_admin_settings_form_submit() you see if the email has changed. I think this should really be a validation step.

(+) In forms, don't explictly check for empty(). Set #required as needed.

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.

mpdonadio’s picture

Assigned: mpdonadio » Unassigned
klausson’s picture

Assigned: Unassigned » klausson
klausson’s picture

Assigned: klausson » Unassigned
Status: Needs work » Needs review

I went through the list of topics raised. Detailed responses to follow. The latest PAReview.sh check shows 4 warnings. Three are as expected the longer lines for translatable strings, the fourth says that line 44 of vcita.admin.inc lacks a whitespace around a concat operator. There are three string concatenators in that line and all three have whitespace to the left and right, so I'm concluding it's a false positive.

Individual user account
Unknown: Follows the guidelines for individual user accounts. User pages on D.O. are throwing errors today, so I can't check this..

drupal.org is back to normal today and shows my account as an individual account.

3rd party code
No: Follows the guidelines for 3rd party code.
(*) Unless you can point me to a place where it says usage is OK, the vcita_logo.png image has to be removed as it is third-party.

The image was actually sent to me by the company that is the integration target. However, since I'm not sure what the proper process is, I took out the logo for now until I can find out. I know the wikipedia rules require some public notice about images having a creative commons license and I suspect it's similar here. But the image does not contribute anything to the functionality so it can wait.

Secure code
No. If "no", list security issues identified.
(*) vcita_page_alter() uses vcita_account directly in a URL. This is user input, so it is possible for a user with the 'administer vcita' to inject something
naughty on the page. You need to check_plain() this. However, you should really use #attached to add this to the page. This supports
external scripts, and you can also do your protocol logic. #attached will sanitize the src via drupal_attributes() inside of the theme_html_tag() that eventually gets called.

This is an interesting one: the variable in vcita_account is actually NOT user input. It is automatically generated by the login form at vcita.com and then sent back as a URL parameter. So my initial reaction was that this should not be relevant. But then I thought about it a little more and figured there is actually a slight risk of URLs being tampered with in transit so I added the check_plain() also because it is not very costly ;-)

(+) Remove the .gitignore from the repo

I tried a git rm .gitignore, which worked locally but does not appear to propagate into the repository :-/ Any hint as to how this would work?

You don't need to variable_set in a hook_install(); just use default values in your variable_get() calls.

Removed from the install file and set as defaults in the form instead.

Avoid directly using $_GET['q']. See request_uri() and friends (see the first comment on the API page.

Actually request_uri would require parsing the string returned, which is already done in $_GET. I think the better API call is to drupal_get_query_parameters(). Implemented accordingly.

(+) _vcita_user_visible() should not do role detection. Make a separate permission for this.

I understand the goal of having permissions checked properly in a single place. However, this is a different use case and after going back and forth a few times about this, I'm coming down on the usability side - here's why: The use case for this module is to give customers a way to communicate with whoever runs the site. Typically, this is for an e-commerce site or similar setup. In this case, the widget should not be rendered, if in-house personnel is looking at a page - sort of the reverse of a permission check (we are not concerned about permissions, but about page clutter). More importantly though admins would expect visibility to be controlled in a single location rather than through a permissions check for roles and then with a url filter for pages. Hence, this should remain on one single page as it currently is.

(+) The error message in vcita_callback() has an untranslated string. So does vcita_admin_settings_form() Double check the module.

Fixed the error message. Assuming the note about the form was about the two strings embedded in the links, these are fixed in the context of having the links rendered with l() rather than manual string concatenation (see below).

vcita_admin_settings_form() should use API calls for making links, and #prefix / #suffix markup for the divs. I would also suggest using CSS background images instead of img elements.

Links are implemented with API calls to l() instead of manually and divs are created as prefix and suffix now.

In vcita_admin_settings_form(), why the `unset($form['actions']['submit']);`. Comment needed?

This was giving me trouble when I implemented the submit handler and adding the unset appeared to fix it (not sure why it is necessary though, except that it appears to be related to the system_settings_form() call). I added a comment explaining it.

(+) Avoid breaking translatable strings across lines. This warning in pareview can be safely ignored.

Fixed - which does indeed lead to the warnings in PAReview.sh.

(*) Where did that invite code in vcita_admin_settings_form_submit() come from?

It's for two reasons - one to distinguish the source of the invite (Drupal vs Wordpress and others), second to explicitly go to the login form (no invite) or the register form (with invite). I clarified in the comment.

(+) You are building the callback URL improperly in vcita_admin_settings_form_submit() and _vcita_link_account(). The $options parameter to drupal_goto will let you set request variables, which will also escape/encode them. However, you shouldn't drupal_goto from inside a submit handler. You should use $form_state['redirect']; see the comments to https://api.drupal.org/api/drupal/developer!topics!forms_api_reference.h...

I fixed the URL parameters for drupal_goto in both places. After reading up on $form_state['redirect'], I do not think it is the proper way to redirect in this case - here's why: The documentation states that by using this method, the form continues to pass through the chain of other registered form_submit, which gives other modules the chance to register a different redirect. In this case, we can't allow that since the redirect is needed to pass the user through the login form and back to continue the work on the form (sort of OAuth style). Therefore, we will need to stick with drupal_goto() in this case.

In vcita_admin_settings_form_submit() you see if the email has changed. I think this should really be a validation step.

Actually no. The check on the change of email is needed to decide whether a redirect to the login form is required. If there was no change, we can continue to use the existing account information. If there was a change, the user needs to log in to verify that it is really their account. Therefore, it must remain in the submit handler rather than the validator.

(+) In forms, don't explictly check for empty(). Set #required as needed.

There is no check for empty, only for NOT empty. The reason why it is needed is because an empty value is actually legitimate in this case and the validator should only kick in when the field is not empty. If it is left empty, we interpret this as a hint that there is no account yet and the user wants to register for one.

Switching back to "Needs Review" since all changes are made except the ones that need to remain as implemented.

naveenvalecha’s picture

Status: Needs review » Needs work

@klausson
Thanks for your contributions.

Automated Review

Best practice issues identified by pareview.sh / drupalcs / coder. http://pareview.sh/pareview/httpgitdrupalorgsandboxklausson2335843git-7x-1x Please fix the issues addressed here as @mpdonadio mentioned in #11. I am not confirmed answer about the question as you mentioned above someone else will let you know about it.

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/No: Follows the licensing requirements
3rd party code
Yes/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
Yes: Follows the guidelines for project length and complexity.
Secure code
Yes/No. If "no", list security issues identified.
Coding style & Drupal API usage
  1. (+) Remove the .gitignore from the repo.Also the same is mentioned in above #11.Use the git rm -f to remove it.Also the similar removal is here Remove the .gitignore file from the repository
  2. (+) Regarding the inline use of javascript in function vcita_page_alter(&$page) Write the javascript in a seperate file and attached it using like
    $form['#attached']['js'] = array(
      drupal_get_path('module', 'ajax_example') . '/ajax_example.js' => array(
      'type' => 'file',
      ),
    );

    that seems better approach to manage the javascript later also.

  3. Define the $widget_path, $settings_path variables value in constants in the vctia.admin.inc and used then in the function so that it will be easily chanageable later.Similarly for other variables like $invite_code,etc.Also use variable name $module_path instead of $mod_path in vcita_admin_settings_form
  4. Use proper comments above functions.Please see Comment standards
  5. (+)
      $node_types = array_keys(node_type_get_types());
      $ntypes = array();
      foreach ($node_types as $ntype) {
        $ntypes[$ntype] = $ntype;
      }

    Use the node_type_get_names function instead to get the names with machine names. $ntypes = node_type_get_names();

  6. (+)
      $node_types = array_keys(node_type_get_types());
      $ntypes = array();
      foreach ($node_types as $ntype) {
        $ntypes[$ntype] = $ntype;
      }

    Use this in place of node_type_get_names function instead to get the names with machine names. $ntypes = node_type_get_names();

  7. (+) Use this $role_options = array_map('check_plain', user_roles()); instead of this
    $roles = user_roles();
      $role_options = array();
      foreach ($roles as $rid => $rolename) {
        $role_options[$rid] = $rolename;
      }
  8. unset($form['actions']['submit']);

    I have uncommmented this code and the form was submitting fine. if you are still getting the problem then please elaborate a bit.

As I am not a git administrator, so I would recommend you, please help to review other project applications to get a review bonus. This will put you on the high priority list, then git administrators will take a look at your project right away :-)

This review uses the Project Application Review Template.

klausson’s picture

Status: Needs work » Needs review

Thanks for the review, naveenvalecha. Please see below for my answers:

Best practice issues identified by pareview.sh / drupalcs / coder. http://pareview.sh/pareview/httpgitdrupalorgsandboxklausson2335843git-7x-1x Please fix the issues addressed here as @mpdonadio mentioned in #11. I am not confirmed answer about the question as you mentioned above someone else will let you know about it.

There was one issue raised in mpdonadio's review, which is fixed. Four new ones are introduced as per my message above. Three of them are direct results of fixes requested by mpdonadio. The fourth is IMHO a false positive since the whitespaces are definitely in the correct place.

(+) Remove the .gitignore from the repo.Also the same is mentioned in above #11.Use the git rm -f to remove it.Also the similar removal is here Remove the .gitignore file from the repository

Thanks, it looks like the -f flag did the trick. .gitignore is now gone.

Define the $widget_path, $settings_path variables value in constants in the vctia.admin.inc and used then in the function so that it will be easily chanageable later.Similarly for other variables like $invite_code,etc.Also use variable name $module_path instead of $mod_path in vcita_admin_settings_form

Changed the variable name. But I do not agree on the use of constants since the strings are dynamically assembled with inserted values.

Use proper comments above functions.Please see Comment standards

Where do you think the comment standards are violated?

Use the node_type_get_names function instead to get the names with machine names. $ntypes = node_type_get_names();

Done.

I believe #6 is a duplicate of #5.

(+) Use this $role_options = array_map('check_plain', user_roles()); instead of this

Done.

unset($form['actions']['submit']);
I have uncommmented this code and the form was submitting fine. if you are still getting the problem then please elaborate a bit.

You are indeed correct. I'm not sure why this was behaving differently earlier, but it does now work without the unset line.

As I am not a git administrator, so I would recommend you, please help to review other project applications to get a review bonus. This will put you on the high priority list, then git administrators will take a look at your project right away :-)

My understanding is that for the review bonus, three full reviews are required. As you can see at the top of the page, I currently have four and am working on additional ones. As a result, this application is indeed marked as qualifying for the review bonus and part of the high priority list.

Thx

klausson’s picture

It looks like I forgot to address #2 in naveenvalecha's list:

(+) Regarding the inline use of javascript in function vcita_page_alter(&$page) Write the javascript in a seperate file and attached it using like

$form['#attached']['js'] = array(
  drupal_get_path('module', 'ajax_example') . '/ajax_example.js' => array(
  'type' => 'file',
  ),
);

that seems better approach to manage the javascript later also.

Actually, this does not work in this case. Here's why: $form['#attached']['js'] does not appear to work in a page_alter call. Instead, I have the equivalent now in $page['content']['#attached']['js']. On the bigger topic of moving the javascript code into a separate file, this will not be possible since the account id is a PHP variable that needs to be filled in at runtime (different from site to site and can be changed). Hence 'type' will have to remain => 'inline'.

naveenvalecha’s picture

Thanks @klausson for the updates.
Regarding the reviewing other project applications so that it will be helpful for the git admins to come on your application ASAP.

mpdonadio’s picture

The project already has a review bonus, so it is on the high priority list to be reviewed.

er.pushpinderrana’s picture

Assigned: Unassigned » er.pushpinderrana

Assigning to myself for next review, which will hopefully be tonight.

er.pushpinderrana’s picture

Assigned: er.pushpinderrana » Unassigned
Status: Needs review » Reviewed & tested by the community

Automated Review

http://pareview.sh/pareview/httpgitdrupalorgsandboxklausson2335843git reported following minor issues that need to be fix.

FILE: /var/www/drupal-7-pareview/pareview_temp/vcita.admin.inc
--------------------------------------------------------------------------------
FOUND 1 ERROR AND 2 WARNINGS AFFECTING 3 LINES
--------------------------------------------------------------------------------
42 | ERROR | Concat operator must be surrounded by spaces
154 | WARNING | Line exceeds 80 characters; contains 99 characters
192 | WARNING | Line exceeds 80 characters; contains 99 characters
--------------------------------------------------------------------------------

Manual Review

(+) vcita_admin_settings_form(): I have tested this module functionality and all functionality works as intended except one thing. All form elements values are not inserting in database that need to be fix to test this module further. I am not marking this issue as blocker because it needs a minimal changes in your code to make it works, but you fix this issue on priority to proceed further.

I fixed the URL parameters for drupal_goto in both places. After reading up on $form_state['redirect'], I do not think it is the proper way to redirect in this case - here's why: The documentation states that by using this method, the form continues to pass through the chain of other registered form_submit, which gives other modules the chance to register a different redirect. In this case, we can't allow that since the redirect is needed to pass the user through the login form and back to continue the work on the form (sort of OAuth style). Therefore, we will need to stick with drupal_goto() in this case.

I tested module functionality and callback URL function properly after a valid authentication that seems good.

(+) vcita_admin_settings_form(): Wrong doc hook_admin_settings_form() is not a valid hook, fix it.

(+) vcita_admin_settings_form(): At line 37 and 42, you are rendering image directly through <img> tag, rather use theme_image().

(+) vcita_uninstall(): Some unused variables (vcita__active_tab, vcita_visibility) exist that need to be remove.

hook_help() is missing in your module.

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.

I am marking this RTBC as inline comments and code looks good to me. Also all the points mentioned by other admin are answered or fixed that shows author has decent idea of what he is doing.

Thanks!

klausson’s picture

Hi Pushpinder,

Thank you for the review and the status update. I fixed the points raised above, except for two:

- I tested the form and it does appear to save the values that I change. When I reload the form and when I bring it up in a different browser, the values are changed. Can you let me know how to test in case I'm missing something?

- When uninstalling the module, both variables you mention are being removed. I know an earlier version of the module did not remove them. Is it possible that you have the master branch instead of 7.x-1.x?

Everything else is fixed as suggested in the latest version.

Thanks!
Klaus

klausson’s picture

One more thing to point out: PAReview.sh now comes back with 4 warnings. 2 are the result of an earlier recommendation to not break translatable strings into separate lines despite what PAReview says. The other two are the result of the theme_image() call as recommended above. I am not an expert on theming, but the documentation seems to suggest that there are two camps on the topic - one that advocates this technique, the other seems to suggest it's wrong. If anybody wants to be the tiebreaker on this, I'm happy to do it either way ;-)

gaurav.pahuja’s picture

Here is how I was able to reproduce this issue:

Enabled this module.

Accessed URL: admin/config/services/vcita

Error1

Checked both 'Article' and 'Basic Page' from 'Node Type Settings' and submitted the form.

I was redirected to Vcita page.

Error

Again went to configuration page, but checkboxes for Node Types are not enabled.

Error

klausson’s picture

Ah, got it - this is because there was no account enabled yet upon the first save. Need to look into it - I suspect there is no harm in saving settings without an account present (initial assumption was there has to be an account before it can be configured).

klausson’s picture

I changed the submit function and it now properly gets processed in all cases including upon account change.

madhusudanmca’s picture

Hi klausson,

Thanks for your contribution!!

This module worked fine for me!! However I can seem some minor problems with automated script

Automated Review

No

  • Coder Sniffer has found some issues with your code (please check the Drupal coding standards).

    <p></p>
    <p>FILE: /var/www/drupal-7-pareview/pareview_temp/vcita.admin.inc<br>
    --------------------------------------------------------------------------------<br>
    FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES<br>
    --------------------------------------------------------------------------------<br>
     170 | WARNING | Line exceeds 80 characters; contains 99 characters<br>
     211 | WARNING | Line exceeds 80 characters; contains 99 characters<br>
    --------------------------------------------------------------------------------</p>
    

    Time: 131ms; Memory: 7.25Mb<br>
    
  • DrupalPractice has found some issues with your code, but could be false positives.

    <p></p>
    <p>FILE: /var/www/drupal-7-pareview/pareview_temp/vcita.admin.inc<br>
    --------------------------------------------------------------------------------<br>
    FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES<br>
    --------------------------------------------------------------------------------<br>
     48 | WARNING | Do not call theme functions directly, use theme('image', ...)<br>
        |         | instead<br>
     58 | WARNING | Do not call theme functions directly, use theme('image', ...)<br>
        |         | instead<br>
    --------------------------------------------------------------------------------</p>
    

    Time: 63ms; Memory: 5.5Mb<br>
    
  • 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.

It'll be good if you can fix above before it's final release to give a nice and clean module!! :)

+1 RTBC !!

Thanks!!

klausson’s picture

Hi Madhusudan,

Thanks for the review. Both types of warnings in PAReview are direct results of earlier fixes. You can look up the history in comment #14 (about the translatable strings) and in comment #23 (about the call to theme_image). In other words, the warnings cannot be fixed without creating a bigger problem.

Klaus

er.pushpinderrana’s picture

Status: Reviewed & tested by the community » Fixed

Automated Review

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

Coder Sniffer has found some issues with your code (please check the Drupal coding standards).
FILE: /var/www/drupal-7-pareview/pareview_temp/vcita.admin.inc
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES
--------------------------------------------------------------------------------
170 | WARNING | Line exceeds 80 characters; contains 99 characters
211 | WARNING | Line exceeds 80 characters; contains 99 characters
--------------------------------------------------------------------------------

Time: 128ms; Memory: 7.25Mb

DrupalPractice has found some issues with your code, but could be false positives.
FILE: /var/www/drupal-7-pareview/pareview_temp/vcita.admin.inc
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 2 WARNINGS AFFECTING 2 LINES
--------------------------------------------------------------------------------
48 | WARNING | Do not call theme functions directly, use theme('image', ...)
| | instead
58 | WARNING | Do not call theme functions directly, use theme('image', ...)
| | instead
--------------------------------------------------------------------------------

All comments must be under 80 characters, start with a capital letter, and end with a period (.). See https://www.drupal.org/node/1354. It would fix above two warnings but for theme_image() these warnings can be false or you can try theme() function instead.

Manual Review

OK, 14 days since me setting this RTBC and also all my #21 concerns has been addressed except following.

(+) vcita_uninstall(): Some unused variables (vcita__active_tab, vcita_visibility) exist that need to be remove.

Still exists, delete following lines of code as these variables are not in use.

variable_del('vcita__active_tab');
variable_del('vcita_visibility');

vcita_requirements(): Would be good to take care of translation, $t = get_t(); function to ensure translations don't break during installation. Also for concatenation, usage of t() with placeholder would be good.

'description' => 'vCita has not been configured yet. Go to <a href="' . $admin_url . '">vCita Settings</a>',

See: https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/t/7.

I also tested module functionality and it works as intended, after a manual scan didn't see anything blocking issue, so...

Thanks for your contribution, klausson!

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:

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.

Status: Fixed » Closed (fixed)

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