wordpress-public-workspace/reports/dark-mode-by-gracepress-1.0.0-baseline.md

Dark Mode by GracePress 1.0.0 Baseline

Date: 2026-08-22 Scope: Phase 1 factual baseline only Release action: none

Artifact and environment

• Canonical source: /Workspace/gracepress-workspace/wordpress-plugins/dark-mode-by-gracepress/
• Installed artifact: /Workspace/gracepress-workspace/dist/wp-org/dark-mode-by-gracepress.zip
• Package contents: one top-level dark-mode-by-gracepress directory containing the main PHP file, CHANGELOG.md, and readme.txt.
• Installed status: active, version 1.0.0.
• Declared compatibility: WordPress 6.0+, PHP 7.4+, tested through WordPress 7.0.
• Lab runtime: WordPress 7.1, PHP 8.3.33, Twenty Twenty-Five 1.5.
• Lab URL: http://100.64.0.9:8890/
• Exposure: Desktop Tailnet address only.

Current architecture

• The runtime is one 38 KB PHP file containing PHP, HTML, CSS, and JavaScript.
• It registers activation and deactivation hooks, init translation loading, wp_head/admin_head output, wp_footer/admin_footer output, an admin settings page, an admin-bar node, a menu-item filter, a shortcode, and plugin action links.
• It stores 19 small WordPress options. Every current option is autoloaded.
• It retains legacy option names beginning gracepress_dark_ and gp_dm_ to preserve migration compatibility.
• It has no database tables, REST routes, AJAX actions, scheduled tasks, filesystem writes, uploads, or direct remote HTTP calls.
• It retains conditional calls to private gp_omnilog() and gp_log() functions when those functions exist.
• It retains private-era routing checks for GracePress_Central_Hub, gracepress-theme, and GracePress-specific front-end selectors.

Current saved configuration

• Default state: follow operating-system preference.
• Front-end floating control: enabled.
• WordPress admin dark mode: enabled.
• Admin/menu integration: enabled.
• Floating pulse: enabled.
• Keyboard shortcut: enabled.
• Toggle: classic icon, normal size, bottom-right.
• Brightness: 95 percent.
• Contrast: 90 percent.
• Media opacity: 85 percent.
• Transition: fade, 250 ms.
• Page exclusions, element exclusions, and custom CSS: empty.

Admin interface in light mode

The valid visual baseline was captured only after removing the gracepress-dark-active root class. The earlier black rendering was the plugin actively filtering wp-admin and was not the page's native palette.

Strengths:

• Clear two-column desktop layout.
• Large local-only navy hero with cyan accent.
• Four named settings groups.
• Readable white cards and standard form controls.
• Working filter preview.
• Visible primary save and secondary reset actions.
• Responsive intent is present.
• GracePress footer includes John 1:5 and the plugin version.

Weaknesses:

• The hero is visually large but carries no operational status, current mode, quick action, or navigation.
• Information architecture follows implementation categories rather than user goals.
• All controls are presented at once; advanced selectors and custom CSS receive no progressive disclosure or risk explanation.
• There is no concise summary of active behavior, precedence, schedule, exclusions, or where toggles are currently displayed.
• The preview is small and demonstrates only filter values, not toggle styles, theme content, media correction, system preference, or transitions.
• Some labels use engineering language such as "absolute Anti-FOUC synchronization" and "hardware-accelerated CSS inversion" instead of user outcomes.
• Save feedback is generic and the page has no dirty-state indication.
• Reset Filters resets only three filter values, not all settings, but the distinction is easy to miss.
• The full-page browser capture repeated moving sections while stitching the image. The semantic DOM contained one set of controls, so this is recorded as a capture artifact rather than a plugin duplication defect.

Front-end baseline

• The stock Twenty Twenty-Five homepage renders normally in light mode.
• A floating moon button appears at bottom-right.
• A Dark Mode item appears in the WordPress toolbar for logged-in users.
• The floating button's accessible name is only the moon glyph; it has no descriptive label or pressed-state semantics.
• The pill-switch variant is emitted as a div rather than a native button.
• Front-end and admin scripts use one localStorage key: gracepressDarkMode.
• No external network dependency is required for ordinary rendering.

Confirmed implementation concerns

These are baseline findings, not the complete Phase 5 security review.

High-priority functional issues

1. The "Enable in WordPress Admin" setting is not enforced. admin_head and admin_footer always run the dark-mode engine, and the admin-bar toggle is always registered for logged-in users.
2. admin_init force-enables the admin setting once and records gp_dm_adminbar_toggle_restored, overriding the expected role of an administrator-controlled preference.
3. The settings form always posts to admin.php?page=dark-mode-by-gracepress even when the public plugin registered its page under options-general.php. This needs direct workflow testing and likely correction.
4. Time-based mode calculates the WordPress site hour while PHP renders the page. Full-page caching can preserve a stale hour and produce incorrect schedule behavior.
5. In automatic-time mode, the schedule is evaluated before the stored manual preference, so a visitor's manual choice does not persist across page loads while automatic mode is selected.

Security and review concerns

1. The nonce value is passed directly from POST to wp_verify_nonce() without wp_unslash() and scalar sanitization.
2. Several numeric POST values use absint() without checking that the fields exist first.
3. Enumerated settings such as default state, icon style, button size, position, and transition speed are sanitized as generic text on save rather than rejected against allow-lists.
4. Transition speed is interpolated into CSS without strict CSS-time validation.
5. Element-exclusion text is concatenated into generated selector CSS. It needs bounded selector validation and graceful handling of invalid selectors.
6. Custom CSS is intentionally emitted into every applicable page. The capability boundary is strong, but allowed syntax, external URL behavior, privacy implications, and closing-tag safety require explicit review.
7. Conditional gp_omnilog()/gp_log() integration contradicts the goal of a fully independent public plugin and complicates the readme's no-telemetry assurance.
8. Large inline CSS and JavaScript blocks are emitted on all front-end pages and broadly across wp-admin rather than being scoped and enqueued where practical.

Accessibility and compatibility concerns

1. Floating icon buttons need descriptive accessible names and state semantics.
2. The pill-switch variant must be a keyboard-operable native control or implement complete button semantics.
3. Ctrl+Alt+D is captured globally, including while users work in form fields and editors, and may conflict with browser, operating-system, or assistive-technology commands.
4. Motion does not currently honor prefers-reduced-motion.
5. Many admin strings remain untranslated.
6. GracePress-specific media selectors remain in the public plugin and need either generalization, documented compatibility purpose, or removal.
7. The readme describes "accessible toggle controls," which is not yet fully supported by the observed controls.
8. The package declares Tested up to 7.0 while the current lab is WordPress 7.1; compatibility metadata must follow completed testing rather than assumption.

Initial checklist disposition

Pass or substantially present:

• Independent public slug and renamed dmbg_ PHP identifiers.
• GPL-compatible declared license.
• Correct top-level installable ZIP structure.
• No direct executable-code downloads.
• No direct remote HTTP request in the current source.
• manage_options gate on the settings renderer.
• Nonce generation and basic verification are present.
• Stable tag, main header version, runtime constant, and package version agree at 1.0.0.
• Local WordPress.org icons and banners exist outside the runtime ZIP.
• No embedded credentials or API tokens observed.
• Active installation on the isolated lab succeeds.

Needs repair or proof:

• Private logging and routing remnants.
• Strict input validation and nonce handling.
• Admin-enable behavior.
• Settings form action.
• Accessibility semantics and reduced-motion behavior.
• Complete internationalization.
• Admin/front-end asset scoping and performance.
• Privacy statement reconciliation with conditional private logging.
• Readme claims versus actual accessibility.
• Uninstall/data-retention policy.
• Minimum-version matrix.
• Plugin Check, readme validator, PHPCS, debug, upgrade, deactivation, uninstall, and multisite testing.
• Exact final ZIP inspection after the redesign.

Baseline conclusion

Version 1.0.0 is a working independent installation candidate and a sound behavioral starting point, but it is not yet a WordPress.org submission candidate. The next approved phase is competitor and user-value research, followed by an admin information-architecture proposal. No source repair or redesign was performed during this baseline.