| 1 |
--- |
| 2 |
module: beaver-builder |
| 3 |
--- |
| 4 |
|
| 5 |
# beaver-builder |
| 6 |
|
| 7 |
## Responsibility |
| 8 |
|
| 9 |
Owns the CartFlows-specific Beaver Builder integration: four `FLBuilderModule` subclasses plus their BB settings forms, per-node CSS, and an editor-compatibility shim. |
| 10 |
|
| 11 |
Ownership stops at the shortcode boundary — the modules render `[cartflows_checkout]` / `[cartflows_optin]` / `[cartflows_order_details]` and only *steer* the real step modules by pushing values through `cartflows_*_meta_*` filters. None of the actual checkout/optin/thank-you behaviour lives here. |
| 12 |
|
| 13 |
## Why it is this way |
| 14 |
|
| 15 |
Settings reach the renderer through filter closures registered at render time rather than by direct call, because the shortcodes read step meta rather than accepting arguments. That indirection is why the closures are never removed and why two modules of the same type on one page interfere. |
| 16 |
|
| 17 |
Enablement depends on a request-scoped static cache of the step type plus a two-entry-point loader (`wp` and `admin_init`, both at priority 8), which is also why a plain `admin-ajax.php` request loads none of this. |
| 18 |
|
