Editly for Elementor documentation

Editly 1.0.0 requires WordPress 6.0 or newer, PHP 7.4 or newer, and Elementor 3.0 or newer. Elementor must be installed and active; otherwise Editly stays inactive and shows an administrator notice.

Install Free

1. Install Editly for Elementor from WordPress.org or upload the Free zip.
2. Activate the plugin in Plugins.
3. Open Editly in wp-admin.

Install Pro

1. Download the Editly Pro ZIP from your Freemius purchase email or the Customer Portal.
2. In WordPress, open Plugins → Add New → Upload Plugin, select the ZIP, and install it.
3. Activate Editly Pro as an administrator.
4. Enter and activate your license in the Freemius licensing screen in wp-admin.
5. Open Editly and select an Elementor page.

Editly ships with English source strings and complete interface packs for German, Spanish, French, Italian, Dutch, Polish, Brazilian Portuguese, and European Portuguese. Both PHP screens and JavaScript interactions are localized.

• WordPress loads the matching Editly interface from the active site or user language.
• The same language coverage is included in Free and Pro.
• The package also includes the standard WordPress translation template (POT), so an agency or translator can create a missing locale using the normal WordPress translation workflow.
• White label in Pro changes the Editly menu name, header baseline, logo, and accent color; it does not translate client content or unsupported third-party screens.

Free and Pro do not use the same delivery model. Free follows the standard WordPress.org plugin workflow. Pro uses a commercial licensing and update flow through Freemius.

Free

• No paid license is required.
• Distribution and updates follow the normal WordPress.org path for the Free package.

Pro

• Editly Pro requires a valid paid license, or an active trial where one has been issued.
• Licensing, billing, private updates, downloads, and subscription management run through Freemius.
• Reading content and working with existing drafts remain available when a license is inactive.
• New content and White Label changes cannot be saved through Editly until the local site license is reactivated.
• Existing Elementor content is preserved; deactivation does not delete page content or current Editly drafts.

Manage subscription in the Customer Portal · Review the post-purchase steps

Release details are listed on the Changelog.

Pro is a complete, independent package. It replaces the Free runtime rather than extending it, so a site has one clear Editly editor and settings surface at a time.

Recommended upgrade sequence

1. Back up the site as you would for any plugin change on a live install.
2. Install and activate the Pro package as an administrator.
3. Confirm that Free is inactive; Pro deactivates it to avoid two editions running together.
4. Open Editly → Settings and verify the new tabs and settings are present.
5. Remove the inactive Free plugin once the Pro workflow has been checked.

What to verify after upgrading

• Your allowed roles and edit-limit settings are still correct.
• Third-party widget pages now expose the expected editable content where supported.
• Audit Log and Branding tabs are visible to administrators.
• Licensing and updates are connected if you expect paid update delivery.

This is the most important scope rule in the product. Free edits supported text, textarea, WYSIWYG, and number controls exposed by native Elementor and Elementor Pro widgets. Free does not edit third-party Elementor add-on widgets.

What happens on mixed pages

• If a page includes native widgets and third-party widgets, Free still exposes the editable native fields.
• If a page contains only third-party add-on widgets, Free can show an empty-state explanation instead of editable fields.
• The diagnostic message is there to make the boundary explicit, not to imply that Free can edit those third-party widgets.

The editing workflow is intentionally simple: choose an Elementor page in draft, private, or published status, edit supported content fields, save, then review important front-end pages when the change matters.

Typical workflow

1. Open Editly in wp-admin.
2. Choose the draft, private, or published page you want to edit.
3. Use the search field to locate the relevant text quickly when needed.
4. Edit the supported fields shown in the interface.
5. Save the changes and review the front-end result for high-visibility pages.

How fields adapt to the content

Plain text: when Editly detects an editable text value, it presents the appropriate text field or textarea. The user updates the copy from wp-admin without opening Elementor.

Rich content: when a detected editable field contains compatible HTML or rich text, Editly can use a focused TinyMCE editor. This keeps supported formatting work in Editly rather than sending the user back into the builder.

Save related edits together

You can update several fields—and several supported widgets on the same page—before using the global save button once. Editly collects those pending changes into one save operation, so a small page update does not become a sequence of individual saves.

Editly has two separate search levels: one to find the page you need, then one to find the editable content inside that page. This keeps a large site navigable without mixing page discovery and field discovery into one control.

Search for a page

The sidebar search narrows the list of draft, private, and published Elementor pages before you open one. Long result sets load progressively with Load more pages.

• Draft, private, and published pages appear when Elementor data or Elementor builder mode is detected; editable fields are resolved only after a page is opened.
• Sidebar search reduces friction for operators working across many pages.
• Progressive loading keeps the list responsive instead of dumping every page at once.

Search inside an open page

Once a page is loaded, the search bar at the top filters its editable blocks by text or widget context and opens the first matching result. If nothing matches, Editly shows an explicit empty state instead of leaving the operator to scan the whole page manually.

Edit limits help keep the editing workflow aligned with layout safety. They exist to prevent small content autonomy from quietly turning into UI breakage.

What the setting does

• Limits how much a field can grow relative to its original size.
• Helps keep short UI elements such as buttons, badges, and compact headings within sensible bounds.
• Supports a safer handover when clients and operators should update copy, not redesign components through text growth.

Best-practice checklist

• Keep compact UI copy short and specific.
• Review campaign-critical pages after substantial copy changes.
• Choose one site-wide growth percentage that fits the most constrained delegated workflow; the current setting is global, not per role.

Editly access is role-based, but settings are intentionally more restricted. An administrator chooses which WordPress or custom roles can use Editly and can optionally make Editly the only Elementor content editor available to those selected non-administrator roles.

Recommended setups

• Agency handover: dedicated client content user with Editly access, but without builder access.
• Freelance delivery: owner/admin keeps full control; day-to-day copy edits go through a scoped content role.
• SEO/content team: operational edit access without full design permissions.

Configure Elementor editor access

1. Open Editly → Settings → General as an administrator.
2. Under Access, select the WordPress roles that should use Editly.
3. Under Elementor editor access, enable Use Editly as their only Elementor editor.
4. Save, then test with an account assigned to one of the selected non-admin roles.

Exact behavior

• The selected non-admin roles keep Editly access but cannot open the full Elementor editor.
• Elementor editor buttons and direct editor access are blocked through Elementor’s native role-access mechanism.
• Administrators are never restricted, including accounts that also have another WordPress role.
• Existing restrictions saved in Elementor Role Manager are preserved.
• The rule follows WordPress roles. Assign distinct roles when two users need different access.
• Disabling the option, deactivating Editly, or uninstalling Editly removes only Editly’s dynamic restriction.

Common questions

Can my client still edit Elementor content?
Yes. They edit supported content through Editly; only their access to the full Elementor builder is restricted.

Can administrators still use Elementor?
Yes. Editly never applies this restriction to administrators.

Does Editly replace Elementor Role Manager settings?
No. Editly adds its rule dynamically and preserves Elementor’s stored configuration.

Can I restrict one Editor but not another?
The setting follows WordPress roles. Assign separate roles when users need different access levels.

Free uses a deterministic contract for native Elementor and Elementor Pro widgets: it inspects the complete registered control tree and exposes only editorial values whose behavior and storage are predictable. Pro adds a fundamentally different universal engine. It recursively scans stored scalar values, maps them to the rendered DOM of the same widget and, when a value is ambiguous, verifies that changing that value would actually change visible text. The field can therefore be discovered even when Editly does not know its widget, control type or name.

What Pro does well here

• Uses one universal discovery layer rather than an allowlist or a separate integration for every widget pack.
• Keeps one editing workflow across Elementor, third-party add-ons, theme-provided widgets, and compatible custom widgets.
• Reduces the need to send every add-on widget copy change back into the builder.
• Makes Editly more viable for agencies that do not control every add-on used across client sites, without requiring manual widget-by-widget setup.

Pro extension layer Common add-on stacks

These are non-exhaustive examples. Free remains focused on native Elementor and Elementor Pro widgets; Pro is the route when client-editable text lives in third-party add-on stacks and broader theme environments.

Branding in Pro helps agencies present a cleaner handover experience inside Editly. In a few settings, you can turn the editing surface into a persistent part of your agency delivery: recognisable for the client, consistent across the team, and separate from the generic WordPress administration feel.

Branding controls in Pro

• Enable White Label
• Plugin name in menu
• Header baseline
• Header logo
• Primary accent color with a suggested brand direction and derived hover, contrast, focus, tint, and border tokens

Set the menu name, subtitle, logo, and accent once. Editly persists the choice and applies the resulting palette across the editing interface, so each client sees a coherent agency-branded workflow without manual styling work.

Audit Log is the accountability layer in Pro. It records content edits so teams can keep a complete local history of what changed, on which page, by which user, and when.

What administrators can do

• Enable or disable audit logging.
• Filter entries by search term, user, and date range.
• Review paginated log history.
• Export entries with Export CSV.
• Purge entries with Clear logs.
• Configure retention by days and maximum rows; defaults are 90 days and 5,000 entries.

On larger installs, Pro maintains a persistent page index in the WordPress database for the page list. It improves repeated listing and navigation work instead of relying only on heavier live page lookups.

• Page selection stays more responsive when the site has a larger content inventory.
• Progressive loading still matters, but indexed listing makes repeated operations more predictable.
• This is primarily an operator productivity improvement, not a marketing-only feature bullet.

Data handling should be documented plainly because it affects trust. Free and Pro are close in purpose, but not identical in what they store or which external licensing workflow they use.

Important documentation points

• Free keeps persistent settings and content references by default on uninstall. Runtime caches and scheduled hooks are still removed.
• Pro exposes a data-lifecycle control through Delete data on uninstall. Confirm its saved value before removing the plugin from a production site.
• Audit Log retention in Pro is configurable by days and maximum rows.
• Freemius should be documented accurately as a licensing/update workflow dependency, not as generic product telemetry language.