ALTOS

ALTOS runs before WordPress loads regular plugins, using the MU-plugins mechanism. That means the code is genuinely not loaded on screens where you don't need it — not loaded-and-then-suppressed. Deactivation is global and permanent; this lets you keep an item active site-wide while skipping it on specific admin screens or request types.

For 24–48 hours after you enable it, the loader samples real performance data on your own admin: load time, database queries, memory per active item, per admin screen. It then analyses those samples to suggest rules with a confidence score (0–100 %) and estimated savings. Suggestions are never applied automatically — you review them and apply with one click.

ALTOS has multiple safeguards:

• Dependency cascade detection — if you block a parent (e.g. WooCommerce), dependents are flagged automatically.
• Smart menu preservation keeps blocked items' admin menu entries reachable.
• Critical scenarios (page-builder editing, WooCommerce checkout/cart) are auto-excluded.
• The loader itself is auto-protected from being blocked.

Yes. Elementor, Bricks, Divi, and Beaver Builder edit sessions are detected and the loader steps out of the way to avoid breaking editor previews.

Full WooCommerce support: cart, checkout and account pages are excluded from any blocking on the frontend. Admin screens are recognised per area (products, orders, settings, …) so you can keep WooCommerce active on its own screens while skipping it elsewhere.

The Frontend Optimizer is an opt-in feature. If you leave it disabled (default), the frontend is completely unaffected. With it enabled, you can selectively skip items per page-type context (homepage, single, archive, …).

Yes. Open Settings → ALTOS → Administration and scroll to Conditional Rules (device / user). Each rule names a plugin, where it applies (admin, frontend or both), the device (any, mobile only, desktop only) and who it applies to: everyone including visitors, visitors only, all logged-in users, or a WordPress role; for the administrator role you can pick one specific administrator account. A rule with "Mobile only" keeps the plugin loaded on desktop and skips it on phones; a rule with "Administrator → admin2" skips the plugin for that account and nobody else. Conditions in one rule are combined (device AND user); several rules for the same plugin are alternatives. Rules are evaluated when plugins are loaded, so the plugin code really does not run. The Plugins screen and the ALTOS settings page always load everything, WooCommerce stays protected on shop pages, and safe mode switches the rules off. The device comes from wp_is_mobile(), the user from the login cookie without signature verification: treat these rules as a performance optimisation, not as access control. Rules with users do not apply to visitors who are not logged in. Developers can implement other conditions (time of day, IP ranges, ...) with the sapm_admin_filtered_plugins and sapm_frontend_filtered_plugins filters from an mu-plugin; SAPM_Core::get_logged_in_user_hint() returns the user login available at that early stage.

Three strategies are available:

1. TTL extension — Throttle the outbound api.wordpress.org update HTTP calls so they only re-run after a configurable interval (12 h → 24–72 h). WordPress keeps its own cache; we only reduce how often it gets refreshed.
2. Page-specific — Only run update checks on the dedicated Plugins, Themes and Updates admin pages.
3. Cron-only — Move all update checks to background WP-Cron; the admin never blocks on them.

Yes. Network activation is supported but each subsite needs its own per-site rules. The MU-loader is created once for the network. Frontend rules also apply to network-activated (network-wide) plugins.

No. See the External Services section above.

English (source) plus Czech (cs_CZ), Slovak (sk_SK), Polish (pl_PL), German (de_DE), French (fr_FR), and Spanish (es_ES). Translations live in /languages/ as .po/.mo. Community translations from translate.wordpress.org are also picked up automatically.