Title: EffortLess Multisite Auto Translate
Author: domclic
Published: <strong>7. okt 2026</strong>
Last modified: 7. okt 2026

---

Search plugins

![](https://s.w.org/plugins/geopattern-icon/effortless-multisite-auto-translate.
svg)

# EffortLess Multisite Auto Translate

 By [domclic](https://profiles.wordpress.org/domclic/)

[Download](https://downloads.wordpress.org/plugin/effortless-multisite-auto-translate.3.3.6.zip)

 * [Details](https://et.wordpress.org/plugins/effortless-multisite-auto-translate/#description)
 * [Reviews](https://et.wordpress.org/plugins/effortless-multisite-auto-translate/#reviews)
 *  [Installation](https://et.wordpress.org/plugins/effortless-multisite-auto-translate/#installation)
 * [Development](https://et.wordpress.org/plugins/effortless-multisite-auto-translate/#developers)

 [Support](https://wordpress.org/support/plugin/effortless-multisite-auto-translate/)

## Description

EffortLess Multisite Auto Translate is a Network-Activated plugin for WordPress 
Multisite. When a post, page, or custom post type is published or updated on one
site in the network (the “source” site), the plugin sends its title, content, categories,
and tags to your chosen translation provider (OpenAI or DeepL) and creates or updates
a matching translated copy on each of the network’s other sites you’ve selected 
as a “destination”. Translation runs in the background via WordPress Cron (or Action
Scheduler, if another active plugin provides it), not during the page save itself.

Content is translated block by block: each Gutenberg block is sent to the API and
reassembled individually, so block structure, attributes, and nested layouts (columns,
groups, galleries) survive translation. Shortcodes and `core/html` blocks are left
untouched rather than translated. A Glossary lets you pin specific terms (brand 
names, proper nouns) to a fixed translation, or to “do not translate,” per destination
site if needed.

#### What gets translated

 * Post titles and content (Gutenberg blocks)
 * Pages and public custom post types you haven’t unticked in “Post Types to Translate”
 * Categories, tags, and other public taxonomies
 * Post metadata you explicitly add to the “Extra translatable meta keys” setting

#### What is left untouched

 * Shortcodes (preserved exactly, including their attributes)
 * `core/html` blocks (skipped by default; a `elmat_translate_html_block` filter
   exists for developers who want to opt them in)
 * Private post metadata

#### Settings (Network Admin  GPT Translator)

 * **Translation Provider** — OpenAI (GPT), DeepL, or (WordPress 7.0+ only) the 
   built-in WordPress AI Client, which uses whichever provider your site has configured
   under Settings  Connectors instead of a key entered here. Only the selected provider’s
   key below is used.
 * **OpenAI API Key** / **DeepL API Key** — required for whichever provider is selected.
   A “Test API Key” button verifies the active one before you save.
 * **Enable automatic translations** — checkbox. When off, translation only happens
   if triggered manually from the block editor’s GPT Translator panel.
 * **Publish new translations as draft** — checkbox, off by default. When on, a 
   translation’s _first_ creation is saved as a draft instead of published, so a
   human can review it before it goes live. Only affects first creation — updating
   an already-published translation keeps updating it in place, never unpublishing
   it automatically.
 * **GPT Model** — `gpt-4o-mini` (default) or `gpt-4o`. OpenAI only.
 * **Translation Style** — Literal, Natural (default), or Creative — controls how
   closely the translation sticks to the source wording. Applies to both providers(
   mapped internally for each).
 * **Additional Instructions** — free-text instructions appended to every translation
   request (tone, formality, house style). OpenAI only — DeepL has no prompt/instruction
   mechanism.
 * **Post Types to Translate** — untick any post type to stop translating it, both
   automatically and via Bulk Translate. Lists every public post type registered
   on the source site.
 * **Extra translatable meta keys** — a plain-text list (one per line) of additional
   post-meta keys to translate, for meta fields added by other plugins (e.g. custom
   SEO title/description fields).
 * **Shared Media Library** — optionally designate one site’s Media Library as the
   single source of truth for images; other sites’ translated content then links
   back to that site’s files instead of duplicating them.
 * **Source Site** — the one site whose saves trigger translation.
 * **Destination Sites** — which of the network’s other sites receive translated
   copies.
 * **Glossary** — a table of terms with a fixed translation (optionally overridden
   per destination site), so brand names and specific phrases translate consistently
   instead of varying between posts.

A running character-usage total (this month + lifetime) is shown above the API key
fields once translation has run at least once — a rough usage indicator, not exact
billing; check your provider’s own dashboard for that.

A “Translation Status” box also appears in the post editor’s sidebar (source site
only) showing each destination’s status for the post you’re editing, without a trip
to Network Admin.

#### Tools (Network Admin  GPT Translator  Tools)

Bulk Translate All Posts, Force Re-translate All (clears retry/failure counters 
and re-sends everything), Sync Design & Templates (switches every destination site’s
active theme to match the source, network-enabling it first if needed, then copies
global styles, site icon, logo, and queues templates/patterns for translation — 
a confirmation dialog states the theme change before you proceed), Resync Media 
Links (also runs automatically whenever the Shared Media Library setting changes),
Clean Destinations (removes orphaned translations and non-translation content added
directly on a destination site), Flush Permalinks, and Emergency Stop (cancels every
pending translation). Stuck queue entries clear themselves automatically within 
about an hour — there’s no separate cleanup button for that.

#### Notes and limitations

 * Requires WordPress Multisite to do anything. It can be installed and activated
   on a single-site WordPress (for example before you enable Multisite), but there
   it only shows a notice on the Plugins screen and has no settings. After converting
   the site to a network, network-activate it from the Network Admin; the one-time
   network setup runs automatically.
 * Translated and synced content is saved through WordPress’s normal sanitization.
   Form tags (`<input>`, `<select>`, `<textarea>`) and scripts inside a translated
   custom-HTML block are removed on save, as they would be for any non-privileged
   user.
 * “Sync Design & Templates” does not copy Additional CSS; each site keeps its own.
 * Translation is asynchronous: after publishing, allow a few seconds (or up to 
   a WP-Cron cycle on a low-traffic site) for the destination copies to appear.
 * Trashing, permanently deleting, or restoring a post on the source site does the
   same on every destination site’s translated copy.
 * Adding a new destination site automatically switches that new site’s theme to
   match the source site as part of its one-time setup (it also copies the design
   and starts translating existing content to it) — this only happens for a brand-
   new site being added, never for a site already in production; running “Sync Design&
   Templates” manually against an existing destination will switch its theme too,
   and asks for confirmation first.
 * A translation that fails is retried up to twice with a growing delay; after 10
   total failures for a given post/destination pair, the plugin stops retrying it(
   visible as “abandoned” in the Status tab, with a manual retry button).
 * No custom database tables are created (except a translation-memory cache table,
   used to skip re-translating a block whose source content hasn’t changed). Uninstalling
   the plugin removes it along with all `elmat_*` site options and the translation-
   linking postmeta.

### External services

This plugin sends content to your chosen translation provider’s API in order to 
translate it — this is the plugin’s core function and cannot be disabled while automatic
or manual translation is used. Only the provider you’ve selected in Settings is 
ever contacted.

**OpenAI** (`api.openai.com`) — used when Translation Provider is set to OpenAI.
What is sent: the post title, the text content of each Gutenberg block (shortcodes
and `core/html` blocks are excluded), the names of categories/tags/taxonomies, and(
if set) your “Additional Instructions” text. Terms of use: https://openai.com/policies/
terms-of-use — Privacy policy: https://openai.com/policies/privacy-policy

**DeepL** (`api.deepl.com` / `api-free.deepl.com`) — used when Translation Provider
is set to DeepL. What is sent: the same title/content/taxonomy names as above (Additional
Instructions does not apply to DeepL). Terms of use: https://www.deepl.com/en/pro-
license — Privacy policy: https://www.deepl.com/en/privacy/

**WordPress AI Client** (WordPress 7.0+ only) — used when Translation Provider is
set to “WordPress AI Client”. The same title/content/taxonomy names as above are
sent, but to whichever external AI provider your site has configured under Settings
Connectors, not to this plugin or its developer — this plugin never sees that provider’s
identity, endpoint, or API key, only the result. Check your configured Connectors
provider’s own terms of use and privacy policy.

Either way, this happens every time a post is published or updated on the configured
source site, and whenever “Bulk Translate All Posts” or a manual per-post translation
is triggered. No personal visitor data, and no data from any site other than the
post being translated, is sent. Using OpenAI or DeepL requires your own API key 
for that provider (entered in the plugin’s settings); using the WordPress AI Client
instead defers entirely to whatever provider and credentials your site’s Connectors
screen has configured. Either way this is billed to your own account directly — 
the plugin developer has no access to your key, your account, or the content sent.

## Installation

#### Automatic Installation

 1. Log in to your Network Admin.
 2. Navigate to Plugins  Add New.
 3. Search for “EffortLess Multisite Auto Translate”.
 4. Click “Install Now”, then **Network Activate** (not a per-site Activate) from the
    Network Admin’s Plugins page.

#### Manual Installation

 1. Download the plugin zip file.
 2. Upload it to `/wp-content/plugins/`.
 3. Extract the zip file.
 4. Network Activate the plugin from the Network Admin  Plugins page.

#### Configuration

 1. Go to Network Admin  GPT Translator.
 2. Enter your OpenAI API key and click “Test API Key” to confirm it works.
 3. Choose your Source Site and one or more Destination Sites.
 4. Leave “Enable automatic translations” checked (or uncheck it if you only want to
    translate manually per-post from the editor).
 5. Save.
 6. Publish or edit a post on the Source Site — its translation appears on each Destination
    Site within a few seconds to one WP-Cron cycle.

## FAQ

### Do I need an OpenAI API key?

Yes, an active OpenAI API key with available credit. Create one at platform.openai.
com/api-keys. The plugin does not work without one.

### How much does translation cost?

Cost is billed by OpenAI directly, not by this plugin, and depends on your chosen
model and the length of your content. Check OpenAI’s own current pricing at openai.
com/api/pricing before enabling automatic translation on a large site.

### Will shortcodes be translated?

No. Shortcodes are preserved exactly as written, including their attributes and 
values — only the surrounding text is translated.

### Does it work with Gutenberg?

Yes, translation is done block by block so structure and attributes are preserved.
Classic-editor (non-block) content is translated as a single unit.

### Can I translate existing content?

Yes — use “Bulk Translate All Posts” under Tools to translate everything already
published on the source site.

### What happens if a translation fails?

It’s retried automatically up to twice with an increasing delay. After 10 total 
failures for the same post on the same destination, the plugin stops retrying and
marks it “abandoned” — visible (and manually retryable) in the Status tab.

### How do I stop all translations immediately?

Click “Emergency Stop” under Tools. This cancels every pending translation job.

### Translated posts are showing 404 errors — what do I do?

Click “Flush Permalinks” under Tools to regenerate rewrite rules on every site in
the network.

### Can I disable automatic translation temporarily without deactivating the plugin?

Yes — uncheck “Enable automatic translations” in Settings. Manual translation from
the block editor’s GPT Translator panel still works.

### Does it translate categories and tags?

Yes, category and tag names (and other public taxonomies) are translated and kept
in sync across sites.

### What happens when I delete a post on the source site?

Its translated copies on every destination site are deleted (or trashed/restored,
matching whatever action was taken on the source).

### Can I choose which post types are translated?

Yes — untick any post type in the “Post Types to Translate” setting. This stops 
it being translated both automatically and via Bulk Translate; existing translations
of an unticked type are left in place, they simply stop being updated.

### Can I install it on a normal (single-site) WordPress?

Yes, it installs and activates without errors, but it does nothing there and has
no settings page — it needs a Multisite network. It shows a “Requires Multisite”
link and a notice on the Plugins screen. Once you enable Multisite (see WordPress’s“
Create a Network” guide), network-activate the plugin from the Network Admin and
the settings appear under Network Admin  GPT Translator.

### Can I use DeepL instead of OpenAI?

Yes — set “Translation Provider” to DeepL and enter a DeepL API key. DeepL is a 
pure translation engine rather than a prompt-driven model, so the “Additional Instructions”
field has no effect when DeepL is selected (Translation Style, Glossary, and translation
memory all still work the same way).

### Can I use the built-in WordPress AI Client instead of entering my own API key?

On WordPress 7.0 and later, yes — set “Translation Provider” to “WordPress AI Client”.
No key field appears for it; it uses whatever AI provider your site already has 
configured under Settings  Connectors. This option is hidden entirely on WordPress
versions before 7.0, since the AI Client doesn’t exist yet there. Use “Test Connection”
after saving to confirm it actually works.

### How do I monitor what the plugin is doing?

The Logs tab shows recent activity and auto-refreshes every 5 seconds. A local log
file is also written to `wp-content/uploads/elmat-translator.log`. The Settings 
tab also shows a rough character-usage total (this month + lifetime) once translation
has run at least once.

### I configured everything and nothing is being translated — what should I check?

Confirm the plugin is **Network Activated**, not activated on an individual site(
it does nothing per-site). Confirm “Enable automatic translations” is checked, that
the post type isn’t unticked in “Post Types to Translate”, and that the post you’re
testing with was actually saved _after_ configuration was completed — the plugin
only reacts to a `save_post` event on the source site going forward, it doesn’t 
retroactively pick up older posts (use Bulk Translate for those). Also confirm your
provider’s API key still has available credit — a billing failure surfaces as a 
translation failure in the Logs tab, not as a plugin error.

## Reviews

There are no reviews for this plugin.

## Contributors & Developers

“EffortLess Multisite Auto Translate” is open source software. The following people
have contributed to this plugin.

Contributors

 *   [ domclic ](https://profiles.wordpress.org/domclic/)

[Translate “EffortLess Multisite Auto Translate” into your language.](https://translate.wordpress.org/projects/wp-plugins/effortless-multisite-auto-translate)

### Interested in development?

[Browse the code](https://plugins.trac.wordpress.org/browser/effortless-multisite-auto-translate/),
check out the [SVN repository](https://plugins.svn.wordpress.org/effortless-multisite-auto-translate/),
or subscribe to the [development log](https://plugins.trac.wordpress.org/log/effortless-multisite-auto-translate/)
by [RSS](https://plugins.trac.wordpress.org/log/effortless-multisite-auto-translate/?limit=100&mode=stop_on_copy&format=rss).

## Changelog

Only the most recent versions are listed here to stay within WordPress.org’s changelog
length limit; see the plugin’s own repository for the full history.

#### 3.3.6

 * Change: the plugin can now be installed and activated on a single-site WordPress
   ahead of enabling Multisite. It stays inactive there, shows a notice and a “Requires
   Multisite” link on the Plugins screen, and does nothing else.
 * Fix: if a site is converted to a Multisite network while this plugin is already
   active, the one-time network setup (permalink flush on every site, shared translation-
   memory table) now runs automatically the first time a Super Admin opens the Network
   Admin, instead of only on activation.
 * Fix: Design Sync skips theme mods the destination already has with the same value,
   avoiding hundreds of redundant option writes on a re-run.
 * Housekeeping: corrected an inaccurate note about which saves the form-element
   allowlist applies to.

#### 3.3.5

 * Fix: activating the plugin on a single-site (non-Multisite) WordPress no longer
   ends in an error screen. Activation now succeeds quietly, the plugin does nothing
   there, and a notice on the Plugins screen explains that Multisite is required.
 * Security: translated and synced content is now always saved through WordPress’s
   normal sanitization (kses). The previous internal bypass that disabled kses while
   the plugin wrote translated posts, templates, patterns, navigation and global
   styles has been removed.
 * Security: “Sync Design & Templates” no longer copies the source site’s Additional
   CSS to destination sites (each site keeps its own), and no longer copies the 
   source site’s Additional CSS post reference.
 * Fix: the shared-media URL rewriter that runs on `the_content` and featured-image
   HTML now escapes the URL values it inserts into the markup.
 * Fix: logo, header/background image and menu-location settings are now written
   with WordPress’s own theme-mod functions instead of editing the `theme_mods_*`
   options directly.
 * Change: “Requires at least” is now 5.4 (a major release, as WordPress.org requires,
   and still covering `serialize_block()` 5.3.1 and `wp_date()` 5.3.0).

#### 3.3.4

 * Fix: raised “Requires at least” from 5.0 to 5.3.1 to match what the plugin actually
   needs — `serialize_block()`/`serialize_blocks()` (used unconditionally throughout
   the block-translation pipeline) require 5.3.1, and `wp_date()` (used in the admin
   Status tab) requires 5.3.0.
 * Housekeeping: shortened the 3.3.0 upgrade notice to fit WordPress.org’s 300-character
   limit.

#### 3.3.3

 * New: added the built-in WordPress AI Client (WordPress 7.0+) as a third Translation
   Provider option, alongside OpenAI and DeepL. Unlike those two, it stores no API
   key in this plugin at all — it uses whatever provider your site already has configured
   under Settings  Connectors. Hidden entirely on WordPress versions before 7.0.
   Per WordPress.org review guidance to prefer the core AI Client over a direct-
   only integration where practical; OpenAI and DeepL remain available since this
   plugin supports WordPress back to 5.3.1 and DeepL’s translation-only model has
   no AI Client equivalent.

#### 3.3.2

 * Fix: activation fatal-errored on a single-site (non-Multisite) WordPress install,
   since the activation hook unconditionally queried the network’s site list. It
   now shows a clear “requires Multisite” error and does not activate, instead of
   fataling.
 * Security: removed the opt-in “Allow editor unfiltered HTML” setting, which granted
   the `unfiltered_html` capability to source-site Editors/Administrators to work
   around multisite’s kses stripping some block markup. WordPress.org review treats
   granting this capability to anyone below Super Admin as a hard violation regardless
   of scope or documentation — the existing `wp_kses_allowed_html` allowlist extension
   is the correct way to keep specific additional markup from being stripped.
 * Change: the “Sync Design & Templates” tool’s description and confirmation dialog
   now explicitly state that it switches the destination site’s active theme (previously
   only “theme mods” were mentioned, not the theme switch itself).
 * Housekeeping: shortened the readme’s short description to fit WordPress.org’s
   150-character limit (was 162).

#### 3.3.1

 * Housekeeping: bumped Tested up to 7.1 (the current WordPress release) ahead of
   first submission to WordPress.org.

#### 3.3.0

 * Feature: DeepL is now a second supported translation provider alongside OpenAI—
   pick either in Settings, each with its own API key. DeepL’s own tag-handling 
   mechanism protects shortcodes and internal placeholder tokens the same way OpenAI’s
   system prompt does.
 * Feature: “Post Types to Translate” setting — untick any post type to stop translating
   it, both automatically and via Bulk Translate. Fixed a related bug in the same
   pass: the automatic save-triggered translation never actually consulted the translatable-
   post-types list at all (only bulk operations did), so this exclusion (and the
   existing `elmat_translatable_post_types` developer filter) would previously have
   been silently ignored for day-to-day translation.
 * Feature: “Publish new translations as draft” setting, for reviewing a translation
   before it goes live. Only affects a translation’s first creation; updating an
   already-published translation is unaffected.
 * Feature: a “Translation Status” box in the post editor’s sidebar (source site
   only) shows each destination’s status for the post being edited.
 * Feature: a rough character-usage total (this month + lifetime) now appears above
   the API key fields.
 * Feature: “Additional Instructions” free-text field, appended to every translation
   request — tone, formality, house style (OpenAI only).
 * Change: replaced the “Translation Temperature” slider, which turned out to have
   never actually been sent to the API in any released version, with a “Translation
   Style” setting (Literal / Natural / Creative) that is genuinely wired into both
   providers.
 * Change: removed the “Clean Up Duplicate Patterns & Navigation” tool — it existed
   only to clean up duplicates from a slug-matching bug fixed in 3.2.59, so it had
   nothing left to do.
 * Change: removed the “Clean Up Duplicate Patterns & Navigation” tool — it existed
   only to clean up duplicates from a slug-matching bug fixed in 3.2.59, so it had
   nothing left to do.
 * Change: removed the “Clean Up Translation Queue” button — stuck queue entries
   now clear themselves automatically within about an hour (was once a day) instead
   of needing a manual click.
 * Change: enabling or switching the Shared Media Library setting now automatically
   fixes embedded media links on destination sites, instead of requiring a separate“
   Resync Media Links” click afterward. The button is still available under Tools
   for the unrelated case of images broken for some other reason.

#### 3.2.67

 * Fix: the lifetime failure counter that abandons a permanently-failing translation
   after 10 attempts was shared across all destination sites instead of tracked 
   per destination. With more than one destination configured, a destination that
   failed on every attempt while the others succeeded could never reach the threshold(
   the others’ successes kept resetting the shared counter), retrying forever with
   no abandonment notice; conversely, a temporary outage affecting every destination
   together could abandon all of them at once, including ones that would have succeeded
   on the next try. The counter (and its one-shot abandonment-email flag) is now
   tracked separately per destination, and the Status Dashboard’s per-destination“
   abandoned” indicator reflects this too. Found and fixed via direct testing of
   the failure-handling code, not a user report.
 * Fix: a Query Loop / Latest Posts block whose JSON attributes nest past 5 levels(
   routine once style, layout, and a taxonomy filter combine) could silently lose
   its category/tag filter during translation — the code protecting those attributes
   used a hand-built pattern capped at 5 nested levels instead of the recursive 
   pattern used everywhere else in the plugin for exactly this reason. Verified 
   against a 6-level-nested payload before and after the fix.
 * Fix: uninstalling the plugin left behind per-destination-site options written
   by the logo/site-icon/header-image sync feature — these live in a different database
   table than the postmeta the uninstaller already cleaned up, so they were never
   removed.

#### 3.2.66

 * Fix: the settings page’s CSS/JS enqueue was registered on `network_admin_enqueue_scripts`,
   which is not a real WordPress hook (it never fires — the correct hook, `admin_enqueue_scripts`,
   is shared by both regular admin and Network Admin pages). This meant the plugin’s
   real `wp_enqueue_style()`/`wp_enqueue_script()` calls had never once executed;
   the settings page only worked at all because of a separate raw-HTML fallback 
   duplicating the same CSS/JS directly into the page body. Found and fixed via 
   real HTTP testing while preparing this release, not by a user report.
 * Fix: that same fallback now uses `wp_add_inline_style()`/`wp_add_inline_script()`(
   attached to the now-correctly-firing enqueue) instead of echoing raw `<style>`/`
   <script>` tags — identical “always inline, no second request required” guarantee,
   delivered through a WordPress-recognized API instead of a hand-rolled one.
 * Fix: the “Allow editor unfiltered HTML” checkbox on the Settings tab always rendered
   unchecked regardless of the actual saved setting — the computed value was never
   passed into the method that renders that part of the form.
 * Change: internal prefix renamed from `ms_gpt`/`MS_GPT` to `elmat`/`ELMAT` throughout(
   classes, options, hooks, REST namespace, JS globals, CSS classes, file names)
   ahead of first publication — no existing installs are affected.
 * Change: readme rewritten as documentation (external services disclosure, full
   settings list, notes and limitations) ahead of first submission to WordPress.
   org.

#### 3.2.65

 * Fix: a glossary entry could fail to match at all, and the term would get translated
   as if no entry existed for it — even when the entry looked correctly configured.
   A company name (e.g. “ID7 LLC”) is often typed with a non-breaking space between
   its parts so it never line-wraps in the middle, which is a different, invisible
   character from the plain space typed into the glossary’s own field, and previously
   had to match byte-for-byte. Any space in a glossary entry now also matches a 
   non-breaking space, a tab, or more than one space, so the entry is found and 
   applied regardless of exactly which kind of space the content actually uses.

#### 3.2.64

 * Feature: the Glossary now protects a brand name even when it is split mid-word
   by a style change — for example a two-tone logotype where the first half is one
   color and the second half another, authored as separate HTML elements next to
   each other. Previously the glossary could only recognise a protected term when
   it appeared as plain, unbroken text, so a mid-word style split made it invisible
   and each half was translated separately, breaking the mark. The exact original
   styling is now preserved untouched wherever this happens, while a plain (unstyled)
   occurrence of the same term elsewhere on the page still gets the translation 
   configured in the glossary entry.

#### 3.2.63

 * Fix: the Glossary feature could fail to protect a multi-word entry (e.g. a brand
   name like “Honey Edge”) whenever a shorter, unrelated entry sharing a word with
   it (e.g. “Edge” on its own) also existed — whichever happened to be saved first
   would claim its match, and if that was the shorter one, it consumed the shared
   word out of the middle of the longer phrase before the longer entry got a turn
   to protect it as a whole. Longer, more specific entries are now always matched
   first, so a phrase like “Honey Edge” is protected as one unit before a shorter
   overlapping entry can ever touch part of it.

#### 3.2.62

 * Fix: the actual root cause behind navigation menus, patterns, logos and template
   parts still not linking up correctly on destination sites across several recent
   releases. Every place that reads a block’s reference (which post it points at)—
   a navigation menu, a synced pattern, a template part’s theme, a site logo — did
   so with a shortcut that only understood one level of nested settings inside that
   block’s own attributes. Any of those blocks with its own spacing, color or layout
   style set (extremely common — most blocks that have been styled at all have this)
   has more than one level of nesting, so the reference inside was silently never
   read at all, and never corrected. Every one of the fixes shipped since 3.2.51
   was applying correctly, but a good number of blocks were never actually reached
   by any of them because of this. This has been replaced everywhere with a correct
   reader that understands any depth of nested settings, so every one of those earlier
   fixes now reaches the blocks it was always meant to.

#### 3.2.61

 * Fix: “Clean Up Duplicate Patterns & Navigation” could itself trash the navigation
   menu (or pattern) actually in use, if a template’s reference to it was not detected
   as such, showing WordPress’s own “This navigation menu has been deleted or is
   unavailable” message on the live site — a trashed post is exactly what WordPress
   treats that way, whether or not the database row still exists. The tool is now
   self-healing: it also looks inside Trash, and if the item it determines is actually
   referenced turns out to be the one sitting in Trash, it is restored automatically
   rather than left broken while an unrelated duplicate is kept. When nothing in
   a group is referenced anywhere, a published item is now preferred over a trashed
   one before falling back to “most recently modified” — closing the gap that let
   this happen. Re-running the tool is safe and will correct any site left in this
   state by a previous run.

#### 3.2.60

 * Feature: added a “Clean Up Duplicate Patterns & Navigation” tool (Tools page,
   next to Clean Destinations) that finds patterns, navigation menus, templates,
   and template parts on destination sites left duplicated by a sync run before 
   3.2.59, and moves the extra copies to trash. The copy actually referenced by 
   a template or template part is always kept; every trashed copy can be restored
   from that site’s own Trash if needed.

#### 3.2.59

 * Fix: Design Sync could create an extra, duplicate pattern or navigation menu 
   on a destination site instead of updating the one already there, so re-running
   the sync left destinations accumulating stray copies rather than staying an exact(
   translated) mirror of the source. The sync only recognised an already-copied 
   item by matching its web address slug, but WordPress does not keep navigation
   menu slugs stable — it can rename one from “navigation” to “navigation-2” behind
   the scenes — so a slug that matched on one sync could stop matching on the next,
   and a duplicate was created instead of the real one being found and updated. 
   Every item is now matched first by its actual link back to the specific source
   item it was copied from, which does not change, falling back to matching by slug
   only the very first time an item is copied. This is also the most likely explanation
   for a header or footer needing to be manually reset to get its navigation working
   again after a sync: the reset was making it point at the correct copy, which 
   the next sync could not find and update because of this bug.

#### 3.2.58

 * Fix: a backslash anywhere in copied or translated content — most visibly reported
   as Additional CSS (Appearance > Customize) arriving on destination sites with
   every newline and tab replaced by a stray “n” or “t” — was silently corrupted
   on every sync and every translation. WordPress’s own post-save functions expect
   content to be pre-escaped by the caller and always remove one level of backslash
   immediately before writing to the database; this plugin was not escaping first,
   so any real backslash in the content (an escaped CSS character, a quote inside
   translated text, and the case actually reported: certain editors store a literal
   backslash-n/backslash-t in Additional CSS rather than an actual line break) was
   stripped everywhere content gets written — templates, template parts, patterns,
   navigation, translated posts and pages, media captions, and Additional CSS alike.
   Every one of those save points now escapes content correctly first, matching 
   how WordPress’s own equivalent built-in function already did it for Additional
   CSS specifically.

#### 3.2.57

 * Fix: the Header Image and Background Image set under Appearance > Customize were
   copied to destination sites as a raw link back to the source site’s own address
   instead of an image belonging to that destination — so removing or changing the
   source image, or the source site going offline, could silently break it everywhere
   else. Both now go through the same media sync already used for the site logo 
   and favicon: shared through the shared media library when one is configured, 
   or downloaded and stored locally on each destination otherwise.

#### 3.2.56

 * Fix: a navigation menu item linking to a category, tag, or custom taxonomy term
   kept pointing at the source site’s term on every destination site — only links
   to a post or page were being remapped. It now matches the equivalent term by 
   slug on each destination, the same way categories/tags are already matched when
   a post is translated.
 * Fix: a background image or other `url(...)` reference inside the source site’s
   Additional CSS was copied to destination sites unchanged, so it kept loading 
   from the source site’s own address. It now goes through the same media-URL rewrite
   already used for images inside pages and templates.

#### 3.2.55

 * Fix: a reusable/synced pattern embedded in a header, footer, template, or another
   pattern could render blank or show the wrong content on destination sites. That
   kind of pattern is referenced by a raw post ID with no slug involved, and the
   ID was being copied unchanged across sites, pointing at an unrelated (or missing)
   post on the destination. Every pattern reference is now remapped to the correct
   destination post, the same way navigation menu references already were.

#### 3.2.54

 * Fix: a correctly-synced header or footer could revert to showing the wrong theme’s
   content shortly after a successful Design Sync, or whenever it was edited and
   saved again on the source site — the regular translation pipeline (a separate
   code path from Design Sync) never rewrote the “theme” attribute embedded in a
   template part’s reference, silently reintroducing the mismatch 3.2.53 fixed. 
   That pipeline now carries the same fix.

#### 3.2.53

 * Fix: a synced template part (most visibly the footer) could look correct in the
   Site Editor but still show the theme’s own default content on the live site, 
   because WordPress only uses a copied template part when its embedded “theme” 
   reference matches the site’s active theme — copying carried the source site’s
   theme name over unchanged. Every such reference is now rewritten to the destination’s
   theme when content is copied.

#### 3.2.52

 * Fix: design sync could still update or match the wrong header/footer/template
   on a destination site that had ever run a different theme, since template/template-
   part lookups matched by slug alone with no theme filter. Every such lookup is
   now scoped to the site’s active theme first.

#### 3.2.51

 * Fix: design sync could copy the wrong header/footer (or other template part) 
   content to destination sites, since template posts stay in the database tagged
   by the theme they belonged to at save time, and the sync previously fetched all
   of them regardless of theme. Templates and template parts are now scoped to the
   source site’s active theme before copying.

#### 3.2.50

 * Fix: the Translation Glossary never actually worked due to a reversed placeholder-
   substitution bug — every configured glossary entry was silently ignored. Matching
   is also now case-insensitive for Latin/ASCII terms.

#### 3.2.49

 * Fix: a translation-prompt gap that could let the `name` or `value` attribute 
   of a form/block element be rewritten during translation, corrupting field mapping
   or stored data on destination sites.

#### 3.2.48

 * Feature: an opt-in setting (“Allow editor unfiltered HTML”) to fix “Attempt Block
   Recovery” errors on the source site caused by WordPress stripping block markup
   from non-super-admin saves. Off by default; enable only for trusted editors.

## Meta

 *  Version **3.3.6**
 *  Last updated **17 tundi ago**
 *  Active installations **Fewer than 10**
 *  WordPress version ** 5.4 or higher **
 *  Tested up to **7.1.3**
 *  PHP version ** 7.4 or higher **
 *  Language
 * [English (US)](https://wordpress.org/plugins/effortless-multisite-auto-translate/)
 * Tags
 * [gpt](https://et.wordpress.org/plugins/tags/gpt/)[gutenberg](https://et.wordpress.org/plugins/tags/gutenberg/)
   [multisite](https://et.wordpress.org/plugins/tags/multisite/)[openai](https://et.wordpress.org/plugins/tags/openai/)
   [translation](https://et.wordpress.org/plugins/tags/translation/)
 *  [Advanced View](https://et.wordpress.org/plugins/effortless-multisite-auto-translate/advanced/)

## Ratings

No reviews have been submitted yet.

[Your review](https://wordpress.org/support/plugin/effortless-multisite-auto-translate/reviews/#new-post)

[See all reviews](https://wordpress.org/support/plugin/effortless-multisite-auto-translate/reviews/)

## Contributors

 *   [ domclic ](https://profiles.wordpress.org/domclic/)

## Support

Got something to say? Need help?

 [View support forum](https://wordpress.org/support/plugin/effortless-multisite-auto-translate/)

## Donate

Would you like to support the advancement of this plugin?

 [ Donate to this plugin ](https://id7.dev/donate/)