Frank Ralf, Projektmanager und Site Builder

Drupal sandbox

Buried in the sand(box)

Creating a sandbox project

So you go about and create a sandbox project. But there are these key differences between "sandbox" and "full" projects:

  1. Sandbox project pages display an Experimental Project warning message with a yellow background.
  2. Sandbox project URLs are /sandbox/username/node-id, rather than a human-readable short name such as /project/views.
  3. You cannot create releases (downloadable files) of sandbox projects; the only way to obtain them is via Git.
  4. Sandbox projects do not appear in the Main project issue drop-down. To add an issue to a sandbox project, you must do it directly from the project's own issue queue.


What's the problem with that?

IMO this procedure causes a lot of gems (i.e. very useful modules and themes) beeing buried in the sandbox where no one will find them except other applicants which want their own sandbox project getting reviewed and promoted.

Finding a sandbox project

To engage more people to review other peoples' code this code has to be findable in the first place. As it happens to find a sandbox module which provides a certain feature (e.g. "ownership") you have to follow at least these steps:

  1. Search on
  2. Filter by module:[0]=ss_meta_type%3Amodule
  3. Set status to also include sandbox modules:[0]=bs_project_sandbox%3A[%20TO%20]&f[1]=ss_meta_type%3Amodule
  4. Only then will you find "Delayed Ownership" (which happens to be my current project in the application issue queue).

So IMO it's no wonder that it's only other applicants which stumble across sandbox modules and review them. Another way to find sandbox modules is and but I suppose that these pages are only visited by other applicants.

(NB: No sandbox module is listed on which IMHO is still far better for finding modules than

I think the main flaw of the whole review process is the fact that sandbox modules are hidden from the masses. Why not make them more prominent to engage more people in the review process?

Make sandbox projects easier to find

IMO this should involve changing most of the current features of sandbox projects (see above). Please notice that this doesn't necessarely involve changing the application process itself.

  1. Don't hide them in the attic but make them more prominent.
  2. Make "All projects" the default setting when searching for modules on In fact, a filter should be set by default to provide the largest possible result set and then be used to further narrow your search, not to broaden it.
  3. Mark them appropriately but don't give them a warning as if the code were dangerous. If for example the Media module can get away with an 7.x-2.0-unstable7 release I see no reason why the community must be protected from - mostly harmless - sandbox project. Security issues should be one of the few main concerns in a formal review process. Everything else can very well be handled by the community.
  4. Give them a human readable short name so they are more easily findable.
  5. Create releases for download so also people without any Git knowledge can test them.
  6. Show them in the Main project issue drop-down.

I don't have anything against nudging people to contribute more to Drupal but the resources should be applied where they are most useful. I contribute to quite some issues depending on problems I'm facing in current projects.

Reviews of sandbox projects should preferably done by people which have an intrinsic interest in the sandbox project features not by other applicants only doing the review to earn their bonus points to get their own project promoted.

I hope this clarifies my criticism of the review bonus in the discussion "Module Approval Process is Too Slow".


Frank Ralf - Mon, 04/08/2013 - 09:20
There's a great proposal by <a href="">Jeremy Thorson</a> to speed up the process in the <em>Code Review of Full Project Applications</em> group: <a href="">"Unplugging the On-Ramp"</a>.
Giovanni Glass - Thu, 01/31/2013 - 03:07
The process to become a module contributor is slow indeed. This is a result of a volunteer process. But I don't think the system is broken. It's there to instill coding standards and behaviors. This improves module quality and security. It also prevents spam and sub-par code that may cause security issues or data loss. Yes there are gems in sandboxes. Yes, it can be improved to bubble them higher and be more discoverable. But also, if the programmer is diligent and responsible and responsive, a module worth using will make it through the process eventually. It's a one time process of course. Programmers can also promote their code outside of the Drupal website. There are more ways than one to do it.
jthorson - Tue, 01/29/2013 - 21:00
This has long been a concern, and one with enough associated baggage and pain that even some of our most proficient catalysts and cat-herders have stepped in to try and resolve the issue, only to throw up their hands and walk away out of sheer frustration. As Ian has noted above, the number one issue with the current process is that it is volunteer driven. However, applicants see the folks doing reviews more as 'traffic cops' or 'hurdles', rather than the 'mentor' role the process was designed for, which in turn breeds a competitive atmosphere instead of a collaborative one. This make the process much less rewarding for volunteers, and drives them to look for other areas of the community which could benefit from their contribution. Another concern is that many interpret this as a 'module' approval process, rather than a 'developer' approval process ... and criticisms of the process are thus focused around achieving 'code perfection' instead of 'contributor development'. Personally, I feel we need to somehow decouple these 'module approval' and 'developer approval' aspects of the process; separating the rights to publish a single module from the 'vetted git user' right (i.e. the right to unilaterally publish all future modules); and thus allow some sort of a fast-track route out of 'sandbox' status for those that aren't interested in the long-term 'create full projects' permission. Eventually, most criticisms of today's process come down to the fact that sandbox modules are treated as second-class citizens, much as you have observed. The lack of pre-packaged tarball releases was done intentionally, for a couple of reasons. First, is the protection of the 'user who doesn't know better', which most people comment on. The second reason is also one of the main reasons that we have a developer approval process in the first place ... and is sadly one of the most often overlooked consideration in this ongoing debate. Drupal is unlike any other open-source project that I am aware of, in that the Drupal Security Team also takes on a certain accountability for community-contributed code, in addition to the core project code base. The Security team will accept, coordinate, and generate Security Advisories for any contrib project with an official release ('official' not including -alpha, -beta, or -rc). The argument is that this is one of the distinguishing factors and a key differentiator for Drupal ... but this policy would not be sustainable if we simply opened the floodgates and allowed anyone off the street to create a account, upload code, and create a fully packaged project release. Over time, we have built an certain trust with the user base that modules listed on are (somewhat) trustworthy. We are victims to our own success, and maintaining this trust and reputation has come with certain compromises in other areas. Now I'm not saying that the status quo is the 'right' answer ... the current lack of volunteerism in the queue has solidly proven otherwise. But it is all we have for the moment, until folks offer up i) an alternative, and ii) the resources to implement it. To be frank, it was the pain that I experienced bringing a project through the process that motivated me to step up and try and automate portions of it (which in turn led me to an equally neglected area which needed attention, and I now find myself maintaining the automated testing infrastructure). The challenge I see is that changing this process is not a one-man job ... we need more people who are not simply content with pointing out the flaws, and who are willing to step up, put in some hard effort, come up with alternate solutions, and implement the change that everyone seems to be asking for. Ongoing criticisms without action only serve to demotivate those who are currently involved ... whereas seeing others sharing your passion and joining in to do something about it only encourages them to work harder.
rooby - Tue, 01/29/2013 - 14:58
I agree that there are issues with the approval process, and I also agree that it is better to have people actually using your sandbox on a real site as a form of testing. In relation to finding sandboxes though, this is where it is important that your sandbox be logically named and have a decent description of what the module does. If that is the case, google is your friend. It will find sandboxes and projects, arguably better than any other way of searching.
Ian Thomas - Tue, 01/29/2013 - 14:27
This assumes that: a) Sandbox modules are ready for 3rd party use. b) Any module user is capable of reviewing a sandbox module. c) Sandbox modules are safe to use. d) Users looking to solve a problem on their site are willing to spend the time reviewing a sandbox module in order to solve that problem. a) Is quite easy to solve by only returning modules that are awaiting review. b) You're not really capable of reviewing a module unless you've at least done a bit of module development. We don't want to show half-baked work to people who know little or no php. c) You really don't want to make it any easier to trick someone into installing a malicious module - at least there is some degree of review if the author has had to graduate out of the sandbox. d) Even if I am the right person to review a sandbox project, will I be able to take the time out of my own schedule to do so and still meet my own project deadline? Will the sandbox owner even respond in time, or will I need to fork the project anyway? I think the fundamental problem is that Drupal relies too much on volunteers, and volunteers enjoy writing new code, but don't spend enough time reviewing other people's or polishing bugs that don't affect them. The only solution I see is to raise money for a paid staff to do (or at least coordinate) these less glamorous tasks.