Loco Translate Not Working in WordPress: A Diagnostic Workflow and the Most Common Fixes

When Loco Translate stops doing what you expect — translations don’t appear on the front end, strings aren’t extracting from your theme, or the plugin throws errors when saving a file — the cause is usually one of a handful of specific issues. The trick is identifying which one faster than wading through general “did you clear the cache” advice.

This guide walks through the diagnostic flow that resolves most Loco Translate issues, organized by what symptom you’re actually seeing. Each cause has a “does this match your symptoms” check, a diagnostic step, and a specific fix.

How to use this guide

Start with the symptom that matches your situation; the relevant cause section is linked from each:

• Translated strings don’t appear on the front end → Cause #1 (file locations) and Cause #2 (locale settings)
• Loco Translate shows the strings as translated, but the front end still shows the original → Cause #3 (caching) and Cause #4 (plugin/theme update overwriting)
• You can’t find strings to translate in Loco’s interface → Cause #5 (POT file extraction)
• Loco Translate gives a “permission denied” or “could not save” error → Cause #6 (file permissions)
• Translations were working, then suddenly stopped after an update → Cause #4 (update overwriting) and Cause #7 (plugin conflict)
• Some strings translate, others don’t → Cause #5 (incomplete POT extraction) and Cause #8 (text domain mismatches)
• Loco’s editor is blank or fails to load → Cause #9 (server limits, security plugin AJAX blocking)
• WPML or Polylang is also installed → Cause #10 (plugin coexistence)

Cause #1 — Translation files aren’t where WordPress expects them

WordPress loads translations from specific directories based on what’s being translated. Loco Translate places files in different locations depending on configuration; if you’ve changed the default and the front end is loading from a different location than Loco is saving to, the translations exist but aren’t being used.

Does this match your symptoms?

• You created and saved translations in Loco Translate
• The Loco interface confirms the strings are translated
• The front end still shows the original (English) strings

Diagnostic:

Check where Loco is saving your translations:

1. In Loco Translate, open the translation set you’re working on
2. Click “Save” (or hover over the save area) and look for “Save to” or “Source”
3. The path shown is where Loco is writing the .po and .mo files

WordPress checks these paths in order for translations:

1. wp-content/languages/themes/{theme}-{locale}.mo or wp-content/languages/plugins/{plugin}-{locale}.mo — the “Languages directory” location, recommended for translations that should survive plugin/theme updates
2. The theme/plugin’s own languages/ directory — overwritten by updates
3. The plugin’s bundled translations

Fix:

In Loco Translate, configure the saving location to the languages directory:

1. Open the translation set
2. Use the “Custom” location dropdown and select the path under wp-content/languages/loco/
3. Re-save the translation

This makes the translation files survive theme/plugin updates and ensures WordPress finds them on the first lookup.

For programmatic verification:

add_action( 'init', function() {
    error_log( 'WPLANG: ' . get_locale() );
    error_log( 'Languages dir: ' . WP_LANG_DIR );
}, 999 );

This logs where WordPress is looking for translation files and confirms your current locale matches what Loco is producing.

Cause #2 — Site locale doesn’t match the translation locale

A common-but-overlooked issue: you’ve translated into Spanish (es_ES), but the site locale is set to English. WordPress only loads translations for the active locale.

Does this match your symptoms?

• Loco confirms the translation file exists for the target locale
• File permissions and locations are correct
• Front end shows original strings regardless

Diagnostic:

Check the current site locale:

add_action( 'init', function() {
    error_log( 'Current locale: ' . get_locale() );
} );

The output should match the locale of the translation file (e.g., es_ES if you translated to loco-es_ES.mo).

Fix:

Change the site locale at Settings → General → “Site Language” to match the locale you translated to. For multilingual sites where each user sees a different language, the locale switches per-user — use the per-user language setting in the user profile.

For programmatic locale switching (e.g., based on URL or geo), hook into locale filter:

add_filter( 'locale', function( $locale ) {
    if ( /* your condition */ ) {
        return 'es_ES';
    }
    return $locale;
} );

Use the same locale string in both the filter and your Loco translation set.

Cause #3 — Object cache or page cache serves stale translations

WordPress caches the loaded translation data. When you save a new translation in Loco, the file on disk updates immediately, but the cache may still serve the old version until invalidated.

Does this match your symptoms?

• You just saved a translation update
• Other users on the site see your translation
• You still see the old version (browser-specific, varies by user)

Diagnostic:

Check if persistent object caching is active:

wp cache type

If you see Redis, Memcached, or APCu reported, the cache is persistent across requests.

Fix:

Flush the object cache after saving translations:

wp cache flush

For page-cached sites (WP Rocket, W3 Total Cache, hosting-level cache):

• WP Rocket: Settings → WP Rocket → Cache → Clear cache
• W3 Total Cache: Performance → Dashboard → Empty all caches
• WP Engine, Kinsta, Pressable, Pantheon: clear the host-level cache via the hosting dashboard
• Cloudflare or other CDN: clear edge cache

If translations update but only after a delay, the cache TTL is the cause — wait or shorten the TTL for development.

Cause #4 — Plugin or theme update overwrote your translations

If you stored translations inside the theme’s or plugin’s own languages/ directory, updates from WordPress.org replace those directories entirely — taking your translations with them. This is the single most frustrating Loco Translate issue because it can happen silently.

Does this match your symptoms?

• Translations were working
• A plugin or theme just updated
• Translations suddenly disappeared

Fix going forward:

In Loco, always save translations to the Custom location at wp-content/languages/loco/.... This directory isn’t touched by plugin/theme updates.

To migrate existing translations:

1. Open the broken translation set in Loco
2. The translations should still be in the .po file even if the .mo was overwritten — Loco can rebuild
3. Use Loco’s “Save as” to a custom location
4. Verify the front end picks up the new location

If the .po file was also overwritten:

1. Hopefully you have a backup of wp-content/languages/ from before the update
2. Restore from backup, then immediately migrate to the custom location

For ongoing protection:

• Always use “Save to → Custom location” in Loco Translate
• Set the default save location in Loco Settings → “Plugin defaults” to a custom location
• Document the location in your handover notes if the site is managed by multiple people

Cause #5 — Strings aren’t being extracted into the POT file

Loco Translate displays strings that exist in the POT (template) file for the theme or plugin. If a string isn’t in the POT, it won’t appear for translation — but it might still appear on the front end (untranslated) because the original string is the fallback.

Does this match your symptoms?

• Some strings translate correctly
• Other visible strings can’t be found in Loco’s translation editor

Diagnostic:

For your own custom theme or plugin: the string must be wrapped in a WordPress translation function with the correct text domain:

// Translatable
echo __( 'Welcome to our site', 'mytheme' );
echo _e( 'Read more', 'mytheme' );
echo _n( '1 item', '%d items', $count, 'mytheme' );

// Not translatable
echo 'Welcome to our site';
echo "Welcome to {$siteName}";

For third-party themes/plugins, check the source code to see if the string in question uses a translation function. If not, the string is hardcoded and can’t be translated through Loco without modifying the plugin/theme code.

Fix:

For your own code, wrap user-facing strings in translation functions with a consistent text domain. Then in Loco:

1. Open the theme or plugin in Loco
2. Click “Sync” — this re-extracts strings from the code
3. New strings should appear in the translation list

If “Sync” doesn’t find expected strings, check for syntax issues in the translation function call (missing quotes, wrong text domain, etc.).

Cause #6 — File system permissions block Loco from writing

Loco needs write access to wherever it’s saving translations. On some hosts or after migrations, file permissions get reset and Loco can no longer save.

Does this match your symptoms?

• Loco shows a “permission denied”, “could not write”, or “failed to save” error
• You can read translations but not save changes

Diagnostic:

Check file permissions on the languages directory via SSH or your hosting file manager:

ls -la wp-content/languages/loco/

WordPress typically expects directories at 755 and files at 644. If the languages directory or files are owned by a different user than the PHP process runs as (www-data, nginx, apache, or your specific host’s user), writes will fail.

Fix:

Set correct permissions:

chmod 755 wp-content/languages/loco/
chmod 644 wp-content/languages/loco/*.po wp-content/languages/loco/*.mo
chown -R www-data:www-data wp-content/languages/loco/

Adjust the user/group to match your hosting environment. For managed WordPress hosts (WP Engine, Kinsta), contact support — they often have specific procedures for adjusting file permissions safely.

For temporary debugging, you can give Loco wider write access via wp-config.php:

define( 'FS_METHOD', 'direct' );

This tells WordPress to use direct file writes instead of FTP, which often resolves permission issues on shared hosting. Add to wp-config.php before the That's all, stop editing! line.

Cause #7 — Another plugin or theme is conflicting

Some security plugins block AJAX requests, some caching plugins intercept Loco’s edits, some translation plugins compete with Loco for the same files.

Does this match your symptoms?

• Loco worked yesterday, broke today
• Recently installed a security, performance, or translation plugin
• Loco’s editor is blank, fails to save, or shows errors

Diagnostic:

Standard plugin conflict isolation:

1. Switch to a default WordPress theme (Twenty Twenty-Four or similar). If Loco works, the issue is in your theme.
2. Deactivate all plugins except Loco Translate. If Loco works, reactivate plugins one at a time until you find the conflict.

Common culprits and fixes:

• Wordfence / Solid Security blocking AJAX: allowlist Loco’s admin-ajax endpoints or add an exception for the WP admin user role
• WP Rocket / caching plugins: exclude admin pages and Loco’s URLs from caching
• WPML or Polylang: these are alternative translation systems; running them alongside Loco can cause conflicts (see Cause #10 below)
• Page builders that override the WordPress admin UI: disable temporarily to isolate

Cause #8 — Text domain mismatch

Loco organizes translations by “text domain” — the identifier passed to translation functions like __( 'text', 'text-domain' ). If your code uses one text domain in the function call but Loco is configured for a different one, the translations won’t apply.

Does this match your symptoms?

• Strings show up in Loco for translation
• You save translations
• Front end still shows original

Diagnostic:

Check the text domain in your theme/plugin’s style.css (themes) or main plugin file header:

/*
Theme Name: My Theme
Text Domain: my-theme
*/

Compare against the text domain you’re translating in Loco. Also check that translation function calls use the same domain:

// In your theme files
__( 'Hello world', 'my-theme' );    // <- this domain must match

Fix:

If the domains don’t match, either:

• Change Loco’s project to use the correct text domain
• Update the theme/plugin code to use a consistent domain across all translation function calls

For custom themes/plugins, set the text domain in the file header and ensure load_theme_textdomain() or load_plugin_textdomain() is called with the matching domain:

// Theme functions.php
function my_theme_setup() {
    load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );
}
add_action( 'after_setup_theme', 'my_theme_setup' );

Cause #9 — Loco’s editor is blank or fails to load

The Loco editor uses AJAX to load translations. Server timeouts, memory limits, security plugins, or browser issues can prevent the editor from rendering.

Does this match your symptoms?

• Loco’s translation editor area is blank or stuck loading
• Browser console shows AJAX errors

Diagnostic:

Open your browser’s developer console (F12, then Console tab) on the Loco editor page. AJAX errors will show with status codes:

• 500 errors — server-side PHP issue. Check the PHP error log for the actual error
• 502 / 504 errors — request timed out. PHP memory limit or execution time too low
• 403 errors — security plugin blocking the request
• 401 errors — admin session expired or nonce mismatch

Fix per error type:

• PHP errors: check wp-content/debug.log (enable WP_DEBUG_LOG if not already on)
• Timeout / memory: increase PHP limits in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );
ini_set( 'max_execution_time', 120 );

• Security plugin blocking: allowlist the Loco URL path in your security plugin’s settings
• Session expired: log out, log back in, retry

Cause #10 — WPML, Polylang, or another translation system installed alongside Loco

Loco Translate is a string-level translator (you translate strings used in code). WPML and Polylang are page-level translators (you translate posts and pages). They don’t directly conflict, but you need to be clear about which one is handling what.

Does this match your symptoms?

• Both Loco and WPML/Polylang are installed
• Translations behave unexpectedly
• Some content translates, some doesn’t

Fix — clarify the division of labor:

• Loco handles: strings in theme/plugin code (__(), _e(), etc.) — UI text, button labels, error messages, admin notices
• WPML or Polylang handles: post content, page content, category names, custom field content

If you want only one system handling everything, choose one:

• For string-level translation only (no multi-language pages): keep Loco, remove WPML/Polylang
• For multi-language pages with built-in string translation: WPML String Translation or Polylang Pro handles both; you can remove Loco

Running both is fine as long as you understand which tool handles which translations. If translations behave unexpectedly, audit which tool is producing the output for the specific string in question.

WordPress 6.5+ and Just-in-Time (JIT) translation loading

WordPress 6.5 introduced significant changes to how translations are loaded. The “Just-in-Time” loader defers translation loading until a translation function is actually called, rather than loading all translations at init. This is a performance win, but it can cause issues with code that called translation functions before the locale was set, or that hooked into load_theme_textdomain / load_plugin_textdomain expecting eager loading.

Does this match your symptoms?

• Translations stopped working after upgrading to WordPress 6.5 or later
• Specific strings translate fine in some contexts but not others
• You see “_load_textdomain_just_in_time was called incorrectly” notices in the debug log

Diagnostic:

Enable WordPress debug logging:

// In wp-config.php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then check wp-content/debug.log for the JIT-related notice. It usually points to a specific text domain and call site.

Fix:

For your own code, ensure translation functions are called after init (where WordPress loads the locale). Don’t call __() from inside plugins_loaded or earlier hooks:

// Don't — too early
add_action( 'plugins_loaded', function() {
    $label = __( 'Settings', 'my-plugin' );    // JIT will warn
} );

// Do — wait for init
add_action( 'init', function() {
    $label = __( 'Settings', 'my-plugin' );
} );

For third-party plugins/themes producing the warning, report it to the maintainer or check for an updated version. The warning is informational — translations still work — but is a signal of code that should be modernized.

Translating strings in block themes (theme.json)

Block themes use theme.json for configuration, and some string values inside theme.json are user-facing. WordPress handles translation of specific theme.json properties — names of color palettes, font sizes, spacing presets, and template parts.

For Loco Translate to extract these, the plugin needs to know which paths to look at. As of recent versions, Loco Translate handles common theme.json paths, but custom or unusual structures may need explicit configuration.

For your own block themes, ensure user-facing labels in theme.json are wrapped appropriately. The keys that get translated automatically:

{
    "settings": {
        "color": {
            "palette": [
                {
                    "name": "Primary",
                    "slug": "primary",
                    "color": "#0073aa"
                }
            ]
        }
    }
}

The "name": "Primary" is translatable; WordPress wraps it with the theme’s text domain at runtime. After saving translations in Loco for Primary and similar theme.json strings, they appear in the Site Editor and block style picker localized.

If theme.json strings aren’t appearing in Loco for translation, click “Sync” in the Loco theme view. The sync should re-scan all sources including theme.json.

Translating Gutenberg block strings

Custom Gutenberg blocks have their own translation considerations. JavaScript-side strings use wp.i18n rather than PHP translation functions, and the translations are loaded differently.

For your block’s PHP-side rendering, standard __() works as expected. For JavaScript-side strings in edit.js or block.js:

import { __ } from '@wordpress/i18n';

const label = __( 'Block Label', 'my-block' );

To make these translations work at runtime, register the script’s translations via PHP:

add_action( 'init', function() {
    wp_set_script_translations(
        'my-block-editor-script',     // script handle
        'my-block',                    // text domain
        plugin_dir_path( __FILE__ ) . 'languages'    // path to translations
    );
} );

For Loco to extract JavaScript strings, the JS files need to be included in the project’s source paths. In Loco’s project configuration, add the JS file paths to the source list.

Translation file validation with msgfmt

When you suspect a .mo file is corrupted (translations randomly stop working, or specific strings produce garbled output), validate the file with msgfmt from GNU gettext:

# Validate a .po file
msgfmt --check wp-content/languages/loco/themes/mytheme-pl_PL.po

# Generate a .mo from a .po
msgfmt -o mytheme-pl_PL.mo mytheme-pl_PL.po

# Verbose validation showing line errors
msgfmt --check --verbose mytheme-pl_PL.po

If msgfmt reports errors, the .po file has syntax issues (unescaped quotes, malformed msgid/msgstr pairs). Fix the issues and regenerate the .mo.

On managed WordPress hosts that don’t include msgfmt, you can validate locally by downloading the .po file, running msgfmt --check on your workstation, then re-uploading the corrected file.

WP-CLI commands for translation debugging

WP-CLI’s translation commands inspect the WordPress-level translation state without needing to write diagnostic PHP:

# List installed languages
wp language core list

# Show current site language
wp language core list --status=active

# Install a core language
wp language core install pl_PL

# Update all installed language packs
wp language core update

# List plugin languages
wp language plugin list --plugin=loco-translate

# Update a specific plugin's translations
wp language plugin update --plugin=loco-translate

# Force re-download of WordPress.org translations
wp language core update --force

These commands work against the actual WordPress install, so the output reflects real state — useful when the UI says one thing but reality is different.

For diagnosing why a specific translation isn’t loading, the relevant context is the locale, the text domain, and the file system path:

# Verify locale
wp option get WPLANG

# Check translation file existence
ls -la wp-content/languages/themes/mytheme-pl_PL.mo
ls -la wp-content/languages/loco/themes/mytheme-pl_PL.mo

If both files exist with different content, WordPress will use the one in the priority list above (wp-content/languages/ overrides Loco’s custom location in some configurations — verify which is actually being loaded).

Bulk operations and external translation services

For larger translation projects (hundreds or thousands of strings), Loco’s UI workflow becomes slow. The realistic options:

• Loco Translate Pro adds bulk operations and translation memory across projects, reducing repetitive work
• External translation tools (Crowdin, Transifex, Lokalise, POEditor) handle large projects with professional translator workflows, then export to standard .po format which you import back into Loco
• Command-line tooling (msgmerge, xgettext) handles bulk operations directly on .po files for technical teams comfortable with the command line

Workflow for external services:

1. Export your project’s .po file from Loco
2. Upload to the translation service
3. Translators work in the service’s professional interface
4. Export the completed .po from the service
5. Import back into Loco, which regenerates the .mo and integrates with WordPress

This pattern scales much better than translating in Loco’s UI for projects with significant string counts or multiple target languages.

Date, number, and currency localization

Translation functions handle strings. Dates, numbers, and currencies have their own localization mechanisms in WordPress that work separately from Loco.

Dates:

// Localized date format
echo wp_date( get_option( 'date_format' ), $timestamp );

// PHP's date() does NOT localize — avoid for user-facing dates
echo date( 'F j, Y', $timestamp );    // always English month names

Numbers:

// Localized number formatting
echo number_format_i18n( 1234567.89 );    // "1 234 567,89" in pl_PL

Currencies:

WordPress core doesn’t include currency formatting. For currency display, use NumberFormatter (PHP intl extension) or the formatting helpers in WooCommerce / Easy Digital Downloads if you have one of those installed:

$formatter = new NumberFormatter( get_locale(), NumberFormatter::CURRENCY );
echo $formatter->formatCurrency( 1234.56, 'EUR' );    // "1 234,56 €" in pl_PL

If your “Loco isn’t working” issue is actually about dates or currencies not localizing — that’s not Loco’s job. Loco handles string translation; locale-aware formatting needs the functions above.

A diagnostic workflow when you don’t know which cause applies

If the symptom doesn’t clearly match one cause, work through this checklist:

1. Verify the locale. get_locale() returns what you expect?
2. Verify the translation file exists at the expected location with correct permissions
3. Disable all caching (object cache, page cache, CDN) temporarily and retest
4. Switch to a default theme + deactivate all plugins except Loco and retest
5. Re-sync the translation source in Loco (extracts any new strings)
6. Check browser console for AJAX errors on the Loco editor page
7. Check PHP error log for fatal errors during Loco operations

This sequence catches most of the common causes without needing to know which one applies in advance.

A working backup workflow

Translation files are easy to lose to plugin/theme updates. The minimum protection:

1. Always save to custom location (wp-content/languages/loco/)
2. Include wp-content/languages/ in your regular backups — most backup plugins do this by default, but verify
3. Export translations periodically via Loco’s “PO” export — keep .po files in a documented location
4. For multi-site or multi-environment teams: commit .po files to version control alongside your theme/plugin code

The .po file is the source; the .mo file is the compiled output WordPress uses at runtime. Lose the .po and you lose the translation memory; lose the .mo and you can regenerate it from the .po.

Frequently asked questions

Why does Loco show the string as translated but the front end shows the original?

The cache is the most common cause. Flush object cache (wp cache flush) and page cache. If still showing original, verify the translation file location (Cause #1) and the active locale (Cause #2).

How do I move existing translations to the custom location after I’ve been using the theme/plugin’s languages directory?

In Loco Translate, open the translation set. Click “Save as” and select the custom location. Loco copies the existing translations to the new location. Delete the original files from the theme/plugin directory to avoid confusion. Future saves go to the custom location and survive updates.

Can I edit translation files outside Loco (in a regular text editor)?

Yes — .po files are plain text and can be edited in any editor. After editing the .po, you need to compile a new .mo (WordPress reads the .mo). Loco can re-import a manually-edited .po and regenerate the .mo, or you can use msgfmt (GNU gettext) on the command line.

Why does Loco extract some strings but miss others in my theme?

Loco only finds strings inside translation function calls (__(), _e(), esc_html__(), etc.) with a matching text domain. Strings that are hardcoded without translation functions, or use a different text domain, are invisible to Loco. Check the theme code for the missing strings to confirm they’re correctly wrapped.

Will my translations survive a WordPress core update?

Yes, if they’re in wp-content/languages/ (not inside the theme or plugin directory). WordPress core updates don’t touch the languages directory.

Can I use Loco Translate on a multisite installation?

Yes. Translations stored in wp-content/languages/ apply network-wide. For per-site translations on multisite, the same approach works at the site level — Loco respects each site’s locale setting.

Should I use Loco Translate Pro or the free version?

The free version handles the core string translation workflow that most sites need. The Pro version adds features like API access, translation memory across projects, and team collaboration tools. For single-site translation work, the free version is usually sufficient.

How does Loco compare with WPML and Polylang?

Loco translates strings in theme/plugin code. WPML and Polylang translate post and page content (and offer string translation as a sub-feature). The right tool depends on what you’re translating:

• Strings only → Loco
• Posts and pages (multilingual content) → WPML or Polylang
• Both → WPML String Translation or Polylang Pro covers both; Loco still works alongside as a free alternative for string translation

How do I verify my .mo file is valid?

Use msgfmt --check on the corresponding .po file. If the .po validates cleanly, regenerate the .mo with msgfmt -o file.mo file.po. If msgfmt reports errors, the source .po has syntax issues — fix those before assuming the .mo is the problem.

Does Loco work with custom post type strings?

For strings in your code that use translation functions with a consistent text domain, yes. For post-content strings (the actual title, content, custom field values of CPT entries), Loco doesn’t handle those — that’s WPML or Polylang’s domain (page-level multilingual content vs string-level translation in code).

How do I translate strings in theme.json for block themes?

User-facing values in theme.json (color palette names, font size labels, etc.) are extractable by Loco if you run “Sync” on the theme. The translations apply at runtime when WordPress loads the active theme. For strings that don’t appear in Loco’s interface after sync, check that Loco’s source paths include theme.json and that the text domain in the theme header matches.

Why are my translations not showing after a WordPress core update?

A WP core update doesn’t touch wp-content/languages/, so translations stored there should survive. If they stopped working after the update, the more likely cause is one of: (1) a JIT loading change in WP 6.5+ flagging early-loaded text domains as broken, (2) a translation file that was actually in the theme/plugin directory and got overwritten by an update to that plugin/theme triggered around the same time, or (3) a cache (object or page) holding the pre-update state. Check wp_unslash, file location, and cache before assuming the core update is the cause.

Why does Loco Translate need write access to my server files?

Loco saves translation data as .po and .mo files on the file system. Without write access, it can read existing translations but can’t save new ones. This is why file system permissions are a common failure point.

What to do next

If you’ve worked through the diagnostic checklist and the cause matches one of the categories above, follow the corresponding fix.

If your translation problem persists after working through this guide, the most likely remaining issues are theme-specific or plugin-specific behavior that requires inspecting the actual code being translated. Use error_log() calls in your theme to verify which translation function is being called with which arguments, then trace from there.

For sites where translation is business-critical and Loco’s workflow is causing friction, consider whether a different tool fits better — WPML or Polylang for multi-language pages, custom translation handling for very specific workflows, or a managed translation service for high-volume professional translation work.

Loco Translate is a capable tool for string translation in WordPress, and most “Loco isn’t working” issues trace to one of these specific causes rather than to the plugin itself. Working through the diagnostic flow above resolves the vast majority of cases.