Admin Login Styles

An Omeka S module that restyles the admin login screen to match your institution, configured from the admin rather than by editing CSS.

Omeka S renders login, forgot-password and create-password through a stripped-down layout that no site theme touches. That is a reasonable decision — those pages exist before a site has been chosen, so there is no theme to apply — but the effect is that the first screen anyone sees is the only one that cannot be branded.

Features

• A white card layout for the login form, in place of Omeka's default
• Login heading, primary colour and accent colour set from the module's configuration form
• Optional Google Fonts family, or none at all
• Fixes Chrome's yellow autofill overlay on the username and password fields
• Optionally hides the "Powered by Omeka S" footer line
• Covers forgot-password and create-password, not just the login form

Installation

1. Copy the AdminLoginStyles directory into your Omeka S modules/ directory.
2. In the Omeka S admin, go to Modules, find Admin Login Styles, and click Install.
3. Click Configure to set the heading and colours.

Configuration

All settings live in Modules → Admin Login Styles → Configure, and every one of them is optional.

Setting	Blank means
Login heading	Omeka's "Log in" is left alone
Primary colour	#334155 — headings and link text
Accent colour	#2563eb — the log-in button
Heading font	the system font stack, and no external request at all
Hide "Powered by Omeka S"	unchecked; the attribution stays

With nothing configured the module still applies its card layout and the autofill fix, using the neutral defaults above. It never renders half-branded.

Each field states what is actually in force — either the value you set, or the default and why it applies. Nothing sits in an empty input as a hint, on purpose: an earlier version put each default hex in the field's placeholder, and on a real install all three were saved as their own placeholder values, producing a blue button on a red-branded site.

Login heading takes any text. The form names your installation title in its help text, since Omeka already knows it and it is usually what you want — as a suggestion in prose, not pre-filled into the field. Only the login page is affected; the password-recovery and account-activation headings are instructions ("Forgot password"), and replacing those with an institution's name would remove something the reader needs.

Colours must be 3- or 6-digit hex, e.g. #334155 or #abc. Anything else is rejected with a message rather than silently ignored.

Heading font is a Google Fonts family name — Roboto, Playfair Display. Letters, digits, spaces and hyphens only. Leave it blank if your institution cannot make requests to Google — nothing is loaded from an external host in that case.

How the styling is applied

asset/css/login.css is a static file and carries the defaults as its var() fallbacks. The module emits a small inline <style> block containing only the custom properties you actually set. So the stylesheet stays cacheable, and with nothing configured no inline block is emitted at all.

Everything written into that block is validated at the point it is written, not merely when it is saved — see buildOverrides(). Values reach a database by more routes than a form.

Requirements

• Omeka S 4.0 or higher

Permissions

The module registers no ACL rules, so Omeka S's default applies: only Global Administrators can reach its configuration form.

Known limitations

Current characteristics, not bugs in disguise.

• The heading is generated content, not real text. It is applied as h1::before with the original text collapsed to font-size: 0. That text stays in the accessibility tree, so a screen reader still announces "Log in" — which describes the page better than an institution's name does. Some readers announce generated content too, so a few users will hear both. This is a deliberate trade against the alternative, which was rewriting the heading in JavaScript and destroying the original text along with flashing it on load.
• The layout is not configurable. Card width, padding, radius and shadow are fixed. Only colours, the font and the heading are exposed; anything else means editing login.css.
• One font, applied to everything. There is no separate body and heading face, and no font-weight selection. The family is requested at 400 and 700.
• No logo. There is nowhere to upload one, and no setting for an image.
• Google Fonts only. A self-hosted or otherwise-hosted webfont is not supported; you would add the @font-face rule to login.css yourself.
• Non-ASCII font names are rejected. Every Google Fonts family is ASCII, so this has not mattered in practice.
• No dark mode. The card is white, unconditionally.

Scope

The name is narrower than the module could be, on purpose. It styles the login-controller pages and nothing else — it does not touch the admin theme, the site themes, or the installation screen. If it grew to cover those it would want a different name rather than a wider reading of this one.

Provenance

Extracted from a private monorepo where it has run in production against Omeka S 4.x. Deployment-specific values were removed rather than parameterised, and the history here starts at extraction.

License

GPL-3.0-or-later, matching Omeka S itself — a module is a derivative work of the application it extends. See LICENSE.