[D7] Disable Resizable Textarea

Git clone command for the sandbox is missing in the issue summary, please add it.

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.

Automated Review

PAReview reported some issues. IMHO, these are not substantial, and fixing all issues is not a requirement for getting through the application process, but these should be trivial to fix.

Manual Review

Individual user account

Yes: tregismoreira follows the guidelines for individual user accounts.

No duplication

Yes.

Googling for drupal remove textarea resize does not find an existing module that does this. The SERP also indicates that it is an often requested feature. The applicants solution differs from the many solutions already posted on web (typical example at Drupal.SE) by allowing the admin to disable per field.

Master Branch

No.

It appears you are working in the "master" 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.

Licensing

Yes: Follows the licensing requirements

3rd party code/content

Yes: Follows the guidelines for 3rd party code.

Project page

No.

I find the project's name counterintuitive. It must be named something that reveals its function. e.g. "Disable Resizable".

Also: Please take a moment to make your project page follow tips for a great project page..

README.txt

No: Please take a moment to make your README.txt follow the guidelines for in-project documentation and the README.txt Template.

Code long/complex enough for review

No, it does not follow the guidelines for project length and complexity.

The project is only 45 lines of PHP code (after stripping comments and blanks), it has no permissions on its own, no interaction with the database and only implements a few hooks.
However, it implements a requested feature, and I am sure there a lot of Drupal webmasters that prefer to use a checkbox instead of creating a small custom module or modify templates to have this feature.
IMHO, a larger and more complex project should have been submitted for review for the "Create Full Projects" permission access. (But I shall leave it to a more senior reviewer to make a final call on this.)

Secure code

Yes: Follows guidelines for writing secure code. (There isn't much to review, but I didn't find anything wrong with the code submitted.)

Coding style & Drupal API usage

There isn't much to review, but I didn't find anything wrong with the code submitted.

There is no hook_help(). It is good practice to display a brief help text under the help menu in the admin bar for every enabled module, but this is not a blocker.

There are IMHO no blockers, so I am moving to RTBC. Note that promotion will not happen until a git administrator has given this a second set of eyeballs.
Also note that I doubt this project meets the criteria for "Create Full Projects" permission.

Forgot to change status.

I tried to solve the reported issues, but could not. Do you have any tips?

FILE: /var/www/drupal-7-pareview/pareview_temp/README.txt
--------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
--------------------------------------------------------------------------------
 46 | ERROR | Files must end in a single new line character
--------------------------------------------------------------------------------

The last character in your README.txt is a space character, not a new line.
Delete the space, then add a new line.

FILE: /var/www/drupal-7-pareview/pareview_temp/resizable.module
--------------------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 1 LINE
--------------------------------------------------------------------------------
 86 | ERROR | Type hint "array" missing for $element
 86 | ERROR | Type hint "array" missing for $ms_elements
--------------------------------------------------------------------------------

Insert the missing type hints, like this.

function _resizable_children(array &$element, array $ms_elements) {

What about Resizable Textarea?

Make that "Disable Resizable Textarea". Your module does not provide a Resizable Textanarea. It disables it. The word "Disable" should be part of the name.

Adding tag

You have to wait for a git administrator to approve it. (I am not a git administrator.)

Automated Review

There is still a master branch, make sure to set the correct default branch: http://drupal.org/node/1659588 . Then remove the master branch, see also step 6 and 7 in http://drupal.org/node/1127732

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

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.

Master Branch

No: Doesn't follow the guidelines for master branch.

Licensing

Yes: Follows the licensing requirements

3rd party code

Yes: Follows the guidelines for 3rd party code.

README.txt

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

Code long/complex enough for review

No: Doesn't follow the guidelines for project length and complexity.

Secure code

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

Coding style & Drupal API usage

The README should be a little more clear that this will disable the grippies by default, that users needs to disable the functionality where desired.

You have the 7.x-1.x branch, but you also need to delete master. Read through the two links in the final review again.

I don't really have any substantial comments about this module. It does what it advertises, and it does it the proper way.

It does fall fairly short of the 5 function / 120 line guideline, though. Once the master branch is taken care of, I am happy to do a single project promotion with this, but then @tregismoreira
would have to go through this again for vetted access.

@tregismoreira, did you investigate this for FAPI #textarea fields yet? Adding support for that would probably bring it over the line requirement.
If it was close, and done well, I don't see a problem with vetted access then (it would be a good, comprehensive addition to the module space).

Let me know how you want to proceed.

Thanks for cleaning up the master branch.

Understood about FAPI #textarea fields. Because of the project length / complexity, I would do what gets called single project promotion, which does not give vetted git access (you won't be able to make full modules unless you do another project application).

If you want to add support for FAPI #textarea fields, that would bring the length / complexity requirement up to the point where we can do vetted access. But, you would have to do that before I do the single project promotion and close out this application.

I am only asking because I want to be sure you understand the difference, and don't want you to have to go through another application if your final goal is git vetted access.

One of the requirements for getting git vetted access is having a module that is "complex" enough. The general guideline is 5 functions and 120 lines of code. Your currently falls fairly short.

Adding FAPI support would bring the complexity up. Adding other features would, too, but I think that this would be the easiest thing for you to add and I also think it is the best improvement for the module.

I just verified that we can do single project promotion now, and if you add some features we can use those for vetted access.

Assigning to myself for promotion, and then we can work on the vetted access details.

So when I deploy this improvements, should I report at this same application?

Yes. The "PAReview: Single project promote" tag will be removed by mpdonadio when the project is considered large/complex enough for getting git vetted access.

(I see that you've added hook_help() now. I appreciate that.)

Thanks for your contribution, tregismoreira!

I promoted this to a full project. If you add some features to this that will bring up the complexity a bit, we can reevaluate it to grant git vetted access. If you do this, change the status on this to Needs Review, and leave a comment as to what you added.

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.

Multiple Applications

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

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

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

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.

tregismoreira wrote:

Unfortunately I still have not received permission to create full projects. So I need to create various applications. Maybe I will create another application this week...

I am not the final judge of these things, but piling on one itsy-bitsy project after another that all just implements different variants of hook_form_alter() to disable various form elements may not be your best strategy to gain permission to create full projects.

The guidelines require projects to be complex enough to demonstrate a working knowledge of the API, security, etc. - and none of the projects you've started so far seems to have the any degree of complexity.

I think you need to re-read #21 above and reconsider your options.

I'll add this to my queue.

Multiple Applications

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

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

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

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

Review of the 7.x-1.x (e6d1d0d) branch came up clean for me.

Manual Review

Promoted git commit was d989aa0. git diff d989aa0..HEAD shows enough additions (a setting page is added, as well as support for textareas w/ summaries) to bring up the complexity to proceed with application for vetted access.

In disable_resizable_textarea_menu(), the $item type isn't needed as that is the default.

In disable_resizable_textarea_process_textarea(), the variable_get() should have a default value.

(+) Your admin form should use the system_settings_form() functionality. See https://www.drupal.org/node/206761

Personally, I would make the admin an option a radio, to either enable at once, disable at once, or defer to individual configurations.

The (+) items are things that should be addressed before a stable release. The rest are recomendations.

I am not seeing any blocking issues on this. Assigning to @heddn for a second look, if he has time.

Nit: spelling of property.

/**
 * Recursively reset the #resizable propertiy to the elements of a form.
 *
 */
function _disable_resizable_textarea_children(array &$element, array $instances) {

Nit: plural textareas is better grammar.

function disable_resizable_textarea_form($form, &$form_state) {
..
    '#title' => t('Disable #resizable property of all textarea at once'),

This can use system_settings_form and avoid the use of a submit handler.
disable_resizable_textarea_form()

However, none of these are blockers so...

Thanks for your contribution, tregismoreira!

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.