Explore: WordPress plugin wrapper architecture

[apermo]

Context

Body Refactoring is currently a standalone PHP + vanilla JS PWA. To leverage the WordPress ecosystem for federation (ActivityPub, Friends plugin), the app needs to run as a WordPress plugin.

Key Questions (for discussion)

App Rendering

• Should the app register a custom page template that renders the full SPA?
• Or use a shortcode/block approach?
• How to avoid WordPress theme interference (admin bar, nav, footer) on the app page while keeping the clean PWA experience?

Asset Loading

• Current approach: ES6 modules with filemtime() cache busting
• WordPress expects wp_enqueue_script() — how well does this work with ES6 module graphs?
• Can we use type="module" scripts via wp_enqueue_script_module() (WP 6.5+)?

Database

• Use WordPress's $wpdb + custom tables (same schema as currently planned)?
• Or leverage wp_options / custom post meta where it fits?
• Migration handling via dbDelta() vs custom migration system?

PWA / Service Worker

• Manifest.json and service worker registration within WordPress
• Offline support: WordPress pages cached vs. app-only caching strategy?

Approach

Thin wrapper: keep the existing app code intact, plugin provides the WordPress integration layer (routing, DB, auth, federation hooks).

Open Questions

• Minimum WordPress version to target?
• Does this need its own theme, or should it work with any theme?
• How to handle the app's existing REST-style API — map to WP REST API or keep separate?