[D7] Files Version

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.

Manual Review

Individual user account

Yes: Follows.

No duplication

Yes: Does not cause.

Master Branch

Yes: Follows.

Licensing

Yes: Follows.

3rd party assets/code

Yes: Follows.

README.txt/README.md

Yes: Follows.

Code long/complex enough for review

Yes: Follows.

Secure code

Yes: Meets the security requirements.

Coding style & Drupal API usage

List of identified issues in no particular order.

1. (+)Write hook_uninstall() - for deleting variables, after module removing.
2. (+) In file files_version.module, line 8 - included unavailable file (classes/class.Diff)
3. Line 117: chande count($versions) to !empty($versions).

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.

@rajveergang
All ok. I can more detailed review after 1-2 days.

Hi,

I have reviewed your module and have the following comments.

Manual Review

Individual user account
Yes: Follows.

No duplication
Yes: Does not cause

Master Branch
Yes: Follows

Licensing
Yes: Follows

3rd party assets/code
Yes: Follows

README.txt/README.md
No: Does not follow the guidelines for in-project documentation and/or the README Template.
You have clear instructions for installation, but the summary can be better. I am not sure of purpose by reading the readme page. Questions that I have: Are images, contrib modules, themes, css, etc.. backed up?
How do I use the diff feature? What directory is backed up, is it the drupal home?

Also it is helpful to put that the modules is found under Configure > Files Version in the menu.

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. (+) .git Folder should be excluded by default, or give user the choice. In my test, the batch job failed without much detail with I had .git folder present.
2. (+) The choose a version screen only shows a timestamp. It would be more userful in picking your archive if the timestamp was converted into a human readable date.
3. There are .tmp files added to module folder when I extracted an archive. For exampel fil58C.tmp.
4. I have the settings that only 2 backups should be kept, but I see a list of 4 items. 3 form Saturday nov 26, and 1 from Nov 27 from ny testing.

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.

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: Does follow the guidelines for in-project documentation and/or the README Template.
Although, the README.txt is getting fairly big and reading through it to find the necessary information can be daunting. You might consider splitting it into a new INSTALL.txt file to hold the installation process.

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
(+) You did write a hook_uninstall in files_version.install file, but you did not delete all your set variables. Here's a list of missing variables:
batch_request_time
If the files_version_maintain_file_version_finished function would not be called with $success = TRUE, the variable would not be deleted. Also, I'd use specific variable names, like files_version_batch_request_time to avoid collision with other modules.

• Since your module has a submenu in Configuration menu, you might consider defining a configure tag in files_version.info, like configure = /admin/config/filesversion/files-version-settings so other users can get there from the module list page.
• While your JS code doesn't use jQuery, the Coder module recommends adding jQuery as a parameter if at some point there will be some jQuery code in sync.js. Also, you can make use of the Drupal behaviors and jQuery.once() for your DOM tree scanning/manipulation. And using jQuery over vanilla JS is somewhat preffered for browser compat. Although it's not a big issue these days.
• There are a few mispelled words like 'Show Inline Diffrence' or 'be created baised' that could be fixed in order to be properly translated. There are more, those just are a few examples.
• One superminor improvement recommended by the Coder module is changing the calls to time().
• You can install Coder module to see a few other recommendations. Nothing big, only very small issues. That's why I didn't list them here.

Just a minor modification needed in files_version.install: remove the trailing slash in order for 'Configure' option to appear in module's quick links (/admin/modules), otherwise looks good, thanks.

Multiple Applications

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

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

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

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.