Reassigning super-user content in Drupal 7

Drupal site showcase poster (2012)

I am number one

As with the root user on Unix/Linux systems, user ID 1 (UID 1) in the Drupal content management system is the site maintenance account, intended for performing system administration tasks.

The site maintenance account behaves differently to other accounts, including those belonging to the administrator role:

  • All site permissions are ignored. For example, if the core Statistics module was enabled, but the "View content hits" permission was not assigned to any roles, content hits are still displayed for UID 1.

  • Nothing is cached. Content produced by the site for UID 1 is excluded from any and all caching. While some non-core modules can be instructed to cache for UID 1 (e.g. Authcache), this is not recommended and not enabled by default.

For security and performance reasons, UID 1 should not be used as an everyday account.

The situation

The user account created during installation of a Drupal 7 site - in both the standard and minimal installation profiles - is assigned UID 1.

Best practice in site building is to use a clear, unambiguous username (e.g. "superuser") and assign a strong password. A second user account is then created and assigned the administrator role, which is used to continue with site building tasks.

An example

Taken from real-life, the primary administrator and contributor of a client's Drupal site had been using UID 1 as an everyday account for over a year, unaware of the security and performance implications. As the contributor had built a community with this identity, the requirement was to transfer node and comment authorship/history from UID 1 to another account.

The site was using MySQL for database storage, along with these Drupal modules:

At this point, a backup of the database used by the Drupal site was made. The site was also placed in maintenance mode (/admin/config/development/maintenance) for the duration of changes.

The target

A new user account ("joebrown") was created with the contributor's identity (name, profile photo, signature) and assigned the administrator role; content previously created using the site maintenance account will be reassigned to this account.

At the same time, the user profile of UID 1 was modified to remove its previous identity and its username changed to "superuser".

  • If the popular Pathauto and Redirect modules are enabled, confirm that created aliases/redirects are appropriate for these identities, by visiting /admin/config/search/path and /admin/config/search/redirect respectively.

Using the MySQL SQL shell (mysql), connect to the Drupal database. For example:

$ mysql -u drupal7 -p mysite

The user ID of the target account is required, which can be determined by querying the users table:

mysql> SELECT uid, name FROM users WHERE name = 'joebrown';
| uid | name     |
| 716 | joebrown |
1 row in set (0.00 sec)

As above, 716 is our target user.

Reassigning content

For the modules used on the client's Drupal site, the following tables were required to be modified:

  • node
  • comment
  • file_managed
  • node_revision
  • workbench_moderation_node_history
  • pm_message
  • pm_index
  • node_comment_statistics

As other Drupal modules may record UIDs during their operation, additional tables not listed above may also require adjustment.


This table contains details of node authorship:

mysql> UPDATE node SET uid = 716 WHERE uid = 1;


This table contains details of comment authorship:

mysql> UPDATE comment SET uid = 716 WHERE uid = 1;


This table contains details of file/media authorship:

mysql> UPDATE file_managed SET uid = 716 WHERE uid = 1;

node_revision / workbench_moderation_node_history

These tables are used by Drupal core and the Workbench Moderation module to record details of node changes (as revisions):

mysql> UPDATE node_revision SET uid = 716 WHERE uid = 1;
mysql> UPDATE workbench_moderation_node_history SET uid = 716 WHERE uid = 1;

pm_message / pm_index

These tables are used to record the author and recipient of private messages:

mysql> UPDATE pm_message SET author = 716 WHERE author = 1;
mysql> UPDATE pm_index SET recipient = 716 WHERE recipient = 1;


This table is used by Advanced Forum (and the core Forum module) to provide details on the last comment of a forum topic:

mysql> UPDATE node_comment_statistics SET last_comment_uid = 716 WHERE last_comment_uid = 1;

Final steps

Clearing out Drupal's caches (/admin/config/development/performance) was necessary to apply all changes throughout the site.

Previously authored content was now assigned to the target account. Use of UID 1 could now be limited to only where necessary.

Drupal is a registered trademark of Dries Buytaert.

Last updated: 
2015-12-03 23:25

Add new comment