System administration

In Drupal, system administration is the technical work that keeps a site running: the server, PHP and database underneath it, and the updates, backups, scheduled tasks and security fixes on top. It is separate from writing content. Drupal gives administrators the admin pages and the Status report to see what state the site is in.

What system administration covers

• The hosting layer. The Status report in core lists the web server, the PHP version and extensions, the database system and its version, and the PHP memory limit.
• Software updates. Core and contributed code get new releases, and a security update is the kind to apply first. See update for the full routine.
• Scheduled tasks. Cron runs the recurring jobs, and the Status report shows when it last ran.
• Backups. Drupal.org's core update guide includes a backup step and names the Backup and Migrate module or the Drush commands drush archive:dump and drush sql:dump.
• Access control. Who may touch settings, updates and modules is decided by permissions.

Where it lives in Drupal 11

Administration pages sit under /admin, which needs the permission "Use the administration pages". The Reports section at /admin/reports needs "View site reports". Under Configuration, the System group holds Basic site settings and Cron. The required System module provides these pages. The same tasks can be done on the command line with Drush.

Example

Before a monthly update, open /admin/reports/status and clear every error and warning; the core update guide on Drupal.org has the same step. Then check the Available updates report, make a backup, and apply the update. Afterward, open the Status report again and confirm the site still reads clean. The log at /admin/reports/dblog shows recent errors when the Database Logging module is on.

Common mistakes

• Doing daily work as user 1. Core's SuperUserAccessPolicy grants user 1 every permission, whatever its roles. Work from a named account whose role carries only the permissions the task needs.
• Leaving the update script open. If $settings['update_free_access'] is TRUE in settings.php, the Status report shows an error that update.php needs no authentication. Set it back to FALSE after the update.
• Updating without a backup. A failed update with no backup leaves nothing to return to.

For marketing and content teams

You will rarely run any of this, but you depend on it. A pending update (when the Update Status module is on) or a cron job that stopped is flagged on the Status report, but only if someone reads the report. Ask who owns system administration for your site, what the maintenance windows are, and where outages are reported. If you need access to settings, ask for a personal account with a narrow role rather than an administrator login.

Sources

• Drupal.org: Getting started with Drupal administration
• Drupal.org: Updating Drupal core via Composer
• Drupal core 11.4.10: SystemRequirementsHooks, the Status report checks
• Drupal core 11.4.10: UpdateRequirements, the Update Status checks on the Status report
• Drupal core 11.4.10: SystemController, the /admin routes
• Drupal core 11.4.10: SystemInfoController, the Status report route
• Drupal core 11.4.10: system.permissions.yml
• Drupal core 11.4.10: SuperUserAccessPolicy
• Drupal core 11.4.10: UserPermissionsForm