Keel Defaults

Sixteen of the thirty-nine defaults are on out of the box, and nine more settings that are not simple switches apply a starting value. Nothing is written to your content and nothing is deleted; every one of them is a switch on Settings → Site Defaults you can turn off, and turning it off puts WordPress back exactly as it shipped. Most of it is quiet. Users stop being listed to anonymous REST requests, new passwords have to be long and must not appear in a known breach, raw HTML and JavaScript are limited to Administrators, baseline security headers are sent, AI provider connectors are switched off, translations keep auto-updating, uploads get lowercase filenames, attachment screens show which image sizes were generated, and the site warns you if its own email looks misconfigured. Three are visible straight away and are the ones to know about. Comments, trackbacks and pingbacks are switched off everywhere, including for existing posts — nothing is deleted, and turning the setting off brings every comment back. Author archives stop resolving, so /author/name/ no longer returns a page. And X-Frame-Options: SAMEORIGIN is sent, which stops other sites displaying yours in an iframe; if something is meant to embed this site, set Frame options to "Leave unchanged". Two more change things you may not see immediately: attachment pages redirect to the parent post, and self-pingbacks and the emoji detection script are gone. The starting values are conservative. Core auto-updates are set to minor — maintenance and security releases install themselves, major versions do not — ten post revisions are kept, logins last two days or fourteen with "Remember me", and subscribers are exempt from the password rules. The admin menu width, the front-end admin bar and the login logo are all left as WordPress has them until you choose otherwise. One default is on but does nothing on a live site: outgoing email is blocked on any environment that is not production, so a database copied to staging or a laptop cannot email real people. On production it never acts.

In that case, WordPress.org has offered the same-line security patch only as an automatic-update offer. get_core_updates(), which builds the Updates screen, skips every automatic-update offer. On a 6.9.5 site the patch is 6.9.7 and the screen offers 7.1, which is a major update, not a patch. A same-line patch can also be the current manual release, so Keel asks core what the screen is actually showing rather than assuming it is absent. Keel names the patch for your release line and tells you what that screen is actually offering, so you can see the difference. If minor auto-updates are switched on and nothing is blocking the updater, the patch installs itself on a scheduled check. If something is blocking it, Keel names the specific constant, filter or condition responsible, because each one needs a different fix. Keel can install it for you, from the same panel. The target is recomputed on the server and can only ever be the patched release on your own line, so it cannot cross a release line or move you backwards. It checks the release's PHP and MySQL requirements first, refuses if the filesystem is not writable, and then hands the offer to WordPress's own upgrader with rollback enabled — the same machinery core uses for its own automatic updates.

The defaults that are on out of the box are low-risk, with one exception worth naming: X-Frame-Options: SAMEORIGIN is sent by default, and it stops other sites embedding yours in an iframe. Set Frame options to "Leave unchanged" if the site is meant to be embedded, because a blocked frame fails silently as a blank box. Everything else that can break something is off and opt-in, and each says on the settings screen what it will cost you — for example that blocking the XML-RPC endpoint also stops apps and services that publish through it. Requiring authentication for REST is the one place Keel spends a little of that strictness back: oembed/1.0 stays reachable, so other sites can still embed your posts when every other route is closed.

One thing, and only when the strong-password default is on: the first five characters of a password's SHA-1 hash, to check it against known breaches. Never the password, never the full hash, no personal data. See External services above for the full description and how to switch it off.

Because Keel switched it off, deliberately, and there is an admin notice on the site saying so. The Non-Production Email default suppresses outgoing mail on any environment that is not production, so a database copied down from production cannot email real customers from a staging site or a laptop. It does nothing on production, so it cannot be left on by mistake. To send from a non-production site anyway, turn the default off under Settings → Site Defaults, define KEEL_ALLOW_NONPRODUCTION_MAIL in wp-config.php, or use the keel_suppress_nonproduction_mail filter. A mail catcher can still record what would have been sent by hooking keel_outgoing_mail_suppressed. The environment is read the same way the admin-bar environment indicator reads it: WP_ENVIRONMENT_TYPE, whether set as a constant or an environment variable, and a host-name fallback for local development tools when neither is set.

No. Disabling comments hides them and closes the forms; nothing is removed from the database, and turning the default off brings every comment back. The same holds for the other content defaults.

Yes. Every default reads its value through the plugin's own option, and the behaviours are filterable — keel_weak_roles, keel_disable_hibp, keel_comment_blocks, keel_allowed_comment_types and others. A wp-config.php constant always wins over the settings screen where one applies; the screen says so when it is being overridden.

The setting is stored per site; the effect is not. WordPress keeps one user table for the whole network, so a password is checked against whichever site it is being set on — and once set, it is that person's password everywhere. Exempting a role on one subsite decides what happens when a password is changed there; it does not exempt those accounts from another site's policy. In practice the strictest site on the network sets the floor for anyone who changes their password on it. Keel can now govern it as well as document it. Under Network Admin → Settings → Network Policy, a Super Admin can decide any setting for the whole network; sites see it as locked and cannot change it. Tick the password rules there and the network has one policy instead of a floor set by whichever site is strictest. Nothing is written into your sites. A network value is applied when a setting is read, so a site's own saved settings are untouched — untick a setting later and every site returns to exactly the value it had. Settings left unticked stay each site's own business.

You can, but you probably should not, and Keel will tell you when it matters. Some settings are applied through WordPress filters that transform a value in priority order — session length is the clearest example. Another callback on the same filter does not prove a conflict: two plugins may reach the same outcome or govern different parts of a structured result. Keel reports a structural overlap only when it is registered on an authoritative policy hook and a callback attributable to another active plugin is registered there too. It never executes the other plugin's callback to diagnose the overlap. The notice appears on the Plugins screen, on Settings → Site Defaults, and on the dashboard, where it can be dismissed until the overlap changes. The full details are explained under Tools → Site Health. That evidence confirms shared ownership of a hook, not that the plugins' configured outcomes disagree. Keel asks you to compare their settings and never recommends deactivation from callback presence alone. Mail, authentication, comment-query, capability, and unattributable overlaps stay unconfirmed and informational. There is a limit worth knowing. WordPress ships tiny helper callbacks such as __return_false; the callback belongs to WordPress, not the plugin that registered it. Keel labels that limitation unconfirmed instead of guessing from source code or naming a plugin without evidence. A second limit is broader, and it is worth knowing before you rely on the reporting. Everything above is about filters: Keel can watch a filter because its own callback runs when WordPress runs it, so it can see what the chain settled on. A plugin, theme or host that changes the admin with CSS registers no filter at all, so there is nothing to observe and nothing to report. The width of the admin menu is the usual case — a managed host may style the admin to its own design, and that is not a conflict Keel can detect or should fight. Keel offers settings that can win some of those, the menu width among them, but it will not tell you that you need one. Keel also stays out of the fight where it has nothing to say: when a setting is still at the value WordPress itself uses, Keel does not register the filter at all, so it cannot override a deliberate choice another plugin has made — and it will not report a conflict on a setting it is not itself setting.

WordPress ships one, but it is JavaScript: it advises the person typing and cannot refuse anything, so a password set over the REST API, WP-CLI, or a form with scripts disabled never meets it. Keel enforces length, breach screening, a blocklist and a personal-context check server-side instead, where they cannot be bypassed. See the Help tab on the settings screen.