Imedes Preflight

Description

Imedes Preflight combines a more resilient public URL structure with early request qualification for WordPress.

A normal WordPress 404 can require WordPress, plugins, the theme and database queries to run before the request is finally known to be invalid. Preflight can move that decision much earlier. In Final Mode, invalid public GET/HEAD requests can be rejected from the MU runtime before normal plugin and theme processing, reducing unnecessary PHP, database, CPU and memory work.

Preflight also gives public resources a stable identity while preserving a human-readable semantic URL. It appends a resource-specific delimiter and numeric ID to public Post, Term and Author URLs. For example, a Post URL can end in:

/example-title/:-:123/

Terms and Authors use their own delimiters and IDs. The semantic part remains readable, while the numeric identity gives Preflight a stable way to identify the intended resource.

This has an important practical advantage: if the semantic part of a valid Preflight URL is misspelled, stale or has changed, the stable resource ID can still identify the intended resource. Preflight can then redirect the request to the current canonical URL instead of automatically losing the visit to a 404. This can reduce traffic loss caused by damaged, outdated or incorrectly reproduced semantic URL paths.

A simple example shows the difference. Assume the current canonical resource is:

/example-title/

Without Preflight, a damaged link such as:

/exampl-title/

contains only the semantic path. If WordPress cannot infer which resource was intended, the request ends in a 404 and the visit is lost.

With Preflight, the equivalent public URL contains a stable resource identity:

/example-title/:-:123/

If an external link damages only the semantic part but keeps the identity:

/exampl-title/:-:123/

Preflight can still identify resource 123, compare the requested path with the stored canonical path and issue a 301 redirect to:

/example-title/:-:123/

The readable part can therefore be wrong while the resource itself remains deterministically recoverable. The same principle also helps when a semantic path becomes stale after a URL change: the stable identity does not depend on the wording of that path.

The underlying URL principle is not experimental. Combining a human-readable semantic component with a stable numeric resource identity has been used successfully in production systems for decades. Preflight applies that proven principle to WordPress so URLs can remain readable while also becoming deterministically identifiable. That stable identity is what makes both canonical recovery and early request qualification possible.

Static files such as images, CSS, JavaScript and fonts are outside Preflight’s resource-identity model. Preflight keeps missing requests for these file types out of its Observation statistics and, on compatible rewrite-based servers, lets the web server finish them without sending them through the normal WordPress front controller. This matters because a missing static file can otherwise fall through the normal WordPress rewrite path and trigger a complete WordPress request just to end in a 404. Sites with stale image references, removed media or crawlers requesting old asset URLs can therefore avoid a surprising amount of unnecessary PHP, plugin, theme and database work.

Preflight does not switch this behavior on immediately. It uses a staged lifecycle:

1. Observation – no public URL change. Preflight measures the real cost of WordPress 404 handling.
2. Migration – stable Preflight resource identities are added to generated public URLs while native URLs remain reachable and are redirected forward.
3. Final – the Resource Index becomes authoritative for non-excluded public GET/HEAD requests, enabling early 404/410 decisions and canonical redirects before normal plugin and theme processing.

WordPress attachment pages are outside Preflight’s resource-identity model. If public attachment pages are enabled when Final Mode starts, Preflight disables that WordPress setting automatically and remembers the previous state. The original setting is restored when Re-Migration returns the site to native WordPress behavior.

Preflight currently requires an Apache or LiteSpeed/OpenLiteSpeed web-server environment with working .htaccess rewrite support. NGINX-only environments are not supported. The Migration and Final requirement tests verify the detected web server before productive Preflight modes can be enabled.

Because Migration changes the public URL contract of a site, Preflight includes a protected Re-Migration path for returning to native WordPress URLs. A verified standalone legacy redirect can remain after Preflight is removed so previously published Preflight URLs continue to reach their native counterparts.