Why teams implement the Gin admin theme for Drupal editors
Gin is a redesigned admin theme for Drupal that is built on Claro, the core administration theme, and adds features such as dark mode. Teams implement it when editors spend long sessions in the content and configuration screens and the default admin interface slows their work, or when a platform team wants a modern authoring experience on a Drupal 11 or 12 site. The current 5.0.16 release requires Drupal ^11.2, so a site still on an older core line needs a core upgrade before Gin can be installed. Platform teams should confirm the required core constraint in the release notes on the Gin project page before they add it to a build.
Gin is a contributed theme hosted on Drupal.org, and it is licensed under GPL-2.0-or-later, the same license that covers Drupal core. That means no license fee applies to the theme itself, and the cost of adoption lies in planning, testing, configuration and ongoing maintenance. Drupal.org reports that about 147,216 sites use Gin. Treat that figure as a signal of adoption rather than a quality guarantee, and check the project's issue queue, maintenance status and compatibility with your installed modules before you commit. The reader should also ask whether any custom or contributed admin forms need styling checks, since a theme change touches every back-end screen editors use.
The longer planning question is Claro's lifecycle. Claro is deprecated in Drupal 11.5.0 and removed from Drupal 12.0.0, and sites are expected to move to the new Default Admin theme or the contributed Claro theme. Because Gin depends on Claro, a team that adopts Gin should record which theme it will rely on after Claro is removed and confirm that the chosen path is supported on its target core version. Drupal 12 is scheduled for the week of December 7, 2026, according to the core release schedule, so the decision should be made before the upgrade window opens, not during it. Ask your implementation partner to include an admin theme review in the upgrade test plan.
What the Gin theme changes for authors and administrators
Gin changes the administrative interface that editors and site builders work in, but it sits on top of the same content model, permissions and configuration. The cards below separate what the theme alters from what it leaves untouched, so the decision is made on the actual scope of change.
The redesigned admin interface
Gin replaces the default Claro look with a redesigned set of forms, tables, toolbars and navigation for the content and configuration screens. Authors see the new layout on node add and edit forms, the content overview and the media library, while site builders see it across the configuration pages. Because the layout changes on every screen, plan a short walkthrough with a few real editors before rollout so that any workflow they depend on is confirmed in the new layout. Check the full feature list on the project page before committing, since the set of options changes between releases.
Dark mode and display options
Dark mode is one of the features Gin documents, and it is a per-user display choice rather than a site-wide setting. Editors who work long shifts or prefer high contrast can select it in their own account settings. Accessibility review still applies: confirm that the contrast, focus indicators and status colors used by Gin meet the standard your organization targets, and test them with the keyboard and a screen reader rather than relying on the theme's appearance alone.
Claro as the foundation
Gin is built on Claro, the core administrative theme, so it inherits Claro's markup and templates and extends them with its own styles and templates. Any custom admin templates or overrides you already maintain should be reviewed against both themes. Confirm how the Gin release you choose depends on Claro for the Drupal version you run, because that dependency drives the plan for the Claro deprecation covered later in this topic.
Content types and fields stay the same
Gin does not change how content types, fields, view modes or taxonomy are modeled. Field definitions, widget choices and form display settings remain in configuration and are rendered by the theme. A content model that works today will work after the switch, but the field groups and widget layouts may look different, so review any long forms with many fields or Paragraphs widgets for spacing and tab behavior. Changes to the theme should not require changes to the content model.
Roles and permissions stay the same
Access to admin pages is still controlled by the permissions assigned to each role. Installing Gin does not grant or remove any permission, so editors who could not reach a page before will not reach it afterward. Review the permissions that the theme's settings page exposes, if any, and confirm that only administrators can change the theme configuration. Check the role matrix in a staging environment with test accounts for each role before release.
Theme configuration and deployment
Gin settings such as default theme choice and display options are stored as configuration, so they move through your normal export and import process. Confirm that the active theme and its settings are exported in the same release as the code that depends on them, and that the theme is installed through Composer so that its version is pinned in the lock file. Test the deployment in a non-production environment before it reaches editors.
Choosing between Gin, Claro and the new Default Admin theme
This table compares the three admin theme paths a team weighs for editor experience: staying on Claro through its deprecation, adopting Gin on Drupal 11.2 or later, and moving to the new Default Admin theme or the contributed Claro theme. Read each row against your Drupal version and upgrade calendar, because the deprecation and removal dates decide how long each path remains safe.
| Option | When it fits | What it depends on and what to verify |
|---|---|---|
| Stay on Claro | Sites that need no visual change for editors and can complete the next core upgrade on schedule | Claro is deprecated in Drupal 11.5.0 and removed in Drupal 12.0.0. Confirm the Drupal version you target and whether any custom admin templates override Claro. |
| Adopt Gin | Teams on Drupal 11.2 or later that want dark mode and a redesigned editor interface built on Claro | Gin 5.0.16 requires Drupal ^11.2. Verify the Gin release against your exact core version, test contrib modules that add admin forms, and confirm your accessibility review covers the new styling. |
| Move to the new Default Admin theme | Sites planning for Drupal 11.5.0 and later that want the core-maintained successor to Claro | Sites are expected to move to this theme once Claro is deprecated. Confirm its availability and feature parity with your current admin customizations before committing to a date. |
| Move to the contributed Claro theme | Sites that need Claro's look and behavior after core removes it in Drupal 12.0.0 | Depends on a maintained contributed release for your target core version. Check the project's compatibility notes and who maintains it before relying on it for the long term. |
| Plan for Drupal 12.0.0 | Every site, because removal is scheduled for the Drupal 12 release line | Drupal 12 is scheduled for the week of December 7, 2026, and requires PHP 8.5 or later. Inventory custom admin theme code now, since it will need rework on any path. |
| Estimate the editor-facing change | Teams deciding how much training and testing the switch needs | Editors see new layouts and controls on any theme change. Ask your partner to scope a test pass with real editorial tasks such as content moderation, media and bulk operations. |
| Custom admin theme overrides | Sites with subthemes or templates that extend Claro | Overrides break when the base theme changes. Audit them early, because a switch to Gin, the Default Admin theme or a contributed Claro release can each require changes. |
How a Gin rollout proceeds from audit to editor sign-off
The sequence moves a Gin rollout from a confirmed Drupal and PHP baseline through a tested staging build to a released admin theme that editors have approved. Each step leaves a written record, so the change can be reviewed, repeated and rolled back.
Confirm the Drupal and PHP baseline
Record the Drupal core version, the PHP version, the database and the web server in use, then compare them with what the Gin release requires. The Gin 5.0.16 release requires Drupal ^11.2, so sites on older core need an upgrade plan before any theme work starts. The output is a compatibility record that names each requirement, its current value and the owner who signed it off.
Inventory custom admin templates and overrides
List every custom theme template, library, and contributed module that alters admin routes or depends on Claro's markup, libraries or regions. Include Claro subthemes and any admin pages that editors rely on for daily work. The output is an override inventory with each item marked as keep, rebuild or retire, which becomes the input to the staging build.
Plan the Claro deprecation path
Confirm which admin theme the site will use after Claro's deprecation in Drupal 11.5.0 and removal in Drupal 12.0.0, either the new Default Admin theme or the contributed Claro theme. Decide whether Gin remains the editor-facing theme on the target version. The output is a short decision record with the chosen theme, the reason for it and the Drupal version at which the decision will be reviewed.
Install and configure Gin in staging
Install Gin on a copy of production built from the same code and configuration, then apply the theme settings such as dark mode and layout options. Rebuild any override from the inventory as a custom subtheme rather than editing Gin's files. The output is a working staging build and a theme configuration exported to version control, so the settings can be reviewed and reproduced.
Test editor workflows on the staging build
Run scripted editor tasks on staging, including creating and editing content, using media and paragraph widgets, moderating content, managing menus and working with views. Test with accounts that carry the roles editors actually hold, and check keyboard and screen reader use of the admin forms. The output is a test log with each task, its result and any defects logged against the override inventory.
Obtain sign-off from content leads
Walk content leads through the staging build and the test log, then ask them to approve or reject the changes in writing. Record any open defects and agree which are blocking before release. The output is a signed approval record that names each lead, the build reviewed and the date of sign-off.
Release with editor training and a rollback plan
Deploy the approved configuration to production through the same pipeline used for staging, then confirm that the theme settings match the version-controlled export. Deliver short training on the changed screens and publish a note on where to report problems. Keep the previous theme configuration available for a rollback. The output is a release record showing the deployed version, the training held and the rollback steps tested on staging.
Planning for Claro's deprecation in Drupal 11.5 and removal in Drupal 12
Treat the Claro timeline as a planned migration with a fixed end date, not a cleanup item for the release before launch. Claro is deprecated in Drupal 11.5.0 and removed from Drupal 12.0.0, and sites are expected to move to the new Default Admin theme or the contributed Claro theme. Gin sits on top of Claro, so a site that adopts Gin inherits its dependency on Claro's lifecycle. Editors who have learned Gin's dark mode, layout and forms will notice any change to the admin surface, so the switch needs its own test cycle, editor sign-off and communication window. Build it into the roadmap as a dated work item with an owner.
The removal date depends on Drupal 12, which the core release schedule places in the week of December 7, 2026. Drupal 12 also requires PHP 8.5 or later, according to the Drupal.org PHP requirements page, while Drupal 11 requires PHP 8.3 or later. A team that plans to move to Drupal 12 must therefore check its hosting image, PHP runtime, Composer constraints and every contributed module against both the PHP version and the new core. Confirm on the Drupal core release schedule page whether the Drupal 12 date still holds before you commit to a target, because a slip changes the order of work. Also check whether your current Gin release supports the Drupal version you plan to run.
Before choosing a target, confirm three things on the Drupal.org deprecated and obsolete extensions page and the Gin project page: the exact Drupal version in which Claro is deprecated and removed, which admin theme Drupal recommends as the replacement, and whether Gin's roadmap includes support for that replacement. Then choose between the new Default Admin theme and the contributed Claro theme based on your custom theme overrides, accessibility testing results and how much of the Gin look your editors need to keep. Record the decision, the test environment and the editor acceptance criteria so the switch does not depend on one person's memory when the deadline arrives.
What drives the effort of a Gin implementation
This table lists the factors that raise or lower the effort of a Gin rollout and how to keep each one under control. Read it to find which drivers apply to your site, then ask a partner to price each one separately in the written scope. The main takeaway is that most effort comes from overrides and customizations rather than from installing the theme itself.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Custom admin templates and overrides | Each overridden Twig template or form display must be checked against every Gin release and against Claro's successor. | Keep all admin overrides in one custom theme or library, and document each one with the template it replaces. |
| Contributed modules that alter admin forms | Modules that add fields, tabs or widgets to admin forms can render differently under Gin and need individual testing. | Audit the admin forms of each module before the build, and remove or replace modules that only add cosmetic changes. |
| Number of content types and fields | More content types, long field lists and nested paragraphs make the edit forms harder to review and style consistently. | Use Gin's form layout settings on shared display modes and limit the number of distinct edit form layouts. |
| Editorial workflows and moderation states | Content Moderation transitions, Workspaces and custom buttons add states that editors must see clearly in the interface. | Map each workflow state to one visible label and color, and test the sequence with real editor roles before launch. |
| Brand and theme customization | Brand colors, logos, fonts and dark mode adjustments add custom CSS that must be kept in step with upgrades. | Set brand values through the theme settings where possible, and cap custom CSS to a defined set of files. |
| Accessibility testing scope | Admin interfaces must work for editors with assistive technology, and contrast changes in custom CSS can break that. | Agree the WCAG level and the pages to test in writing, and test custom overrides against the same checks. |
| Current Drupal version and upgrade path | Gin 5.0.16 requires Drupal ^11.2, so a Drupal 10 site must upgrade before Gin can be installed. | Confirm the Drupal version first, and plan the core upgrade as a separate, scoped piece of work. |
How the work differs for new sites, upgraded sites and Drupal 7 migrations
When a new site is built on Drupal 11, Gin can be chosen at the start and the editor experience designed around it. There is no existing admin theme to replace, so the work centers on selecting the theme, setting its options and deciding how it fits the content model. Gin 5.0.16 requires Drupal ^11.2, so the installed core version must be checked against that constraint before the theme is added to the build.
- Version constraint check: Confirm the Drupal core version in
composer.jsonsatisfies the Gin release's requirement before adding the theme to the build. - Early editor testing: Review the content forms, media library and dashboard with real editors while the content model is still changing, because field layout changes are cheaper now.
- Configuration in version control: Store the theme settings and any custom CSS or Twig overrides in configuration and code, so they deploy through the same pipeline as the rest of the site.
- Claro planning: Record in the project plan that Claro is deprecated in Drupal 11.5.0 and removed in Drupal 12.0.0, and decide early which admin theme the site will use after that point.
- Testing scope: Include admin forms, bulk operations and accessibility checks in the acceptance tests, not only the public front end.
Before starting, ask your team to confirm the target Drupal core version and the date each environment will be updated.
An existing Drupal 10 or 11 site usually already runs Claro or a customized admin theme. Adding Gin is a change to an interface that editors use every day, so the work is mostly about compatibility, rollout and rollback. The site's custom admin theme, contributed modules that add admin forms and any custom CSS are the parts most likely to break after the switch.
- Compatibility audit: Check contributed modules and custom admin templates for markup or CSS that depends on Claro, and list the forms that need visual review.
- Staged rollout: Enable the theme on a staging copy with a recent database, then test editor roles one by one before production.
- Rollback path: Keep the previous admin theme enabled and documented so the default can be restored by configuration if editors report blocking problems.
- Custom overrides: Move any sub-theme or CSS overrides that target Claro selectors to Gin equivalents and retest them.
- Editor communication: Plan a short guide for dark mode, changed menus and any relocated actions, since editors notice layout changes first.
Confirm the current Drupal core version, because Gin 5.0.16 requires Drupal 11.2 or later, and a Drupal 10 site would need a core upgrade before the theme can be installed.
Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. They are migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and themes must be rebuilt because they cannot be migrated. Gin is therefore configured in the new site rather than carried over from the old one, and the admin experience is part of the rebuild scope.
- New site first: Build the Drupal 11 target with Gin enabled, then map content, users and configuration into it.
- Theme rebuild: Treat the old front-end and admin theme as a rebuild item, with its templates and CSS reviewed against the new content model.
- Editor workflows in scope: Include the editorial tasks that existed on the old site, such as review, bulk actions and media handling, in the acceptance tests for the new admin interface.
- Security exposure: Drupal 7 security support ended on January 5, 2025, so a migration may need an interim support arrangement with an extended security provider while the rebuild is underway.
- Migration rehearsal: Run the migration more than once against copies of the source data and check that editors can complete their tasks in Gin afterward.
Ask your migration partner to confirm which Drupal 7 modules have no Drupal 11 equivalent, because those features will need custom work before the admin experience can be finished.
How the Gin theme connects to other parts of the Drupal platform
Gin changes how editors see the admin interface, but it sits on top of many site features that carry their own screens and settings. The cards below cover the connections that most often need checking before an admin theme change reaches editors.
Content Moderation and Workflows screens
Review queues, moderation state selectors and transition buttons are rendered by core admin templates that Gin restyles. Editors approving content depend on those controls being legible and in the expected order. Check that every workflow state, transition button and revision history view renders correctly for each editor role, including dark mode, and that moderation forms still behave the same after a Gin update. Confirm this against the Gin release notes for your Drupal version rather than assuming it.
Media Library and Paragraphs widgets
Media Library modal dialogs and Paragraphs add, collapse and drag controls are the most heavily customized admin widgets on many sites. Editors working with nested Paragraphs depend on clear boundaries between items. Test these widgets with your real content types, including nested paragraphs and large media libraries, because styling issues often appear only at depth. Also check any custom widget or contributed module that injects its own markup into these forms.
Search API and Solr administration pages
Search API index configuration, field mapping and Solr connection screens are dense forms with many tables and checkboxes. Gin improves their density and spacing, but long field lists and nested fieldsets need review for readability. Verify that index status, processor settings and the Solr server test screen remain usable, and confirm that any Solr-related admin module you run is supported on the Drupal version you target.
Drupal CMS or site template choices
A site built from Drupal CMS or a site template may ship with its own admin theme choice, recipes and configuration. Before applying Gin, decide whether the distribution's default admin theme stays in place, and confirm that the recipe or template does not hardcode the theme in a way that conflicts with a later change. Check the Drupal CMS documentation for the release you use, since Drupal CMS 2.0 is the current major release.
Configuration management pipeline
Admin theme selection and Gin's appearance settings are stored as configuration, so they move between environments through the same export and import process as other site settings. Confirm that the theme and its settings are exported, that environment-specific overrides are not committed by accident, and that Gin is pinned in Composer to a release that supports your Drupal version. Test the deployment on a staging copy before editors see the change.
Questions teams ask before implementing the Gin admin theme
Does the Gin admin theme cost anything to use?
Gin itself carries no license fee. Drupal and contributed projects hosted on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal. Your costs are the work around the theme: planning the editor experience, configuring it, testing it against your custom admin code, and maintaining it through Drupal updates. Those costs come from the people doing the work, whether your team or a partner, and they recur each time Gin or Drupal core releases an update. Ask any partner for a quote built from a written scope, and confirm the licensing terms of any other contributed module you plan to add alongside Gin.
How long does a Gin rollout take and what drives the timeline?
The duration depends mostly on how much custom admin work the site already has. A site with stock content types, default forms and few admin overrides can adopt Gin with a short configuration and testing cycle. A site with custom form displays, bespoke admin pages, custom field widgets or contributed modules that alter admin markup needs more time to review each override. Other drivers include the number of editor roles that need testing, whether dark mode or other Gin settings need a brand review, the size of your staging environment, and how many Drupal core versions you must support during the change. Ask for a scope with a written list of the screens and roles covered before you agree a timeline.
Can our own development team implement Gin without a partner?
Often yes, if your team already maintains the Drupal site and has someone comfortable with Drupal configuration and theme settings. Installing and enabling Gin is a small task. The harder parts are reviewing custom templates, hooks and preprocess functions that target Claro markup, testing every editor workflow, and documenting the changes so the next upgrade is predictable. Teams that lack capacity for those reviews, or that need an outside check before a release, often bring in a partner for a fixed-scope review. Decide based on who will own the theme after launch, how many custom admin overrides exist, and whether your team has time for regression testing.
What does the Gin rollout need from editors and content leads?
Editors and content leads provide the workflow knowledge that a technical review cannot find. Ask them to list the tasks they perform most often, such as creating nodes, managing media, moderating content or editing menus, and to name any screens that slow them down. They should also review the dark mode and layout choices with real content, check that long titles, translated labels and accessibility needs still work, and confirm which roles see which tools. Plan a short test window where editors use staging with representative content. Their feedback decides whether the change is accepted, so schedule their time early rather than after development finishes.
Must we replace Gin before Drupal 12 because of Claro?
Claro is deprecated in Drupal 11.5.0 and removed from Drupal 12.0.0, and Gin is built on Claro. Sites are expected to move to the new Default Admin theme or the contributed Claro theme. Your planning question is therefore not whether Gin works today but what it depends on over the coming releases. Check the current Gin release notes for its supported Drupal versions, follow the deprecation guidance on Drupal.org, and confirm with the Gin maintainers how they plan to respond to the Claro removal. Drupal 12 is scheduled for the week of December 7, 2026, so build the upgrade path into your plan now rather than during the Drupal 12 work.
What should we do about custom admin overrides?
Start with an inventory. List every custom template, preprocess hook, library, form alter and contributed module that changes admin output, and mark which ones target Claro-specific markup or class names. Overrides that style core admin pages can often be removed once Gin provides the same behavior. Overrides that change business logic should stay but be tested against Gin's markup. Keep each change in custom code with tests, so it can be reviewed when the admin theme changes. Ask any partner to show how they will document each override, what regression tests they will run, and how they will handle the transition if the admin theme changes again.
How do we keep Gin updated after launch?
Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, according to the core release schedule. Gin and other contributed modules follow their own release cycles, so your update routine should cover core, Gin and every module that touches admin pages. Ask who will apply updates, who will test them against your custom admin overrides, and how long a staging check takes. Teams that do not have capacity for this routine often choose an ongoing support arrangement. Confirm the response expectations, testing scope and reporting in writing before you sign.
How DeployOpen scopes and delivers a Gin admin theme rollout
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted Drupal inside your own infrastructure. For a Gin admin theme rollout, we start from a written scope that covers how your editors work, which Claro-based pieces need attention, and how the theme change reaches each environment.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which editor roles, content types and admin screens the Gin rollout must cover.
- We confirm your Drupal core version against Gin's stated requirement before the build is estimated.
How we build
- We install and configure Gin in a non-production environment and review each editor workflow against it.
- Custom admin overrides, contributed modules and custom themes are checked for compatibility with Gin and Claro.
- Testing covers accessibility, dark mode behavior, keyboard navigation and editor tasks across representative roles.
How we hand over
- You receive configuration exports, a change record and documentation of every Gin setting we changed.
- Editor guidance and a short walkthrough explain the new authoring interface to content teams.
- A Claro deprecation plan records which custom code depends on Claro and how it moves to the new default admin theme.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the rollout.
- Retained support can track Gin releases against Drupal core updates, including Drupal 11.5 and Drupal 12 timing.
- Confirm with us which environments, release windows and response expectations the retainer must cover before signing.
