Currently, users are allowed to create an unlimited number of "sandbox" repositories to hold experimental modules, code forks, and not-yet-published modules waiting for approval.

Once created, a sandbox project cannot be deleted. This pollutes the project namespace, as it is not possible to register a project whose name conflicts with a sandbox.

In fact, the only practical difference between sandbox projects and full projects is that the latter are allowed to have release nodes, and appear in the main project issue drop-down. See Sandbox (experimental) projects.

For this reason, many developers have resorted to using (e.g.) github for initial or experimental code development. @todo: explain why this is bad.

Many users have requested the ability to delete sandboxes that are no longer relevant or which were never intended to be promoted to full projects.

Proposed resolution

  • Users should be able to delete their own sandbox projects, which would also delete any associated issues, comments, git repos, etc.
  • A warning should be added to sandbox pages stating that any content posted there may be lost if the sandbox is deleted.
  • Sandbox names should not conflict with full project names.

dww expressed some concerns in #29, but after discussion, agreed in #46 to move forward with this proposal, and even rolled an initial (untested) patch toward this end.

Remaining tasks

The necessary code changes needs to be discussed, tested, reviewed, approved, committed, and deployed.

User interface changes

An additional "Delete" button for user sandbox projects.

API changes

Original report by Snugug

I would like to see the ability to delete projects from our Git sandboxes. This currently does not exist, but would make a very good feature to avoid clutter in projects.

#46 1077884-46.allow-delete-own-sandbox-projects.patch1.35 KBdww
PASSED: [[SimpleTest]]: [MySQL] 253 pass(es).
[ View ]


jdwfly’s picture

I second this. Since my sandbox projects aren't real projects I ought to be able to delete them when I feel like it. I've been looking for another issue about this but haven't found one.

Barrett’s picture


We should definitely be able to clean up our sandbox and purge unwanted projects.

John Pitcairn’s picture

+1 from me. I was just fooling with the sandbox capability for git-testing purposes, committed a custom module from among many I use, wasn't really intending it would get any attention, but it has.

I guess our only option at present is to delete all files, commit, and mark it obsolete/not maintained?

Josh The Geek’s picture

Title:Allow the deletion of Projects from Sandbox» Allow the deletion of sandbox projects
michaelfavia’s picture

Since were all voting, +1 and subscribe.

MasterChief’s picture

It would be great that we can delete sandbox projects!

Josh The Geek’s picture

I think that you shouldn't be able to delete sandboxes. If one contains a module that many people use, those people would be abandoned. If you really NEED to delete a sandbox, you should try in the infra queue.

Barrett’s picture

Josh The Geek, I'd argue that people shouldn't be using a sandbox module without discussing it with the author. My understanding of the point of the sandbox was that it provides a means of working on, and potentially collaborating on, a project that is not ready (and may never be ready) to become a publicly available module.

Josh The Geek’s picture

Hey, no one says you have to maintain a sandbox. One part of sandboxes is that you don't have to maintain them. If someone else comes along and wants to take over a project for you, you grant them maintainer, and you don't have to ever look at the project page again. So, instead of deleting your sandbox, or even deleting your code, I think that you should just leave the project with a note that says the project is unmaintained and if you want to become the maintainer, you can, and also mark as abandoned/obsolete.

Snugug’s picture

Josh The Geek, the counter argument to a sandbox project getting marked as abandoned instead of deleted is that they are by design free flowing projects that, if someone was really passionate about and wanted to keep going, they could start their own sandbox project for and keep alive instead of working off of a test page that the original committer doesn't want to deal with anymore. If we're going to get silly about these sorts of arguments, my freedom to clean out and remove my unwanted sandbox projects should not be trumped by someone else's want to use the experimental code I've posted there, especially when they have a perfectly good forum to keep it going if they still find it useful, their own sandbox project!

jim0203’s picture


joates’s picture


add a system warning message, to the add project page, clearly stating that sandbox projects CANNOT be deleted once created ?

nevergone’s picture

I have a sandbox project, and merging a another Drupal project.
I would delete sandbox, but i don't. :(

Webappz’s picture

+1 subscribe.

alex.a’s picture

I want to delete one of my sandbox projects, and then add it back again, because I didn't do it properly the first time. I used to maintain the project somewhere else using svn and when I put it in I did not migrate the svn history. Now that I know how to use git svn I would like to do it again properly, maintaining the previous history. Is there a way to put the old revisions back in without deleting the project?

tim.plunkett’s picture

Once per-issue repos exist, I will care much less about this, but since I've used sandboxes as a feature branch of a module I don't maintain, it'd be nice to delete it once the code is merged in.

logickal’s picture

+1 For sandbox deletion. If someone is going to use code from a sandbox project, it already comes with a fairly strong Caveat Emptor. Also, if a user has been using code from a sandbox project and that sandbox gets deleted, there's really nothing to stop them from posting it into their own sandbox, right?

marvil07’s picture

Project:The Great Git Migration» Project
Version:» 6.x-1.x-dev
Component:Workflows» Projects
Issue tags:+git phase 3

This would involve also changes drupalorg modules to remove git repo from disk, but IMHO it's a good idea to let people remove un-used stuff(aka let people help use clean).

Moving to project, where project sandboxes feature lives to ask for maintainers opinion on this.

feloescoto’s picture

+1 You should be able to delete them. They are supposed to be for testing purposes of many kinds.

Hope you can change it.

logaritmisk’s picture

+1, if you depend on a sandbox and it is removed, create your own sandbox

acouch’s picture

+ 1

Sandbox projects are by definition experimental so someone should not rely on them anyway. I recently created a sandbox to port a module to D7. That code is now in the official project so the sandbox is no longer needed and someone else would be worse off if they used it instead of the official project. Not being able to delete sandboxes would make me just want to use github for "experimental" code.

dawehner’s picture

What about deleting but keeping the repo? The user could add something like a special text file to notice that the repo isn't active anymore and you should use remote FOO

mikey_p’s picture

No, we've been over this, and we really don't want nodes and git repos to be out of sync. That said, I'd love to see this as well. I'll have to look and see where we're blocking the deletion of projects. We may have to work with that code in drupalorg if that's where it lives.

Kipp Elliott Watson’s picture

I have an internal server error on my test sandbox and I'd like to simply delete my sandbox and start over, using the same vital statistics as when I started, but I can't figure out how to do this. Is there a way to delete a sandbox and just start over?

Ben Coleman’s picture


Some of us have created sandbox projects just to get a handle on the environment, but the code is not generally useful. We should be able to delete such scrap projects.

cpliakas’s picture

Even when per-issue repos are created, it would still be nice to delete sandboxes. A working example is the Search API Facet API Integration sandbox. The integration is complex, so it helps to give multiple maintainers access to commit as well as maintain a separate issue queue for tracking issues that pertain only to the integration. If you look at the #1182614: Integrate with Facet API issue, it was really hard to track everything in one thread. Once the code is merged into Search API, the sandbox will be useless and I will want to remove it.

Huge +1 for being able to delete sandboxes, because I see myself using this workflow more an more.

Chi’s picture

We should be able to clean up our sandbox.

xlyz’s picture


dww’s picture

I'm generally -1 to this for the following reasons:

A) We normally never delete nodes on unless they're spam. Losing history is potentially bad.

B) What happens to all the issues attached to a sandbox project that's being deleted? Do those just become orphaned issues? Do we delete those, too? Now you're really getting into dangerous territory. What if you forked core into a sandbox to work on some tricky problem. I came along and posted a really thorough comment explaining some important aspect of core. Took me hours to research and compose. Then the sandbox author decides they're tired of working on this project and deletes their fork. And now my comment is gone. That sucks. Sandboxes are collaboration tools, and it's not just up to the sandbox owner to decide to destroy other people's work.

C) You can already mark projects as "Abandoned". What's wrong with just doing that when you're tired of a sandbox? The only counter-argument I've heard is that people want to clear stuff out of and the listing of their projects on their profile page (e.g. Could we just solve this by saying that projects marked with the "Abandoned" term should be excluded from those listings?

So, I'm not going to "won't fix", since clearly there's a lot of support for this. But, I'd like to hear people address my concerns before we plow forward with this.


John Pitcairn’s picture

Maybe the issue is terminology then. Maybe these shouldn't be called "sandbox" projects. If other users can comment, open issues against the project, make use of the project in live sites (fools!), clone the repository, fork it, etc, and the project owner cannot prevent that or remove any of it, then I really don't see there's all that much of a distinction between a sandbox and a "real" contrib project?

dww’s picture

See for documentation on the differences between full projects and sandbox projects.

xlyz’s picture

@dww while I still think that having disposable repositories in drupal would be a Good Thing, I can understand you point.
I would propose the following: if a user abandon a sandboxed project, the project will not be reported among the user projects in user profile contribution will move from "project the user currently mantains" to "contribution to project not mantained by %user" (see #1246598: Split "My Projects" into two lists: "Projects Maintainer of" and "Projects Contributed to"), and the user will be removed as mantainer from the project page.
And a BIG message on top of the project page like "don't use unless you know what you are doing, very bad things will happen" :)

EDIT: proposal amended, changes emphasized

Barrett’s picture

My support of the idea of removing sandboxes hadn't taken into account the related aspects dww raised. Taking those into account, just nuking them is a bad idea.

I think, though, that xlyz's suggestion would satisfy my need.

Lars Toomre’s picture

Regarding #29B - How about allowing deletion of sandbox projects where there are no issues associated with it (or no comments from anyone other than the sandbox owner)? That the sandbox owner could clean up false starts, mis-named projects, or training projects that will not be of use to the Drupal community. Those type of nodes are much like spam, no?

fietserwin’s picture

I'm a +1:

Regarding the concerns of dww (#29) my opinions are:

A) Cleaning history should be done more often. All too often, when searching the internet, or just this site, the results are utterly polluted by outdated knowledge/insights/procedures/etc. In general, I also think that people should have the right to unpublish things and that this right should prevail the interest of history keeping.
B) Deleting a project should (at first sight) indeed be a cascading delete, thus including issues, repo's, tarballs, whatever. If there are issue(-comment)s that are worth saving, they can probably be linked to another, still existing, project that apparently profited from the work done in the sandbox project.
C) Pollution of search results won't be prevented by marking things as abandoned.

Concluding: IMO concern B is valid. A possible solution to this concern of dww could be to not give sandbox owners the delete project permission but instead have them post an issue to the same queue as where they apply for full project access, so that other people can have a quick review of what would get lost. Such issues should be well documented (as applications for full project access):
- reason: e.g. 'code integrated into other project' or 'it appears that other projects exists that do the same (and more)'.
- non-severance of loss of history: '(interesting) issues are moved to the same queue as where the code moved' or 'there were no issues' or 'there were only simple bug reports'.

I know this queue has a backlog, but that should not withhold us from doing the right thing here.

pillarsdotnet’s picture


Niklas Fiekas’s picture


michaelfavia’s picture

Sandbox projects titles namespace pollute the allowable project titles because of the autocompletion features in issue reassignment i suppose. You cant name a project something if a sandbox already uses the title.

I probably wouldnt create sandboxes if i knew i couldnt delete them. They are by their nature experimental and disposable and in being so are somewhat unique on d.o. Its no skin off my back either way going forward i just probably wont use them and will use github instead for sandboxing which id rather not do.

alexpetrov’s picture


John Pitcairn’s picture

I probably wouldnt create sandboxes if i knew i couldnt delete them.

Same here. I'd probably have used more than the one I did create.

John Pitcairn’s picture

Issue summary:View changes

Add "garbage collection" proposal.

pillarsdotnet’s picture

Issue summary:View changes

added "project namespace" to the pollution issue.

pillarsdotnet’s picture

Issue summary updated.

I am going to attempt to address the concerns raised by dww:

    • We normally never delete nodes on unless they're spam. Losing history is potentially bad.

    Sure; nodes are set in stone. But would it be so bad if sandboxes were set in ... sand? If sandboxes are forever, they should be renamed diamondboxes to reflect that mindset.

    • What happens to all the issues attached to a sandbox project that's being deleted? ... it's not just up to the sandbox owner to decide to destroy other people's work.

    If a sandbox is forked from core or any other project, typically there will be a related issue attached to the parent project. That's where discussion of the tricky problem happens, not in a sandbox issue queue.

    If a sandbox is intended for later promoted to a full project, typically there will be a related project application node where such discussion happens.

    For the remaining (possibly hypothetical) cases, I think the solution would be to show a disclaimer on sandbox issue pages warning that content posted there is temporary and may be deleted at the whim of the sandbox owner. If you don't like those rules, go play in your own sandbox.

    • You can already mark projects as "Abandoned". What's wrong with just doing that when you're tired of a sandbox? ...

    Nobody is suggesting that we eliminate the "abandoned" approach in favor of deletion. If I wrote some code that I'm tired of maintaining but which may be of use to someone else, I'd still take the "abandoned" approach. But if I wrote some code which is clearly and fundamentally flawed, or which has been merged into or obsoleted by another project, or whose name should be returned to the general pool for re-use, I'd welcome the opportunity to clean up the clutter.

    I have exactly one sandbox project at the moment. It has no code, no issues, no users, no maintainers, and no purpose other than as a placeholder for a name that I may never use. I was thoroughly dismayed to discover that I cannot delete it, and so long as that remains true, I will never create another.

pillarsdotnet’s picture

Issue summary:View changes

Updated from issue summary template.

pillarsdotnet’s picture

Updated the issue summary. Also, I have an idea for compromise/resolution:

  • Rather than a "Delete" button, sandbox (and project) owners should have an "Abandon" button.
  • Clicking on the "Abandon" button should, after a warning, remove the user from the Maintainers list for that project/sandbox.
  • Ownership would automatically be granted to the most senior maintainer, if any.
  • Sandboxes or projects with zero maintainers should be marked "Abandoned/obsolete" and assigned to the "Abandoned projects" user.
  • All abandoned projects should be added to a special "Abandoned projects" page.
  • Any user who already has the "Create project" privilege should be able to claim an abandoned project, thus becoming its new owner.
  • Full projects in the "Abandoned projects" list should be automatically deleted when their latest release is no longer supported. Currently, that means if the latest core version supported by an Abandoned project is 5.x, then it should be deleted. There's no sense in carrying cruft around forever.
  • Sandbox projects in the "Abandoned projects" list should be automatically deleted after a grace period of (e.g.) six months. That gives everyone who cares a reasonable chance to rescue their pet fork/branch/feature, while allowing truly unwanted stuff to eventually disappear.
pillarsdotnet’s picture

Issue summary:View changes

Updated summary with possible resolutions/answers gleaned from the discussion.

dnotes’s picture

Just came across this thread when trying to do this. I'm still for the ability to delete sandboxes. I understand and appreciate the points in #29, but in general I agree with the counterpoints in #35 and think that they outweigh the concerns.

Specifically in regard to point B, about sandboxes used as collaboration tools: I'm wondering, firstly, how much of an edge case this is, and second, whether it could be solved at the personal level by the author simply not deleting those projects, at least not until the other collaborators have been consulted. This seems to me like an area where courtesy should be the determining principle instead of UX.

Also, is it possible on d.o to just unpublish the nodes? Then those comments could be retrieved if they were ever needed.

dnotes’s picture

Issue summary:View changes

Trivial typo correction.

pillarsdotnet’s picture

Issue summary:View changes

Updated with input from dnotes.

pillarsdotnet’s picture

Issue summary:View changes

Added MasterChief to the "should be able to delete" list. Not that voting matters...

sdboyer’s picture

I favor sandbox deletion, strongly. It is a much saner workflow - we should have disposable repos on d.o, and sandboxes were always originally intended to be that. And the deletion should be cascading to all issues. The issue raised by dww about losing a valuable comment/issue is an edge case. I'd like to think that anyone who creates a sandbox with enough interest will take the care to reassign any valuable issues before closing the sandbox. Failure to do so would generate a nontrivial social backlash, and that's really the best deterrent.

I also think that there should be *no* namespace collision issues between sandboxes and projects. This applies to my pre-migration desire that sandboxes have real shortnames, as well.

sdboyer’s picture

Issue summary:View changes

added nevergone, Webappz and jim0203 to the "+1" list.

webchick’s picture

I favor sandbox deletion, strongly. It is a much saner workflow - we should have disposable repos on d.o, and sandboxes were always originally intended to be that. And the deletion should be cascading to all issues. The issue raised by dww about losing a valuable comment/issue is an edge case. I'd like to think that anyone who creates a sandbox with enough interest will take the care to reassign any valuable issues before closing the sandbox. Failure to do so would generate a nontrivial social backlash, and that's really the best deterrent.

Yep. Agreed with all of that.

dww’s picture

Status:Active» Needs review
Issue tags:+Needs tests
new1.35 KB
PASSED: [[SimpleTest]]: [MySQL] 253 pass(es).
[ View ]

Yeah, I'm glad I raised my concerns, but they seem to have been pretty well addressed.

This patch is sort of a hack, but it probably works. I haven't yet tested at all (beyond php -l). Would be nice to add simpletests for this, too.

dww’s picture

Issue summary:View changes

Added sdboyer's input.

webchick’s picture

I've deployed this to (user/pass: drupal/drupal, then log into Drupal with bananas/bananas to test)

I gave both "Git user" and "Git vetted user" roles the permission to "delete own sandbox projects".

acouch’s picture

@webchick i tested creating and deleting a sandbox on your test site. not sure if that is what you wanted ;)

The sandbox along with issues to that sandbox are deleted.

One issue is after visiting a removed issue node you are directed to '/node/add/project-issue' with a message "Invalid project selected."

Should that redirect to a default "this issue has been removed" node?

Mac_Weber’s picture

Tested #47 webchick's website. I created and deleted a project.
I did not test git on that project

MrMaksimize’s picture

I would definitely like ++ that. I'm a perfect example - have 2 projects right now one of which i had to dump, and I can't delete it. Also, it's very helpful if you mess up with git and don't know how to fix it

Mac_Weber’s picture

Status:Needs review» Reviewed & tested by the community

@webchick performing the steps necessary to fix this ;)

tim.plunkett’s picture

Status:Reviewed & tested by the community» Needs work
+++ b/project.moduleundefined
@@ -826,7 +828,21 @@ function project_project_access($op, $node, $account) {
+      if (user_access($any_perm, $account) || (user_access($own_perm, $account) && ($account->uid == $node->uid))) {

Whenever I see mixes of || and && in a conditional, I do a doubletake. Can we get some extra parentheses around this to clarify the order of operations?

Otherwise, this looks great.

Mac_Weber’s picture

Status:Needs work» Reviewed & tested by the community

@tim.plunkett the parenthesis are already double-taking

xjm’s picture

@tim.plunkett the parenthesis are already double-taking

What? I think we've a translation issue here. However, #53 is correct in saying (I think) that the && condition is already properly wrapped in parens.

tim.plunkett’s picture

Whew, my eyes must have been crossed, it was after midnight for me. RTBC from me as well!

Mac_Weber’s picture

No problem. It was almost 4am here! =D

dww’s picture

Status:Reviewed & tested by the community» Fixed

Committed, pushed, and deployed live. The "git user" role now has the "delete own sandbox projects" permission.

Sorry for the delays here. I had actually committed this a while ago but hadn't had a chance to deploy and reconfigure permissions. Since the code just went live with another deployment I had to do, I saw this in the diff and remembered I needed to configure this.

humansky’s picture

I verified it worked....thank you!!!

daffie’s picture

It worked for me too. Thank you

Status:Fixed» Closed (fixed)
Issue tags:-Needs tests, -infrastructure

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary:View changes

Removed details that are unnecessary now that a decision has been made.