SOS Documentation
The normal WordPress website
A normal WordPress page can depend on many different components working together.
These can include:
- WordPress Core;
- your active theme;
- installed plugins;
- the WordPress database;
- PHP;
- files stored on the server; and
- external services used by the website.
That flexibility is one of WordPress’s strengths, but it also means that a serious problem with one component can sometimes prevent the normal page from being completed.
SOS does not attempt to reproduce that entire environment during the emergency experience.
A deliberately simpler emergency page
The SOS Critical Error Page is intentionally simpler than your normal website.
Its job is not to reproduce your normal navigation, page builder, theme templates or dynamic content.
Instead, it concentrates on information such as:
- your website or business identity;
- a clear status message;
- a visitor-friendly explanation;
- simple presentation and branding;
- useful visitor actions; and
- appropriate contact information where configured.
The SOS resilience profile
When you configure and save SOS, the plugin prepares a local resilience profile containing the information needed for the Critical Error Page.
This means SOS does not need to reconstruct the page from your normal WordPress content at the moment the fatal condition occurs.
The profile is prepared in advance while WordPress is operating normally.
Developer Tools can show whether the compiled resilience profile is present and readable and when it was most recently prepared.
Why SOS does not rely on the database during fallback
WordPress normally stores a large amount of website information in its database.
During the supported SOS fallback experience, the Critical Error Page is designed so that it does not need to retrieve its visitor-facing configuration from the WordPress database.
The required information has already been prepared locally as part of the SOS resilience process.
Why SOS does not rely on your active theme
Your normal website design is usually provided by your active WordPress theme and may also depend on page builders, plugins, templates, fonts and other assets.
SOS does not attempt to load your normal theme to construct the emergency page.
Instead, the Critical Error Page uses its own deliberately self-contained presentation.
This is why your SOS page may resemble your normal brand without being an exact copy of your website.
That difference is intentional.
The priority during a supported fatal error is to provide a clear and useful visitor experience rather than reproduce every part of the normal website design.
You can inspect the current SOS resilience state at any time from SOS → Developer Tools.
Why SOS does not require a remote service
The core SOS Critical Error Page does not require a remote API or external service in order to render.
You do not need an apluskdesign account, licence server or Geneva connection for the core visitor-facing fallback to work.
If the emergency page depended on an external service for its basic content or presentation, that would introduce another dependency into an experience intended for use when something has already gone wrong.
Independent at the core. Enriched by integrations.
Optional services can add useful context, but they are not required for the core SOS Critical Error Page.
The WordPress php-error.php drop-in
WordPress supports a special file named php-error.php that can be used as part of its fatal-error handling process.
SOS uses this supported location to provide its prepared Critical Error Page when the relevant WordPress fatal-error path invokes it.
The SOS drop-in is deliberately designed for the emergency context in which it operates.
It does not attempt to load your normal WordPress theme or rebuild the normal website before displaying the visitor-facing page.
SOS checks ownership before managing the drop-in
SOS does not assume that every php-error.php file belongs to SOS.
Another plugin, developer or website configuration may already be using the same WordPress drop-in location.
For that reason, SOS checks whether it owns the file before treating it as its own.
This helps SOS coexist more safely with custom WordPress installations and other software.
If an existing drop-in prevents SOS from managing its Critical Error Page, SOS can report the situation so that an administrator or developer can investigate it.
What happens when a supported fatal error occurs?
At a high level, the process looks like this:
- WordPress encounters a supported fatal-error condition.
- WordPress remains responsible for its fatal-error handling and Recovery Mode behaviour.
- The supported WordPress error path invokes the available
php-error.phpdrop-in. - The SOS drop-in uses the prepared local resilience information.
- The visitor receives the configured SOS Critical Error Page.
SOS does not need to determine how to repair the underlying problem before it can provide useful information to the visitor.
That investigation remains separate.
SOS and WordPress have different responsibilities
SOS does not replace WordPress’s fatal-error handling system.
It also does not disable or replace WordPress Recovery Mode.
WordPress continues to handle the underlying error and its administrator-facing recovery mechanisms.
SOS concentrates on the visitor-facing experience available through the supported Critical Error Page path.
SOS looks after the visitor experience. WordPress looks after the error.
What happens when you change your SOS settings?
When you make changes to the Critical Error Page and save them, SOS updates the locally prepared information used by the emergency experience.
This is why it is important to save your configuration after making changes.
The prepared emergency experience should represent the latest successfully saved SOS configuration rather than depending on live retrieval from the normal website during the fatal condition.
What happens when SOS is deactivated?
SOS is designed to manage only the files and data that belong to SOS.
When the plugin is deactivated or removed, it should not claim ownership of an unrelated Critical Error Page drop-in created by another plugin, developer or system.
This ownership boundary is an important part of the way SOS manages the shared WordPress drop-in location.
What SOS does not do
SOS is deliberately focused.
It is not:
- a website backup system;
- a hosting or server monitoring service;
- a replacement for WordPress Recovery Mode;
- a tool that automatically repairs broken plugins or themes;
- a database recovery system;
- a general maintenance-mode plugin; or
- a guarantee that a page can be displayed during every possible server, network or infrastructure failure.
SOS is designed for the supported WordPress fatal-error path in which its Critical Error Page can be invoked.
Why SOS cannot cover every kind of outage
SOS still requires enough of the server environment to be functioning for its emergency PHP page to execute.
For example, if the web server cannot process requests, PHP itself cannot run, the required filesystem is unavailable or the request never reaches the relevant WordPress error path, SOS may not be able to display the Critical Error Page.
This is why SOS should complement good hosting, backups, security, monitoring and maintenance practices rather than replace them.
Check the current SOS status
Open SOS → Developer Tools to review operational information about the current installation.
On a healthy installation, Developer Tools can help confirm that:
- the SOS Critical Error Page drop-in is owned and ready;
- the compiled resilience profile is present and readable;
- WordPress Recovery Mode remains preserved;
- the database is not required during fallback;
- the active theme is not required during fallback; and
- a remote API is not required during fallback.