5.1.0
03-09-2026New
- A form styler for WS Form, in both builders — the twelfth, taking the free library to 68 modules. WS Form was assessed once before and set aside as unstylable, because it is the only one of the twelve that renders no fields in PHP at all: its shortcode returns an empty `
element and its own JavaScript builds the form in the browser. That turns out not to matter on a published page, where the script has run long before anyone sees it, so the styler's CSS applies to the form exactly as it does for every other plugin. What it does affect is the builder, which would otherwise show an empty box with nothing to style. Ninja Forms, the other plugin that builds its form in the browser, prints the field definitions inside the markup its shortcode returns, and its preview is rebuilt from those; WS Form carries no such payload anywhere — only a form id — so the preview is rebuilt from WS Form's own PHP instead. It is a reconstruction rather than the live form: WS Form does offer a public function that would populate the container, but calling it would start a working form inside the page you are editing, with its own validation and submissions, which is not what a styler wants on a canvas. Every one of the twelve design groups has something to aim at, including the per-field validation message and the required-field marker that most of the sibling stylers have to improvise. WS Form marks parts of its own styling!important`, including forcing the placeholder colour transparent when labels sit inside their fields, so the field, label, description and button styles answer with Divi's own important flag rather than a longer selector that could not win. - An extension's settings now have a screen of their own rather than a dialog. Six settings whose choices each need a paragraph to explain did not fit in a modal — it scrolled before it was finished. The gear on an extension's card is a real link now, so a settings screen can be bookmarked, opened in a new tab, or sent to somebody by support.
- The settings on that screen are drawn from a description the server sends, not from a panel written for one extension. Login Experience's four page assignments used to be hard-coded into the admin bundle, which does not generalise: an extension belonging to Squad Modules Pro could not appear there without this plugin carrying knowledge of a plugin that may not be installed. An extension now advertises its own settings endpoint, the gear appears on its card, and the screen renders whatever the endpoint describes — so a premium extension can add a setting without a new build of the free plugin. A control this version does not recognise is skipped rather than guessed at, which is the case of an older free plugin being asked to draw a newer premium one's field.
Fixed
- Enabling an extension from the extensions screen, reading an extension's details, and the list of every extension with its active state all quietly did nothing. The registry is a list, and six places looked entries up by name as though it were keyed by one, so each lookup missed. The list of every extension with its active state was the worst of them: it read the list's numeric index as an extension name and passed it where a name was required, which threw and was swallowed, so it returned nothing at all on every site. A registry entry is now found by its name wherever it is needed.
- Premium extensions appeared twice on the extensions screen when Squad Modules Pro was active. Both plugins register an entry under the same name — the free plugin an advertisement, Pro the real thing — and nothing reconciled them. The one with an implementation now wins, and keeps the position the list already had so turning Pro on no longer reorders the screen. The same guard covers the module registry, which has no duplicates today but is built the same way.
- Three of the four Quick actions on the dashboard led nowhere. Leave a review, Get support and Join the community rendered as ordinary links with nothing behind them — the tiles asked for addresses the plugin never sent. All four work now, and support goes where it should: the WordPress.org forum for this plugin, and priority support when Squad Modules Pro is active.
- A script or stylesheet whose file is missing is no longer handed to WordPress. It used to be requested anyway, so the browser fetched a file that was not there, nothing was written to the log, and the only symptom was whatever depended on that bundle silently not working. The file is now checked first and skipped with a warning naming the handle. Assets loaded from another server are not on disk and are unaffected.
Compatibility
- WordPress 7.1 is declared as tested. Every change in the 7.1 field guide was checked against the code rather than assumed: the iframed post editor (this plugin has no post- or block-editor integration — Divi 5 modules are Divi blocks, registered through Divi's own API), the
@wordpress/componentschanges (the package is not used), jQuery UI 1.14.2 (no dependency), and the persistent toolbar (nothing is added to it).
Developer
- A Divi 5 module belonging to another plugin can point at its own build directory. Resolving that folder used to be one line inside the registration method, so the premium plugin overrode the whole method in all 29 of its modules — and lost the wrapper this class puts around the render callback. Two things live in that wrapper: dynamic-content resolution, without which a field renders its raw token instead of the value it stands for (21 of those 29 modules declare such fields, and none of them resolved), and the recording of the block name, which was empty for every one of them. The folder is now its own overridable step.
- A module that extends Post Grid gets CSS for the design groups it declares, on the page and on the canvas alike. Both sides used to write out a fixed list of seven groups, which is correct for Post Grid and the wrong shape for a module built on it: a subclass's own groups had fields in the Design tab and no CSS anywhere. The list is now read from whichever module is rendering.
- The preset-bucket guard finds a field's boundaries by counting braces instead of matching to the next quoted key, so a field whose value contains a nested object is no longer mistaken for its neighbour.
- The end-to-end design suite rebuilds a module's generated metadata when it no longer matches its source. Divi 5 reads a module's selectors at render time from the built copy rather than the source, and that copy is not in version control, so it drifts — and a stale one makes Divi write those design groups with no selector at all. The suite then reports them as not applying, which is indistinguishable from a real styling bug and cost a full investigation. The check compares content rather than timestamps, because the build leaves an unchanged file alone.
yarn test:e2e:prepare --enable-registrationturns public registration on for a fixture site, so the Register Form module renders its form instead of its "registration is disabled" notice and its six design groups can be measured. Opt-in on purpose: the fixture generator will not open a site to public sign-ups on its own.