# Divi Essential Licensing — Policy Pivot Spec
**Release version:** 5.5.1 (still)
**Date:** 2026-04-19
**Status:** Supersedes frontend-lock behavior in [2026-04-19-licensing-system-design.md](2026-04-19-licensing-system-design.md)
---
## Why this revision exists
The original licensing spec locked modules at the render layer — unlicensed users saw blank space or placeholders on the frontend, and the builder palette hid DE modules. This had two problems:
1. **Breaks live customer sites on license lapse.** If a paying customer's license expired while their site was in production, visitors to their site would suddenly see blank sections. Support tickets would cascade.
2. **Over-broad scope.** The lock affected both "can this visitor see the module" and "can the admin add/edit modules." These are separate concerns that deserve separate answers.
User's revised policy, stated directly:
- **No license / expired / revoked:** user cannot edit DE modules, but modules stay visible on the frontend.
- **Active license:** full access.
This pivot moves the lock from the render layer to the builder edit layer. Live sites keep working no matter what the license says. The lock only affects actions taken inside the Divi Builder (adding new modules, editing existing ones).
---
## New state → behavior mapping
| State | EDD status | Frontend render | Builder palette (add new) | Builder edit (existing) | DE admin pages |
|---|---|---|---|---|---|
| `LICENSED` | `valid` | ✅ renders | ✅ allowed | ✅ allowed | accessible |
| `GRANDFATHERED` | `expired`/`disabled`/`revoked`, pin ≥ version | ✅ renders | ❌ hidden | ❌ **blocked with message** | accessible (so they can renew) |
| `LOCKED_BYPASSED` | `expired`/`disabled`/`revoked`, pin < version (ZIP upload) | ✅ renders | ❌ hidden | ❌ blocked with message | accessible |
| `LOCKED_MIGRATION` | `missing`/`invalid`, 30-day grace active | ✅ renders | ✅ allowed | ✅ allowed | accessible |
| `LOCKED` | `missing`/`invalid`, no grace | ✅ renders | ❌ hidden | ❌ blocked with message | **redirect to license page** |
| `LOCKED_STALE` | last verified > 14 days ago | ✅ renders | ❌ hidden | ❌ blocked with message | accessible |
**Two important changes from the original spec:**
1. **`GRANDFATHERED` tightens from "full access" to "view-only in builder."** Paying customers whose license lapsed can still see their modules on live sites but cannot edit them until they renew. Renewal restores full access.
2. **Frontend rendering is unconditional.** All the PHP-side render gating from the original spec is removed.
**Migration grace (`LOCKED_MIGRATION`) deliberately retains full access** — that's the whole point of the 30-day window. Without it, existing unlicensed installs would suddenly lose builder access on the 5.5.1 upgrade.
---
## Code deltas from current (post-Task 15) state
### Reverts (restore frontend rendering)
- [divi-5/server/Modules/Modules.php:147-157](../../../divi-5/server/Modules/Modules.php) — remove the early-return gate. Modules always register on the PHP side.
- [divi-5/divi-5.php](../../../divi-5/divi-5.php) — remove both the `divi_module_wrapper_render` filter and the `the_content` shortcode-strip filter. No frontend lock at all.
- [divi-essential.php:102-116](../../../divi-essential.php) `dnxte_register_module()` — remove the `should_register_modules()` gate. Divi 4 modules always register.
### Gate predicate tightening
In [includes/License/Gate.php](../../../includes/License/Gate.php), the current `is_locked()` predicate serves two different purposes that now need to diverge:
- **Builder lock** (blocks editing DE modules) — tightens to include `GRANDFATHERED`.
- **Admin-page redirect** (bounces DE admin pages to license page) — narrows to only `LOCKED`, so grandfathered users can still reach the dashboard to click "Renew."
**Resolution:** rename `is_locked()` to `is_builder_locked()` with the tightened semantics, and introduce a new `needs_license_page_redirect()` predicate for the Menu.php guard.
```php
/**
* Returns true if the user should be blocked from editing DE modules
* in the builder. Grandfathered users are blocked here even though
* their existing content still renders on the frontend.
*/
public static function is_builder_locked() {
$state = self::get_effective_state();
return ! in_array(
$state,
[ self::STATE_LICENSED, self::STATE_LOCKED_MIGRATION ],
true
);
}
/**
* Returns true only when the user has never held a valid license and
* is out of migration grace. Only these users get bounced off DE
* admin pages to the license activation form; grandfathered users
* keep dashboard access so they can renew from anywhere.
*/
public static function needs_license_page_redirect() {
return self::STATE_LOCKED === self::get_effective_state();
}
```
| Old call site | New call |
|---|---|
| `Gate::should_render_module()` | **delete** — rendering is unconditional |
| `Gate::should_register_modules()` | **delete** |
| `Gate::is_locked()` | replace with `Gate::is_builder_locked()` for edit-gate callers, `Gate::needs_license_page_redirect()` for Menu.php |
| `Gate::extensions_enabled()` | keep as-is — extensions still gated on `is_builder_locked()` semantics |
| `Gate::placeholder_html()` | **delete** — no frontend placeholder anymore |
### Visual builder — swap palette gate + add edit-block wrapper
[divi-5/visual-builder/src/index.ts](../../../divi-5/visual-builder/src/index.ts)'s `addAction` callback currently skips registration entirely when locked. Change to:
1. **Always register modules** (so existing modules on pages can be opened in the builder and inspected).
2. **If not LICENSED and not LOCKED_MIGRATION, wrap each module's `renderers.edit` in a license-gated HOC** that shows a lock overlay (UX spec below).
3. **If not LICENSED and not LOCKED_MIGRATION, skip the module from the library palette** — the `registerModule()` call still runs, but we pass a `hideFromLibrary: true` flag *if Divi 5 supports it*. If not, use a client-side filter on module library list.
The distinction: "register the module definition" (so existing instances can be displayed) vs "show it in the palette" (which we want hidden). These are separate in Divi 5's architecture — registration is universal, palette inclusion is filtered.
**Exact approach:**
```typescript
const LICENSE_ACTIVE_STATES = new Set(["LICENSED", "LOCKED_MIGRATION"]);
function isBuilderLocked(): boolean {
const state = window.divi_essential?.licenseState;
return !!state && !LICENSE_ACTIVE_STATES.has(state);
}
function wrapEditLocked(OriginalEdit: React.ComponentType
, moduleLabel: string) {
return function LockedEdit(props: P) {
return isBuilderLocked()
?
: ;
};
}
// In the addAction callback, replace the current `if (!allowRegistration) return;`
// with per-module wrapping:
Object.entries(moduleMapping).forEach(([moduleKey, moduleComponent]) => {
if (inactive_modules.includes(moduleKey)) return;
const register = (component: any) => {
if (!component || !("metadata" in component)) return;
const rest = omit(component, "metadata");
const moduleLabel = component.metadata?.settings?.title ?? moduleKey;
const wrappedRenderers = {
...rest.renderers,
edit: wrapEditLocked(rest.renderers.edit, moduleLabel),
};
registerModule(component.metadata, { ...rest, renderers: wrappedRenderers });
};
if (Array.isArray(moduleComponent)) {
moduleComponent.forEach(register);
} else {
register(moduleComponent);
}
});
```
**Palette hiding — primary approach: CSS.** When `isBuilderLocked()` is true, inject a `