Last updated November 18, 2014.

This page lists some guidelines for Webmasters on

Unpublishing vs deleting of content

You should only unpublish a post if you can conceivably imagine it being re-published in the future. This should only be for very rare cases. A good example is an unmaintained project (someone might take over development later): unpublish, don't delete. On the other hand, spam can be deleted immediately.

Content that is outdated by another page should also be unpublished with a comment in the revision log linked to the newer page. After some time goes by, it can be reviewed again and deleted.

Blocking vs deleting of users

Deleting users is a very destructive action, as it makes all their content inaccessible in most places, even to administrators. It should not be done. If a user is a troublemaker, just block their account (click username -> edit -> status: blocked). Of course, you should not block people just because they say unfavorable things about Drupal. Here are good reasons to block someone:

  • Spamming (even once)
  • Repetitive flaming
  • Repetitive posting of trash content (test posts, inappropriate book pages, ...)
  • File a webmasters' issue with a link to the user name for the site admins to block more easily

Blocked users who request access

If a user requests their account unblocked, and there are no issues filed in the queues, and their profile, nodes or comments don't give any indication of spam or trolling behavior, their account can be unblocked and an issue filed in the Webmaster queue if one does not exist.

Badly formatted posts

If you see a post with bad formatting which messes up the page's layout, please edit it. A common mistake for newbies is to use two opening tags rather than an opening/closing pair. Tags like bold and italic can 'bleed through' beyond the post, while unclosed block-level tags can mess up the positioning of the sidebar.

If someone made a serious mistake while posting a forum topic and posted a correction in a comment below, try to update the original post and delete the correction.

Select the revision tag and note in the log as well.

Duplicate posts

If you see duplicate posts in multiple forums, choose the best forum and remove the remaining duplicates unless they already have responses. If they already have comments, make a polite note about duplicate posts referencing the other.

Projects without code

It is longstanding policy that we require that projects on have releases present on This means using's git installation to push code there and using the release mechanism to create tarballs for download from This is also a requirement of the security team to review any security flaws that should be reported to the team.

If you encounter a project that does not meet this requirement some time after creation or ceases to provide its current code on, please ask the maintainer to change this by creating an issue in the project's issue queue. If no action is taken by them within a reasonable timeframe, move the issue to the webmasters' queue.

Suggested Courses of Action

When you spot something out of the ordinary, we suggest these steps:

  1. Take a look at the user's post history on the "user -> track -> track posts" page. This will possibly show more bad posts by the same person.
  2. Take a look at the user's page visit history on the "user -> track -> track page visits" page. That way, you can easily tell if a user just registered to spam or if they made only one bad post in a series of good ones.
  3. If the content is spam or off-topic, you can delete it immediately and block the person's account. Otherwise, send them a note through their contact tab about it:

    Your post Foobar on was inappropriate because it contained flaming. Please be nice to your fellow visitors on, or your account may be blocked.

  4. If you know someone to be a troublemaker who has been warned before, block their account.
  5. When possible, file an issue against the webmasters project with a brief reason so others will know why an account was blocked. If you blocked the account, then please close the issue as well.

Dealing with Module, Themes and Distribution pages

If you find a problem with a module, theme or distribution page, don't edit the project yourself. Instead, create an issue in that project's issue queue to discuss the changes with the project's maintainers. If you believe the problem is in violation of a policy and the maintainer doesn't make the changes, then move the issue to the Webmaster issue queue so other webmasters discuss and propose changes.

Document Your Actions: Queue or Revision Log

When you've made a major change to the site, it's good to keep track of it. If you are editing a node, just use the "Log message" field and be sure that the "Create new revision" checkbox is on. If you are adding/removing/modifying user accounts or Planet Drupal content, you should also document the action in the webmasters issue queue. If you edit a comment, just add [edited by {yourname} because...] and provide the reason for the change.