This post discusses an antipattern I see a LOT of wikis engaging in - putting all of their sandboxing on a single page.

Instead of making a single page like User:RheingoldRiver/Sandbox or, worse, Sandbox in the mainspace, and putting every single one of your WIP experiments or code snippets on this centralized page, you should make a new page every time you have a new thing to experiment with.

You have a couple options:

• Use your user space as a sandbox - this is what I do
• Use the Project namespace as a sandbox - some wikis do this, I don’t agree with this, I think Project namespace should be for matters of wiki policy & other meta issues
• Create a dedicated namespace called Sandbox: or similar - this has the advantage over the User namespace option of allowing more collaborative sandboxing among people who lack permission to edit others’ user spaces, but is extra “infrastructure” that you don’t need to bother with if you don’t require that

Whether you pick the first or the third is up to you; you can do the second if you want, but in that case I’d make everything a subpage of Project:Sandbox/ so that you can easily find it with Special:PrefixIndex.

Why shouldn’t you use a single sandbox page?

There’s several disadvantages to using a single sandbox page for all of your experimentation.

• Such a page becomes slow to load and save - especially for people who have slower connections than you.
• Anyone helping you may have trouble realizing exactly what they’re supposed to be looking at if you link them the page, even if you link them a specific anchor. (Trust me on this one, I’m speaking from years of personal experience.)
• Global parameters such as variables might be affected by other experiments on the same page - especially if it’s a collaboratively-edited page.
  • You may not realize you’re failing to re-initialize a variable at 0, and that’s why your code is breaking.
  • More insidiously, if you don’t have egVariablesAreVolatile set to true, or if you encounter a similar issue with templates being cached after their first invocation and an extension not forcing re-parsing of them, you can run into bugs that wouldn’t occur in prod.
• Error categories will appear in relation to the entire page, and so you don’t get individualized information.
• Profiling tools like the expensive parser function count will be unhelpful.

Tools to make multiple pages convenient

You might want to keep everything on one page out of convenience - after all, this way all of your experiments are easy to locate. This isn’t necessary.

Special:PrefixIndex (that link goes to mediawiki.org) is a great tool for finding every page on the wiki that starts with a certain string. For example you could type RheingoldRiver/ and specify User (or Sandbox) as the namespace and quickly locate all of my sandbox pages.

If you’re concerned about explaining how to use sandbox pages to new users whose usernames you might not know, a valuable tool is Special:MyPage. This page is a unique redirect that will send each user to their very own user page! In fact, you can also send people to subpages of Special:MyPage, and they will be redirected to the proper subpage of their own user page. If you want to build, for example, a Discord bot that links someone to a sandbox page that they can use, you can take advantage of this redirect.

And finally, for your own convenience, remember that you can treat partial URLs with wildcards as search engines in your browser. Whenever I want to create a new sandbox page, I type loltest page_name (or replace lol with whichever wiki I want to use) into my URL bar, and I have a new subpage of Special:MyPage ready to go!

What about deleting?

If you have deletion permissions, just delete sandbox pages when you’re done with them, or once a year or so go through and catch up on deletions, or whatever.

If you’re not an admin, you might worry that having tons of sandbox pages lying around can get messy. And…that’s kinda true, they can. I would argue that the alternative is significantly messier - and you can always mark pages for deletion as needed and get an admin to help you delete every now and then.

Another option is to have a wiki admin set up a cron task that automatically deletes every user page that’s marked for deletion periodically; if user pages are protected so that only the user to whom the page belongs can edit it, then this should be safe to do, and you can freely make and delete user pages as needed. A setup like this might store to a Cargo table when pages are marked for deletion and then query on _pageNamespace to find results in the user namespace. If the result of this query is non-empty, the task has work to do.

But you can also just ignore the accruement of sandbox pages. I have a several hundred and I tend to just…not care about them. Sandbox pages are sandbox pages, they serve their purpose, and then I ignore them forever. Take full advantage of them, and don’t squish everything together!