3.5.0 taught your AI to speak Forms and SEO. 3.6.0 goes after something closer to home: the Elementor addons you already build with.
If you use Essential Addons, Premium Addons or Ultimate Addons, your agent had a blind spot you may never have noticed. It could see every widget Elementor itself ships, and not one of the hundreds your addon packs installed. Ask for a pricing table and it would dutifully hand-build one out of containers and headings, while a finished Essential Addons pricing widget sat right there, unused.
That’s fixed.
Why it was a discovery problem, not a placement problem
Here’s the thing that surprised us while building this: placement already worked.
Addon packs register their widgets into Elementor’s own widget registry. EMCP’s add-free-widget reads that registry. So the moment we tested it, eael-fancy-text dropped onto a page perfectly, no new code required.
What was missing was that the agent had no way to know it existed. list-widgets serves EMCP’s curated catalog of core widgets, so eael-pricing-table and premium-addon-banner were invisible.
So Essential Addons and Premium Addons each get exactly one tool, and it’s a discovery tool. The workflow is discover, inspect, then place with the ordinary widget tool you already use. We deliberately did not add a second placement path, because duplicating a code path that already works is how integrations rot.
This means the domain breaks our usual Read/Write pattern, and that’s intentional.
Addon widgets are enormous
One number reframed the whole design. On a stock install:
eael-pricing-table: 456 controlseael-adv-accordion: 467 controlspremium-addon-banner: 391 controls
Hand all of that to an AI and you don’t get a better result, you get a drowned context window and an agent that has forgotten your actual instructions by the time it reaches the end.
So get-widget-schema filters to content-bearing controls by default: the ones holding your headings, prices, images, links and repeater rows. Sliders, colour pickers and popover toggles are skipped. Every response reports total_controls alongside shown, so you always know when you’re seeing a subset, and full: true gives you everything when you genuinely need a styling control name.
One hard-won rule made it into the agent skill: never guess a control name. Elementor stores any settings key you send without complaining. A wrong name looks like it worked and silently does nothing.
Ultimate Addons does double duty
Ultimate Addons for Elementor, which you may still know as Header Footer Elementor, turned out to be two plugins wearing one coat. It registers widgets like the packs above, and it stores your header, footer and block templates with display conditions.
So it’s the one integration here with a full Read/Write pair. Your agent can discover and place its widgets, and it can create a header, decide exactly where it appears, retarget it later, or delete it. You describe where you want it; the display conditions get handled.
The template record and its content stay separate steps, deliberately. create-template makes the record and hands back an ID; you then build the actual header with the same Elementor tools you’d use on any page. One way to build things, not two.
Because a bad header affects every page on your site, the write tool ships disabled by default and deleting a template requires explicit confirmation.
One header, not two
If you run both EMCP Themer and Ultimate Addons, you previously had a coin flip over which header won, and the loser looked like a bug.
EMCP now tells you there’s a conflict, and resolves it while you decide: Themer takes priority, per slot. Where Themer has a matching template, its header renders and Ultimate Addons’ is skipped. Any slot Themer doesn’t claim still renders from Ultimate Addons, so an existing footer keeps working.
That per-slot detail matters. Blanket-disabling the other plugin would have silently deleted a working footer to fix a header problem. And if resolution ever fails, we fail toward rendering, because a bug in conflict handling should never leave a site with no header at all.
The bug that locked people out
A handful of people hit a white screen on wp-admin after 3.5.1, and the cause was genuinely strange.
Our malware scanner was being quarantined by other malware scanners.
A malware scanner has to contain the signatures it hunts for, spelled out as plain strings: the webshell names, the obfuscated-execution patterns. Some hosts’ security scanners read that file, concluded it was a webshell, and quarantined it. Quarantining zeroes a file in place, so the file still existed, PHP’s require_once still succeeded, and the class was simply never defined. The error surfaced somewhere else entirely.
Two fixes, because one addresses the cause and the other addresses the blast radius.
The signatures are now assembled at runtime, so no intact signature sits on disk for a scanner to match. Detection is unchanged, and a test pins the compiled patterns as byte-identical.
More importantly: a single missing file can no longer take down your admin. Registering a tool shouldn’t build a scan engine, so that now happens lazily, and tool registration is guarded so one unavailable group degrades to those tools being absent. Nobody should be locked out of their own site over one tool.
If you were affected, update and reactivate. And it’s worth checking your host’s quarantine log, both to confirm the diagnosis and to allowlist the plugin.
Get it
3.6.0 is live. Free users can update from Dashboard → Updates; Pro updates through your license as usual.
The Elementor Addons integrations are Pro, and each appears only when its plugin is active, so you’ll see tools for what you actually run and nothing else.