Tips for ensuring a smooth review

Last updated on
4 February 2023

When submitting your application, there are a number of things you can do to help ensure a smooth review. The list below contains a number of suggestions which, while not guaranteed to result in a successful application, should at least make your application easier to review (and thus help avoid some of the common discussions/pitfalls which can delay the review process).

Quick Tips

Application checklist

This checklist basically covers all the application points a reviewer will take care of. Resolving these common issues can be a true time saver in the application queue.

Remember to change the status of the application to Needs review

The Needs review says to the users who review the project is ready for review. If the status is still Needs work after the suggested changed have been applied, reviewers won't review the project again.
We allow users to create the application and further check the code they wrote before the reviews start. For that, the Active status is used.

Avoid including any third-party party code or images licensed with the wrong license

If your project requires the use of third party libraries, it is preferable to provide installation instructions directing the user to where they may find the library, and how to install it.
If you are including third-party libraries or images in your project, you could need to be granted an exception by the Drupal Licensing Working Group (LWG). (See Policy on 3rd party assets on Drupal.org for more details.) Exception requests should be posted in the LWG's issue queue using Exception Request as Component field value. If you are including third-party material in your project, just must provide a link in your application post to the issue in the LWG's issue queue where the exception grant is on public display.

Search for similar modules, and explain how your application is different

This demonstrates that you have taken the time to look for existing solutions, and you are aware of the Drupal's collaboration over competition ethos.
If you do find existing modules which are similar or related to the functionality of your project (even if only in name), expect reviewers to suggest providing your module as a feature or patch to the existing project. Be sure you've read the information given in that link, and include your reasoning for the new module approach in your application.

Pre-test the code for XSS vulnerabilities

If you're not sanitizing values entered by the user when they are rendered in the page, chances are that your code is vulnerable.
Try entering <script> alert('xss!'); </script> into every text field used to ask for user input in your module, and browse around looking for popups.

Translate strings that are shown in the user interface and use placeholders for dynamic values

With few well-documented exceptions, strings shown in the user interface needs to be translated. Use placeholders for the dynamic part of the string (for example, the display name of the logged-in user) and avoid concatenating strings.

Include some information about your background and experience with Drupal in your application

Providing background information gives reviewers some extra context which they can use while reviewing your application. This also allows them to tailor feedback to the experience level of the applicant, providing additional links and background to applicants who are less familiar with the "Drupal" way of doing things.

Chip in while you wait

Unfortunately, the application queue does occasionally experience a large backlog; applications may sit in the queue for a few weeks at a time before getting reviewed. While you wait, consider joining the Code Review Group and contributing a few reviews of your own. Providing a solid review of another user's work can help demonstrate your understanding of the code review principles. Some reviewers may be willing to help fast-track your own application when they see you chipping in.

Common Issues

Module submission reviews have pulled up a number of similar problems. The list has grown to almost become a project application FAQ, containing the most common comments made after a review. Addressing each of these in advance will almost certainly help your chances of a successful application.

Incomplete submission

Many people write good motivation messages and then mess it up right at the end with here's a link to my contribution, it's about 75% done. Please, when applying, supply code that you believe is complete. Attempting to review uncompleted work is difficult and time consuming. Reviewing completed work is much simpler as there is already a level of expectation in the reviewer. Try to make our job of reviewing your work a joy.

Your project contains non-secure code

Your code is outputting user-submitted content without first sanitizing it
No piece of user-submitted content should ever be placed as-is into HTML/XML markup. User-submitted content that is saved doesn't need to be sanitized; that is only done when it's output in a page containing markup (including XML).
Your code doesn't use the proper database access functions, or concatenate data directly into SQL queries
The access to the database should be done through the database access functions. (For Drupal 7, see Database access.)
For example, sing code like db_query('SELECT * FROM {table} t WHERE t.name = ' . $_GET['user']), in Drupal 7, is an open gate to security issues: The content of $_GET['user'] could be ' OR 1, which would cause the query to show all the rows contained in the table.
Your code has a lot of string literals shown in the user interface, but they aren't translated
Every string used in the user interface needs to be translated. The system adopted to translate strings uses a script that collects the strings passed to the translation function/method and puts them in a template file that will be used (directly, or through the translation server, such as the one running on http://localize.drupal.org) to create the translation files. That is why the first argument of the translation function/method must be a literal string containing English words, but not containing quote escapes.
Your code allows a user to insert PHP code, but it doesn't provide a specific permission users must have in order to use PHP code
Using eval() or Drupal functions that call eval() in your module's code could have a security risk if the PHP input provided to the function contains malicious code. Even in the case a user needs to have an administrative permission to use PHP code, it is better to have a more specific permission to use PHP code.
Drupal 7 uses a more generic permission (use PHP for settings) that should be used from any module that allows users to use PHP code in their settings pages.

For an example of currently used code used by Drupal 7, see what the Block module does in block_permission(), and block_admin_configure().

Your project shows no hint of coding standards

Although sticking hard and fast to the standards is not an absolute requirement, plain sloppy and poorly presented code is not accepted. Try to follow the standard if at all possible and try to make the code clean and readable. If a reviewer is having a hard time reading your code it is likely that a number of other people will too. Remember, by placing your code on drupal.org you are letting the World see your code. Impress people not only with its awesome functionality but the quality of coding too!
To easily find where the code does not follow the Drupal coding standards, you can use an automated tool: Install and run PHP_CodeSniffer with Coder.

Your project should cooperate with other project

In particular:
  • Two projects should not define the same permission. When a permission is already defined from a project, other projects do not need to define it; they should just use it. That is true whenever the permission is defined from a Drupal core module, or a third-party module.
  • When a project alters a database table defined from another project, it should also implement hook_schema_alter(), in order to allow the other projects to correctly work.
  • If a project depends from a database table defined from another project, it should declare its dependency from the other project rather than creating the database table when the other project is not installed.
  • Each project should respect its own namespace, and correctly name the functions, global variables, Drupal variables, and constants it defines.

Your project outputs a lot of HTML markup but there's not a theme function other projects can override

Those people around the world who theme really won't be your friend if they would need to use your project.

Help improve this page

Page status: No known problems

You can: