[D7] Single Page Site

Multiple Applications

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

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

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

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.

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.

Fixed GIT clone link.

Some of the initial review comments:

No error while cloning the module and then enabling it.

[root@bangvmplccpc01 modules]# git clone --branch 7.x-1.x http://git.drupal.org/sandbox/robin.ingelbrecht/2346267.git single_page_site
Initialized empty Git repository in /var/www/html/audio/sites/all/modules/single_page_site/.git/
remote: Counting objects: 82, done.
remote: Compressing objects: 100% (79/79), done.
remote: Total 82 (delta 37), reused 0 (delta 0)
Unpacking objects: 100% (82/82), done.
[root@bangvmplccpc01 modules]# drush en single_page_site
The following projects have unmet dependencies:                                                                                                              [ok]
single_page_site requires menu_attributes
Would you like to download them? (y/n): y
Project menu_attributes (7.x-1.0-rc2) downloaded to sites/all/modules/menu_attributes.                                                                       [success]
The following extensions will be enabled: single_page_site, menu_attributes
Do you really want to continue? (y/n): y
single_page_site was enabled successfully.                                                                                                                   [ok]
single_page_site defines the following permissions: administer single page site
menu_attributes was enabled successfully.                                                                                                                    [ok]
menu_attributes defines the following permissions: administer menu attributes

Strip tags for all input fields:

JS error on configuration page:

When a menu link item with url <front> is used I get an error.

@Robin

When using a vhosts installation the use of

var basePath = Drupal.settings.basePath;

returns "/",

This should resolve this issue:
http://data.agaric.com/get-complete-base-url-drupal-site#comment-1630

Everything seems to work just oké now, also tested on a multilingual website.

Tested and works as expected.

Possible improvement would be using a theming function or a rendrable array.

- Typo in some files. 'singe page' should be 'single page' of course.

js/menu.js:19:          // We are on the singe page, just add anchor.
README.txt:4:It allows you to automatically create a singe page from a menu. 
README.txt:23:2. Go to Admin -> Configuration -> System -> Singe Page Site Settings, and make
single_page_site.module:64: * Renders singe page.

- A menu item single-page-site has its access callback to TRUE. Permission on that page would make sense (eg. View single page).
- Just return the output array in your page callback. Use a template file or theming function.

The module else works like it should, no hiccups in configuration or whatsoever.

Nice work, i've tested it and also started the jQuery update module to test your javascript when both modules are working. Everything seems fine.

I saw that you have fixed the problem with path, but ... if possible make some validation on the configuration page so it would not let you select a menu which has a menu item with as path.

I saw also one not so important thing in the code. You should consider to give this to a t() function maybe ...
$output .= "

An error '" . $page_callback_result . "' occurred for " . $item['#href'] . '

'; it is line 168 in single_page_site.module.

And btw add also to your project page info about "Module attributes" dependency.

No remarks. All remarks sees to be implemented correctly. It would be awesome though, if there would be a possibility to have multiple single pages in a single Drupal website, but perhaps this is out of the scope of your module.

No remarks. All remarks sees to be implemented correctly. It would be awesome though, if there would be a possibility to have multiple single pages in a single Drupal website, but perhaps this is out of the scope of your module.

Assigning to myself for my next review.

I am taking my name off of this, as I have gotten swamped and can not complete this review. My partial review is below. The single_page_site_callback() function needs some very close attention for both API issues and security problems. The filter-on-save, though, would have been a blocking issuue anyway, as this falls under the Major API problems.

Automated Review

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

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

  
  FILE: /home/matt/PAR/pareview_temp/single-page-site.tpl.php
  --------------------------------------------------------------------------------
  FOUND 1 ERROR AFFECTING 1 LINE
  --------------------------------------------------------------------------------
   5 | ERROR | Doc comment long description must start with a capital letter
  --------------------------------------------------------------------------------
  
  Time: 486ms; Memory: 8.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

Yes: Follows the guidelines for individual user accounts.

No duplication

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

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

Maybe: Follows the guidelines for in-project documentation and the README Template, could probably be longer.

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

You could potentially make your single_page_site_settings_form() a proper system settings form.

(*) Your single_page_site_settings_form_submit() is filtering on save. This is not the Drupal way. See https://www.drupal.org/node/28984 and https://www.drupal.org/node/263002

You may want to validate some of those settings, like the menu.

(+) All of your behaviors should use the context and settings variables that get passed in.

Why does Drupal.behaviors.scrolltoanchors have a $(document).ready() in it? This is what the .attach does.

You may want to put single_page_site_callback() in an include. This can help reduce memory footprint.

#attached is preferred over drupal_add_js and drupal_add_css().

(+) Your link usage in the error message at the top of single_page_site_callback() is incorrect. See https://api.drupal.org/api/drupal/includes%21common.inc/function/l/7

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.

Assigning to myself for next review.

Automated Review

Best practice issues identified by pareview.sh / drupalcs / coder. Yes, http://pareview.sh/pareview/httpgitdrupalorgsandboxrobiningelbrecht23462... reported some issues that need to be fix. See https://www.drupal.org/coding-standards/docs#inline.

FILE: /var/www/drupal-7-pareview/pareview_temp/single-page-site.tpl.php
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
5 | ERROR | Doc comment long description must start with a capital letter
--------------------------------------------------------------------------------

FILE: .../drupal-7-pareview/pareview_temp/includes/single_page_site.callback.inc
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------------------
87 | WARNING | Line exceeds 80 characters; contains 90 characters
--------------------------------------------------------------------------------

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. Could be expanded more.

Code long/complex enough for review

Yes: Follows the guidelines for project length and complexity.

Secure code

1. (*) No: single_page_site_callback(): This is vulnerable to XSS exploits. If I enter <script>alert('XSS');</script> in the Single Page Site Settings form, it break the final output page (single-page-site) because user input directly rendered. You need to sanitize this before rendering, make sure to read https://www.drupal.org/node/28984 again.

   You should sanitize following code and handle the output text in proper manner:

   $href = $item['#href'];
           $anchor = _single_page_site_generate_anchor(drupal_get_path_alias($href));
           $item_title = $item['#title'];
           $item_tag = $settings['tag'];

   
   
   
   

Coding style & Drupal API usage

1. (*) single_page_site_page_build(): You are passing some values to js file, If I enter any html tag or special character especially ` in Single Page Site Settings form, it break the js code. IMHO, either you escape the html tag and special character in JS or prevent the same on form submission.
   
   
   
   
   
2. (+) #attached is preferred over drupal_add_js and drupal_add_css().
   

   But the js files won't load... So I'm still using drupal_add_js.

   You should use #attached as given below.

   /**
    * Implements hook_page_build().
    */
   function single_page_site_page_build(&$page) {
     global $language;
     $settings = variable_get('single_page_site_settings', array());
     if (!empty($settings)) {
       $path = drupal_get_path('module', 'single_page_site');
       $page['page_bottom']['single_page_site'] = array(
         '#attached' => array(),
       );
       $attached = &$page['page_bottom']['single_page_site']['#attached'];
       $options = array('every_page' => TRUE);
       // Add JS to create anchors.
       $attached['js'][$path . '/js/menu.js'] = $options;
       $settings_js = array(
         'className' => !empty($settings['class']) ? $settings['class'] : 'li',
         'menuClass' => $settings['menuclass'],
         'isFrontpage' => $settings['homepage'],
       );
       if (!$settings['homepage']) {
         $settings_js['singlePage']['urlAlias'] = drupal_get_path_alias('single-page-site', $language->language);
       }
       $attached['js'][] = array(
         'data' => array('singlePage' => $settings_js),
         'type' => 'setting',
       );
     }
   }
   

3. (+) single_page_site_settings_form(): the filter_xss() for default value of form elements is wrong here, because #default_value will get sanitized automatically. See https://www.drupal.org/node/28984. When handling data, the golden rule is to store exactly what the user typed. When a user edits a post they created earlier, the form should contain the same things as it did when they first submitted it.

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.

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

(*) single_page_site_page_build(): You are passing some values to js file, If I enter any html tag or special character especially ` in Single Page Site Settings form, it break the js code. IMHO, either you escape the html tag and special character in JS or prevent the same on form submission.

Still this issue exist in your updated code, tested on drupal 7.32 vanilla js still break on admin page.

(+) single_page_site_settings_form(): the filter_xss() for default value of form elements is wrong here, because #default_value will get sanitized automatically. See https://www.drupal.org/node/28984. When handling data, the golden rule is to store exactly what the user typed. When a user edits a post they created earlier, the form should contain the same things as it did when they first submitted it.

Still same behavior exist as filter_xss() is there. I would recommend you, prevent these html tags and special character ' at form submission time using validation See https://api.drupal.org/api/drupal/modules!node!node.api.php/function/hoo....

manual review of 7.x-1.x:

1. single_page_site_help(): filter_xss_admin() and check_plain() are wrong here since you do not print user provided text. You are only printing contents from the README, which is hard coded and not a security threat, right?
2. single_page_site_settings_form(): doc block is wrong, this is not a hook but a form building function. See https://www.drupal.org/coding-standards/docs#forms
3. "module_invoke_all('single_page_site_output', $output, $current_item_count);": Hooks that are provided by a module should be documented in MODULENAME.api.php, see http://drupal.org/node/161085#api_php
4. "drupal_set_title(t('!title', array('!title' => $settings['title'])));": that is not a useful translation. This looks like a rare case where you pass the dynamic variable to t() or check if i18n module string translation is available.
5. single_page_site_callback(): why do you call drupal_render() here? That is very unfortunate for the alter hook which now has to operate on a flat string instead of a structured array with all unrendered page callback results in it.
6. single_page_site_callback(): why do you invoke 2 hooks here? hook_single_page_site_output() does exactly the same thing as hook_single_page_site_output_alter()? I think the alter hook alone is enough.

But that are not critical application blockers, 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 er.pushpinderrana as he might have time to take a final look at this.

Automated Review

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

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

• 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

All blocking issues mentioned in #33 have been addressed. But as Kalusi's mentioned, "drupal_set_title(t('!title', array('!title' => $settings['title'])));": still there that looks awkward to me as well but this is not a blocker.

I also tested functionality of this module and it worked as intended so...

Thanks for your contribution, robin.ingelbrecht!

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.