/*
* PKWARE - admin chrome that applies whatever colour scheme is active.
*
* SEPARATE FROM admin-colors-pkware.css ON PURPOSE.
*
* admin-colors-pkware.css loads ONLY when a user has the PKWARE scheme
* selected. Core swaps it. It is colour.
* this file loads on EVERY admin screen for every user. It
* is structure, spacing and typography, and it must
* stay readable on Midnight and Ocean too.
*
* So: nothing here sets a menu or link colour. If a rule in this file needs a
* brand colour to work, it belongs in the other file.
*
* @package pkware
*/
/* --- Login screen -------------------------------------------------------- */
body.login {
background: #1e3074; /* --pk-navy */
}
body.login h1 a {
background-image: none;
width: auto;
height: auto;
text-indent: 0;
font-family: Georgia, "Times New Roman", serif; /* --pk-font-serif */
font-size: 30px;
line-height: 1.2;
color: #fff;
letter-spacing: 0.02em;
}
body.login form {
border-radius: 6px; /* --pk-radius-md */
border: 0;
box-shadow: 0 12px 32px rgba(30, 48, 116, 0.18); /* --pk-shadow-lg */
}
body.login #backtoblog a,
body.login #nav a {
color: #d9e0ec;
}
body.login #backtoblog a:hover,
body.login #nav a:hover {
color: #0fe4a2; /* --pk-frost */
}
/*
* The privacy link core adds below the form. Left visible deliberately - it
* points at /privacy, which is a real page on this site and a compliance
* artifact, not decoration.
*/
body.login .privacy-policy-page-link a {
color: #d9e0ec;
}
/* --- Footer -------------------------------------------------------------- */
#wpfooter {
color: #646970;
}
/* --- PKWARE sections on core screens ------------------------------------- */
/*
* Scoped to .pkware-admin-section so nothing here can reach a core metabox or
* another plugin's settings page. Every future PKWARE admin surface goes inside
* a container carrying this class.
*/
.pkware-admin-section {
margin: 1.5rem 0; /* --pk-space-md */
padding: 1.5rem;
background: #fff;
border: 1px solid #dcdcde;
border-radius: 6px; /* --pk-radius-md */
box-shadow: 0 1px 2px rgba(30, 48, 116, 0.08); /* --pk-shadow-sm */
}
.pkware-admin-section > h2,
.pkware-admin-section > h3 {
margin-top: 0;
font-family: Georgia, "Times New Roman", serif; /* --pk-font-serif */
font-weight: 400;
}
/*
* The one piece of brand furniture. A 3px rule under a section heading, in the
* accent, is enough to say "this part is ours" without competing with core.
*/
.pkware-admin-section > h2 {
padding-bottom: 0.5rem; /* --pk-space-2xs */
border-bottom: 3px solid #0fe4a2; /* --pk-frost */
}
.pkware-admin-section .description {
max-width: 46em;
}
/* --- Core's "About the user" / "About Yourself" section, removed --------- */
/*
* Bob, 2026-08-15: "Can we move Biographical Info under PKWARE Profile and get
* rid of the About Yourself section everywhere?"
*
* Biographical Info is re-rendered inside the PKWARE Profile block by
* inc/user-profile.php, so this hides core's copy along with the heading above
* it. The heading carries no class and no id - it is a bare printed inline
* by wp-admin/user-edit.php - so it can only be reached through the table that
* follows it, which is why :has() is used.
*
* :has() IS THE LOAD-BEARING PART, AND ITS FALLBACK IS UGLY BUT NOT DANGEROUS.
* In a browser without :has() (Chrome under 105, Firefox under 121, Safari under
* 15.4 - all pre-2022) the heading and a second Biographical Info box remain
* visible. Nothing is lost when that happens: both boxes render the same stored
* value, and PHP takes the LAST field of a repeated name, which is always the
* PKWARE one because it renders later in the form.
*
* The row selector is kept separate from the :has() rules on purpose - it works
* everywhere, so even without :has() the duplicate field collapses to just the
* stray heading.
*/
tr.user-description-wrap {
display: none;
}
table.form-table:has(tr.user-description-wrap) {
display: none;
}
h2:has(+ table.form-table tr.user-description-wrap) {
display: none;
}
/* --- Core's own Profile Picture row, removed ----------------------------- */
/*
* Bob, 2026-08-15: "the original Profile Image at the top threw me, could we
* obviate that and just use the lower block please?"
*
* Two rows offering the same thing is worse than either alone - the top one is
* read-only and points at Gravatar, the lower one is the field that actually
* works. Core echoes this row inline in wp-admin/user-edit.php with no hook to
* remove it, so CSS is the only route; inc/user-avatar.php separately empties
* its description text so the fallback is never a wrong instruction.
*
* display:none rather than visibility or an off-screen shift, deliberately: it
* takes the row out of the accessibility tree and the tab order too, which is
* the objection to "hiding" things. Nothing here is merely painted over.
*/
tr.user-profile-picture {
display: none;
}
/* --- Posts and Pages list tables: give the width to the title ------------ */
/*
* Bob, 2026-08-15: "Category and Tag columns are too wide, we only use 1 tag or
* 1 Category. Can we start with making those two columns shorter, and increasing
* the Title column, please, in both places."
*
* WordPress sizes list-table columns by content, so a Categories column holding
* one short word still claims a share proportional to its heading. On this site
* that is always wasted, and the numbers are stronger than Bob's "we only use 1"
* - measured across all 344 published posts on development, 2026-08-15:
*
* categories per post min 1, max 1 - every post has exactly one
* tags per post min 0, max 0 - NOT ONE POST IS TAGGED
*
* So Categories can never need more than one term's width, and the Tags column
* is entirely empty on the posts list. It is left in place rather than hidden
* because tag 374 does carry six PAGES, and hiding a column is a different
* decision from narrowing one.
*
* Meanwhile the titles here are long - the global scan already flags 65 headings
* over length across 39 pages - so they wrap to three and four lines in a column
* that has been squeezed by six others.
*
* body.edit-php covers BOTH screens: edit.php is the posts list and
* edit.php?post_type=page is the pages list, and both carry that body class.
* That is why one rule does what Bob asked for "in both places".
*
* Percentages rather than pixels, so the table still adapts to the plugin
* columns that come and go - Yoast adds two, Complianz adds one, and a fixed
* pixel layout would overflow the moment one is switched on.
*
* Guarded at 783px because below that WordPress collapses the table to a stacked
* mobile view where widths are meaningless and forcing them breaks the layout.
*/
@media screen and (min-width: 783px) {
body.edit-php .wp-list-table .column-title {
width: 38%;
}
body.edit-php .wp-list-table .column-categories,
body.edit-php .wp-list-table .column-tags {
width: 7%;
}
/*
* A one-word category in a 7% column would otherwise break mid-word on a
* narrow viewport.
*/
body.edit-php .wp-list-table .column-categories,
body.edit-php .wp-list-table .column-tags {
word-break: normal;
overflow-wrap: break-word;
}
}
/* --- Profile screen: two columns on desktop ------------------------------ */
/*
* Bob, 2026-08-15: "Front end is 1300px, admin area, please for Desktop, make
* this 2 columns instead of a single long line."
*
* The 1300px cap is the front end's --pk-container-max value, matched here on
* purpose so the admin reads as the same product rather than a WordPress screen
* with a logo on it.
*
* MULTI-COLUMN RATHER THAN GRID, AND THE REASON IS THE MARKUP.
* WordPress builds this screen as a flat sequence of siblings - , then
*