Gravity Forms Module

v26.07.05Updated: 31/07/2026

[team_mw]
v26.07.05

  -26.07.05: drop class=’spinner’ from the module’s

tag

CSS class selectors match

elements, so any bare global `.spinner` rule
on the page applied to this tag. Postmaster (the Ajax Load More fork) ships
exactly that in core/dist/css/ajax-load-more.css, printed inline for the
load-more button's :

.spinner { display: block; animation: spin 0.6s ease-out infinite; }

display:block on a

element makes the browser render its text content,
so on any page carrying both a GFM Divi form module and an ALM listing the raw
CSS appeared as visible, rotating page content beside the form. Confirmed live
on bcmc.solutions, 17 of 18 /locations/ pages affected; a site-level
`style.spinner { display: none !important; }` override was applied there as a
stop-gap on 2026-07-31 and becomes a harmless no-op once this ships.

The class was never a hook. Nothing in this plugin referenced it, and a sweep of
69 fleet sites' public HTML and Divi/theme CSS found no `style.spinner` selector
anywhere except that stop-gap. The CSS inside the tag is unchanged.

Co-Authored-By: Claude Opus 5

v26.07.06

  -Bump plugin version to 26.07.06

v26.07.04

  -26.07.04: install into the directory the plugin already occupies, whatever the zip is called

Fixes a fleet-wide upgrade hazard found while migrating team.makeweb.com.au.

This plugin exists under two directory names across the fleet:
gravity-forms-module (every site that never left the legacy update server, about
25 of them) and Gravity-Forms-Module (anything installed from the CI artifact,
whose zip has a capital top-level folder, about 11). WordPress derives the install
destination from the zip’s top-level folder name, so a mismatch does not upgrade
the plugin at all. It extracts a SECOND copy alongside the first, leaves the
original directory orphaned, and leaves active_plugins pointing at a path that no
longer holds the new code.

That is how barabarang ended up with two copies, and it reproduced exactly on
team.makeweb.com.au: a lowercase install pulled the capital CI zip, WordPress
reported the upgrade as successful, and the active plugin file went MISSING. The
release’s own verification caught it and rolled back.

Serving matching casing per channel is not enough on its own, because the one-hop
migration deliberately moves legacy sites onto the makelabs channel, where the zip
is capital while their directory stays lowercase. So every migrated site would
break on its NEXT update.

gfm_match_upgrade_source_to_installed_dir() hooks upgrader_source_selection and
renames the unpacked source to match this plugin’s own installed directory, making
it indifferent to either server’s casing. It only acts when this plugin is the one
being upgraded, passes WP_Error through untouched, and if the rename fails it
returns WP_Error to abort rather than silently creating a duplicate directory.

Verified against both installed casings, matching and mismatching zips, another
plugin upgrading, a theme/core upgrade with no hook_extra, WP_Error passthrough,
and a refused rename.

Co-Authored-By: Claude Opus 5

v26.07.03

  -26.07.03 hotfix: rename the prop() helper, which fataled every Divi site on 26.07.02

26.07.02 is broken and must not be installed. The prop() helper added in that
release narrowed an inherited method: Divi’s ET_Builder_Element already declares
“public function prop( $prop, $default = null )”, and declaring a protected
prop() in the subclass makes PHP reject the class at declaration time with
“Access level to ET_Builder_Module_MW_Gravity_Forms::prop() must be public”.
includes/module.php loads on et_builder_ready, so this fataled any Divi site the
moment it rendered, which is effectively every site running this plugin. Caught
on team.makeweb.com.au during the first legacy upgrade.

Renamed to gfm_prop() rather than widening to public, because overriding Divi’s
own prop() accessor would change behaviour for any Divi code that calls it.
decode_font_icon() was checked and does not collide.

Why the 26.07.02 tests missed it: the stub-WordPress load harness requires the
main plugin file, but includes/module.php is pulled in on et_builder_ready and
the stub add_action never invokes callbacks, so the Divi subclass was never
declared and no base class was present to conflict with. Added
module_collision_check, which parses the real ET_Builder_Element (328 methods)
and compares visibility of every method the module declares. Verified it fails on
the pre-fix file and passes on this one.

Co-Authored-By: Claude Opus 5

v26.07.02

  -26.07.02 audit release: PHP 8 readiness, GF 2.x and 3.x compatibility, collision safety

New standard release, replacing the 1.4.x line and moving to the MakeWeb
YY.MM.NN scheme. Supersedes 26.07.01, which never registered because a CI repack
step failed the build job; the repack is now continue-on-error so it cannot block
version registration again. This is the version for BOTH update servers, so
legacy sites still pointed at updater.makeweb.com.au can move off 1.3.06.

Correctness
– Non-ASCII submit labels were being corrupted. The old DOMDocument
loadHTML()/saveHTML() round-trip carries no charset hint, so libxml assumed
ISO-8859-1 and a label containing an arrow or accented text came back as
mojibake. The button path now rewrites only the opening tag, so label bytes
pass through untouched.
– gfm_set_button_attributes() no longer risks handing null back to Gravity Forms
if preg_replace_callback fails.
– Button handling is explicit about both generations it must support:
GF 2.x “” and the malformed GF 3.x
“. Verified against real markup from both.

PHP 8 readiness
– Replaced mb_convert_encoding(…, ‘HTML-ENTITIES’) with html_entity_decode().
mbstring’s HTML entity handling was deprecated in 8.2 and is on the way out.
Output is byte-identical.
– Declared makeUpdate::$licence_key. It was assigned but never declared, so
every admin request on PHP 8.2 or newer raised “Creation of dynamic property
makeUpdate::$licence_key is deprecated”. 21 MakeWeb plugins vendor this same
file and all share the issue; the upstream makeUpdate repo still needs it.
– All $this->props[…] reads go through a prop() helper, so absent Divi props
no longer emit undefined-key warnings.
– libxml_use_internal_errors() is restored to its prior value rather than left
switched on globally.
– Declared Requires PHP 7.4 and Requires at least 5.6.

Collision safety
– Every global function sat on a generic name (input_to_button, spinner_url,
ugc_fix, child_plugin_has_parent_plugin, child_plugin_notice,
maybe_auto_login). A second plugin declaring any of them fatals the site.
Implementations now carry a gfm_ prefix. Legacy names are still declared as
delegating aliases when nothing else owns them, and hooks target the legacy
name only when it is ours, so an existing
remove_filter(‘gform_submit_button’, ‘input_to_button’) keeps working while a
real collision degrades safely instead of white-screening.

Removed
– deploy.php. It shipped with no ABSPATH guard, was reachable at
/wp-content/plugins/…/deploy.php on every site, and required a vendor path
that was never shipped, so requesting it only ever produced a fatal.
– Six stylesheets shipped but never enqueued: basic.min.css, formsmain.css,
gforms.css, gforms_builder.css, theme-fixes.css, divi_fixes.css.
basic.min.css was enqueued under the same ‘gforms’ handle as
radio_btn_style.css on the same hook, which is a no-op, so it never loaded
anywhere. Confirmed across all 37 sites running this plugin that
radio_btn_style.css is the only one ever requested. Zip drops 66KB to 28KB.

Other
– Hardcoded /wp-admin/ link replaced with admin_url(); malformed
target==”_blank” fixed.
– Focus colour escaped before it reaches a CSS declaration.
– Asset version follows the plugin version instead of a stale hardcoded 1.3.04.
– CI additionally builds and uploads a lowercase-folder zip, which is what the
legacy update server should serve so those sites upgrade in place instead of
ending up with two plugin directories.

Co-Authored-By: Claude Opus 5

v1.4.16

  -fix empty submit button under Gravity Forms 3.0; bump plugin version to 1.4.16

GF 3.0 emits a malformed submit control – “” – with a
self-closing slash left over from the old markup. Browsers ignore it, but
DOMDocument’s HTML4 parser reads the element as empty and parses the label as a
sibling, so add_custom_css_classes()’s loadHTML()/saveHTML() round-trip returned
” and the label vanished. Replaced the round-trip with
mw_gfm_set_button_attributes(), which rewrites only the opening tag and leaves
the label and any nested markup untouched. Also applies the Divi button classes
on the GF3 path of input_to_button(), which previously returned the button
unchanged and so dropped styling from forms rendered outside the Divi module.

Hardened the deploy webhook with toJSON() so multi-line commit messages can’t
break version registration.

Co-Authored-By: Claude Opus 5

v1.4.15

  -bump plugin version to 1.4.15

v1.4.13

  -extended focus styles for additional input types

v1.4.12

  -Deprecated default removed

v1.4.11

  -error borders cant be transparent

v1.4.10

  -better label styling

v1.4.09

  -fix field border targeting for new GF update

v1.4.08

  -added styling for select box borders

v1.4.07

  -added styling for conformation msg

v1.4.06

  -Added important to padding and margins

v1.4.05

  -tweaks in code before refactor

v1.4.04

  -cursor on submit button

v1.4.03

  -cursor submit button

v1.4.02

  -general tidy2

v1.4.01

  -general tidy

[download_plugin]