Oiko / defaults

Defaults, not slogans.

Every Oiko plugin ships from the same boilerplate, engineered around a small set of rules you can read in the code.

House security defaults

Security

Every form and API route earns trust before it acts on it.

Every form and API route checks who you are before it does anything else.

Capability comes before nonce, everywhere — a valid nonce only proves a request was intentional, not that the requester is allowed to make it. Oiko Guard's own Settings_Page::save() shows the pattern exactly: `if ( ! current_user_can( 'manage_options' ) ) { wp_die(...); }` runs first, and only then does `check_admin_referer( 'oiko_guard_save_settings' )` fire. Every settings save, REST route and admin-post handler across every Oiko plugin follows this same order.

All input is cleaned, all output is escaped — always, not just when it seems necessary.

Every plugin ships one Sanitizer class as the single chokepoint for $_POST/$_GET/$_REQUEST reads, matched to type. Escaping happens at the point of output, every time — including data a plugin stored itself. Oiko Guard's Login_Log class states this plainly in its own docblock: every field it returns is attacker-controlled input that MUST be escaped by whatever renders it, the same bug class that shipped a stored-XSS CVE in a well-known competing plugin.

Nothing runs without permission. No hidden public endpoints.

Every REST route ships with an explicit permission_callback — never a bare route left open on the assumption nobody will guess the URL. Oiko Boost's Asset_Manager_Bar::can_manage() is the whole check: `return current_user_can( 'manage_options' );` — one line, always present, never skipped.

Removing a plugin removes everything it added. Nothing left behind.

Every plugin's uninstall.php deletes its own options, tables, transients and cron hooks unconditionally. Where cleanup would be destructive to a site's own content — not just the plugin's own settings — that step is opt-in instead: Oiko Fields only deletes field values from posts/users/terms during uninstall if the site owner explicitly enabled `delete_data_on_uninstall` in Settings; the field-group definitions and options-page values are removed either way.

House performance defaults

Performance

Nothing runs, loads, or sits in memory unless it has to.

Scripts load deferred, only on the pages that actually use them.

Oiko Boost's per-page script manager reads an admin-bar-driven rule set and dequeues matched script/style handles per request — scoped to a post type, a specific URL, or globally, decided per rule rather than loaded everywhere by default.

Nothing sits in memory unless it needs to.

Oiko Sessions' "log out everyone" action is a single SQL statement against wp_usermeta — no WP_User objects loaded for a bulk operation that could otherwise touch hundreds of thousands of rows. Oiko Fields' field-group lookup is memoized per request instead of re-querying and re-decoding the same JSON on every meta box render within one page load.

Slow work happens in the background — never blocking your site.

Oiko Guard prunes its 90-day login-event log on a daily WP-Cron event rather than on any page load. Oiko Boost downloads and self-hosts a Google Font on a scheduled single event the moment a page needs it, guarded against being scheduled twice — the visitor's request never waits on that download.

No polling, no bloat, no phoning home.

The one place an Oiko plugin talks to an external API at all is Oiko Boost's Chrome UX Report dashboard — and even that is gated behind an explicit opt-in setting, checked before any request fires. It reads public, aggregate performance data about your own site from Google's free API; nothing is sent the other way, and nothing else in the Oiko line calls out anywhere.

Keep exploring