MV SpeedWeave 1.0.1 - directory review notes

Submit only the mv-speedweave Free ZIP to WordPress.org. This edition has no
license checks, external updater, time limits, account requirement, disabled
premium controls or premium feature implementation. All included functionality
works without payment. Pro is a separate companion distributed outside the
directory. The Free readme describes it once for clarity.

Free makes no external HTTP API requests and performs no telemetry. Support
links open only when the administrator clicks them. Explicit preconnect hints
use administrator-selected HTTPS origins for public-page resources.

Settings and actions require manage_options and a POST WordPress nonce. JSON
imports have a 64-KB limit, exact product/schema validation and per-key
sanitization; they start paused. All displayed settings are context-escaped.

Page caching starts off. Caching uses an explicit public-path manifest plus
optional public blog posts. Requests with cookies, queries, authentication,
nonces, private paths, ranges or no-cache directives bypass it. Responses with
forms, detected security tokens, private headers, errors or redirects are not
stored. Custom personalized routes must be explicitly excluded. Early hits
occur before plugin filters; that limitation is in the readme.

The early reader is optional, never replaces a foreign advanced-cache.php and
requires the administrator to set WP_CACHE. The plugin does not edit
wp-config.php, Apache's main configuration, Redis or PHP settings. On detected
WordPress.com-managed hosts, caching and installation of the reader are blocked.

Filesystem exception rationale

includes/class-mvsw-cache-runtime.php is deliberately standalone: an early
cache hit happens before WordPress and WP_Filesystem load. Its documented
AlternativeFunctions exception covers confined native I/O, flock and atomic
rename, not input validation or security checks. Cache data is authenticated AES-256-GCM encrypted JSON, using keys derived
from configured WordPress authentication keys. Config and pages use .json, the
lock is empty write.lock, and index.php is empty. Direct HTTP access never
reveals cache contents, even on servers that ignore .htaccess. The reader does not evaluate cache data. It rejects symlinks,
validates hashes, generations and sizes, uses a bounded directory and cannot
overwrite an unrelated early reader. Cache invalidation and writers share a
lock. Deactivation/uninstall disable the reader and do not recreate the cache
at shutdown. Once WordPress is loaded, administrative file writes and cleanup
use WP_Filesystem_Direct; atomic hard-link publication additionally prevents a
race from overwriting a newly installed foreign reader.

Other narrow annotations

* Cached HTML is intentionally replayed without HTML escaping after both
  storage and read validation. Escaping a complete page would corrupt it.
* REQUEST_URI must retain encoded route bytes for canonical/path validation.
  It is never printed. Import JSON and settings arrays are validated immediately
  with the dedicated schema and per-key sanitizers.
* var_export is used only to reconstruct the previous 1.0.0 reader for exact
  ownership comparison. That historical string is never written or executed.
  The new optional advanced-cache.php is a byte-for-byte copy of the bundled
  runtime source; no dynamic PHP is generated. Its __DIR__ resolves the real
  content directory before WordPress loads. After bootstrap, wp_content_dir()
  on WP_Filesystem resolves customized content paths. The content/cache
  location is necessary for the early reader and is the cache-plugin exception
  described in the review; this is not an uploads/media directory.
* The bounded prepared SELECT for expired transient timestamps requires fresh
  expiration data. WordPress delete_transient() performs the actual deletion.
  No customer content, orders, revisions or active transients are removed.

Source is complete, readable and GPL-2.0-or-later. Free includes no bundled
third-party libraries or generated/minified script.
