|
| 1 | +# Figma to WordPress |
| 2 | + |
| 3 | +`plugins/figma-to-wordpress` moves a Figma file into WordPress. It hands the design to a WordPress runner service that creates a Playground session and imports the result with Static Site Importer and Blocks Engine. |
| 4 | + |
| 5 | +## Architecture |
| 6 | + |
| 7 | +```text |
| 8 | +Figma plugin UI |
| 9 | + -> Figma document scene data |
| 10 | + -> runner request |
| 11 | + -> WordPress runner service |
| 12 | + -> WordPress Playground session URL |
| 13 | + -> Static Site Importer / Blocks Engine inside WordPress |
| 14 | +``` |
| 15 | + |
| 16 | +The TypeScript boundary stops at request construction and opening the returned Playground URL. WordPress, PHP, Static Site Importer, Blocks Engine, and Playground session orchestration remain WordPress-side runtime concerns. |
| 17 | + |
| 18 | +## Figma Iframe Limits |
| 19 | + |
| 20 | +Figma plugin UIs run in a constrained browser context. That context is friendly to HTML, CSS, and client-side JavaScript, but it is not a normal browser tab. |
| 21 | + |
| 22 | +Practical constraints for this browser-based flow: |
| 23 | + |
| 24 | +- Cross-origin iframes can be blocked or limited. |
| 25 | +- Popup and new-tab behavior can be host-dependent. |
| 26 | +- Large WASM boot flows may not behave reliably inside the plugin UI. |
| 27 | +- Clipboard access can require user activation. |
| 28 | +- Local file URLs can behave differently between desktop Figma, browser Figma, and development builds. |
| 29 | + |
| 30 | +Because of those constraints, the primary integration shape is a service handoff: the plugin posts a runner request and opens the returned URL in a browser tab. If in-plugin embedding works later, it can consume the same runner response interface. |
| 31 | + |
| 32 | +## Playground And PHP Role |
| 33 | + |
| 34 | +WordPress Playground is the correct place to run WordPress and PHP plugin logic. It provides a browser-hosted WordPress runtime backed by WebAssembly PHP and a virtual filesystem. |
| 35 | + |
| 36 | +Static Site Importer and Blocks Engine should run in that WordPress runtime because they are WordPress/PHP import systems. The Figma plugin should not reimplement them in TypeScript. The plugin's job is to hand off design data with enough metadata for the WordPress runner to transform, install, activate, and import with those plugins. |
| 37 | + |
| 38 | +## Current Boundary |
| 39 | + |
| 40 | +Implemented now: |
| 41 | + |
| 42 | +- `GeneratedWebsiteArtifact` for static generated files from Figma. |
| 43 | +- `figma-to-wordpress/runner-request/v1` for the runner handoff plan. |
| 44 | +- A Figma UI client that posts the runner request and opens the returned Playground URL. |
| 45 | + |
| 46 | +Not implemented yet: |
| 47 | + |
| 48 | +- The hosted WordPress runner endpoint that creates the Playground session. |
| 49 | +- Post-import block validation and visual parity checks. |
| 50 | + |
| 51 | +## Local Testing |
| 52 | + |
| 53 | +From the repository root, run the plugin checks: |
| 54 | + |
| 55 | +```bash |
| 56 | +npm run check --prefix plugins/figma-to-wordpress |
| 57 | +npm run build --prefix plugins/figma-to-wordpress |
| 58 | +npm test --prefix plugins/figma-to-wordpress |
| 59 | +``` |
| 60 | + |
| 61 | +Figma development test: |
| 62 | + |
| 63 | +1. Run `npm run build --prefix plugins/figma-to-wordpress`. |
| 64 | +2. Load `plugins/figma-to-wordpress/manifest.json` as a Figma development plugin. |
| 65 | +3. Run the plugin. |
| 66 | +4. Use `Open in WordPress Playground`. |
| 67 | +5. Confirm the runner service returns a Playground URL that opens in a normal browser tab. |
| 68 | + |
| 69 | +## Next Integration Step |
| 70 | + |
| 71 | +The next meaningful step is a hosted WordPress runner endpoint with progress/error reporting around the Playground import and post-import block/visual validation. That should remain in the WordPress/Playground runner layer, not by porting PHP importer behavior into the Figma plugin. |
0 commit comments