Offair - Branded Error Pages

No. It does not let you put your site offline. It styles the screens WordPress shows on its own when the database is down, while updates are installed and after a fatal error. It works alongside any maintenance mode or coming soon plugin.

Because WordPress only looks for these drop-ins there, and loads them before any plugin. That is the only way to show a page when the database is down. The three files are identical copies of dropins/drop-in.php from the plugin folder. They are removed when the plugin is deactivated or uninstalled.

The database is precisely what may be unreachable when the page is shown. The content is saved in the uploads folder, in offair/pages.json, and contains only what the visitors see on the page. The alert settings and the history are kept in a private folder next to it.

Yes. Pages already in the cache keep being served normally during an outage, which is what you want. Only requests that reach PHP see the outage page, and that page is sent with headers that prevent it from being cached.

No. If the web server or PHP itself is down, nothing on the site can run. Only your host can show a page in that case.

Another plugin or a person placed a file with the same name in wp-content. The plugin leaves it untouched. Open the Advanced tab to replace it if you want to.

No. The database and update pages never depend on it, and the PHP error page works without it as long as PHP does not print errors on screen, which is the normal configuration of a live site. There is one combination WordPress cannot handle: errors printed on screen (usually because WP_DEBUG and WP_DEBUG_DISPLAY are enabled) together with output buffering off. PHP then sends the raw error and the headers before WordPress runs its handler, so no error page, branded or not, can be shown. The settings page and Site Health detect this combination and explain the two fixes: disable WP_DEBUG_DISPLAY on a live site, or set output_buffering to 4096 in the PHP configuration.

Only if you turn on the email alert, and only to the address you choose. The alert is sent by your own server. Nothing else leaves it: there is no tracking, no update check and no external asset.

While the database is down WordPress cannot run, so the alert is sent with the mail function of PHP, not through your email plugin. Some hosts block it and some inboxes file it as spam. Use the test button in the Database error tab: the test travels exactly the same way. The report sent once the site is back goes through WordPress, like your other emails. It leaves once the error page has not been shown for about ten minutes, at the next scheduled check or as soon as someone opens the admin.

The date, the page and the HTTP status, once a minute at most, each time a visitor sees one of the pages. For a PHP error page, also the error behind it, as WordPress hands it over: its message, file and line, and the stack trace without the values passed to the functions. Paths start from the WordPress folder. Offair records nothing about the visitors themselves, but an error message may repeat what a request sent when the plugin in cause puts it there: control characters are removed and each errors file is limited to 1 MB. The full history, with the errors, is for administrators: Tools, Outage history, or wp offair history. The dashboard widget, off by default, shows the outages of the last 30 days to the roles you choose, without the errors. It is kept for 180 days and removed when the plugin is uninstalled. An outage while nobody visits the site cannot be seen.

Its name cannot be guessed, and it holds an .htaccess file that refuses web access, which Apache and LiteSpeed apply. Nginx ignores .htaccess files: add location ~* /uploads/offair/private- { deny all; } to the server block of the site. Tools, Site Health warns you when the folder can be read from the web.

Yes. Add offair/db-error.php, offair/maintenance.php or offair/php-error.php to your theme or child theme. The drop-in looks in the active theme, then in its parent theme, and uses your template instead of the built-in page. If a template throws an error, has a syntax error or prints nothing, the built-in page is shown instead. WordPress is not loaded when these pages are shown, so a template can only use plain PHP. The drop-in has already sent the HTTP status and the no-cache headers. After a fatal error during a REST or admin-ajax.php request, the drop-in answers with JSON or plain text, as WordPress does, and the template is not used. The path is checked against wp-content/themes, so a theme stored elsewhere cannot provide templates. On a network, the templates come from the theme of the site asked for. The template prints the whole HTML document and receives one array, $offair:

• screen: db, maintenance or php.
• status: HTTP status sent, 503 or 500.
• lang: language of the site, for the lang attribute.
• site_name, show_name: displayed name and whether to show it.
• title, paragraphs, button: title, message split into paragraphs, label of the retry button (empty when hidden).
• contact: contact line, as parts with a text and, for links, an href.
• meta: incident line, with the local time filled in (empty when hidden).
• notice, detail: recovery mode notice and technical details of a PHP error, when WordPress would show them.
• refresh: automatic refresh delay in seconds, 0 when off.
• logo, logo_dark, favicon: logo and logo for dark backgrounds (src data URI, width, height) or null, favicon data URI or empty. An SVG logo is embedded as it is: show it in an <img> element, where its scripts do not run, never in <object> or <iframe>.
• colors: primary, primary_hover, primary_text (readable on white), primary_dark (readable on the dark surface), on_primary, background.
• heading_font, ornament: serif or sans, and wave, line or none.
• layout, color_scheme: card, minimal, split or banner, and auto, light or dark.
• head: built-in <head> content (meta tags, refresh, title, favicon and styles).
• main: built-in <main class="offair-page"> markup, arranged by the styles for the chosen layout.
• body_class: classes the built-in page puts on <body>, which the styles rely on.
• css: built-in stylesheet.
• escape: function that escapes a value for HTML.

Only if MainWP Child is active on the site and the MainWP Dashboard you connected yourself asks for it, which it does when the Offair for MainWP extension is installed there. The data travels in the synchronization MainWP already runs and authenticates. Offair makes no request of its own. It sends the version of the plugin and the outages of the last 90 days: the page, the start, the end and the HTTP status. The history holds nothing about your visitors.

Yes. The drop-ins are shared by every site of the network, so the settings live in the network admin under Settings, Offair. Each site still gets its own page, found from the address the visitor asked for: its title, its logo or site icon, its language, its timezone and the templates of its own theme. The design, the colors and the texts are shared by the network.