Switcher shows list instead of the dropdown I selected in Settings
Cause: one of three overrides.- Theme calls the function with explicit args. Search your theme:
grep -rn "lf_language_switcher" wp-content/themes/. Look forlf_language_switcher(['style' => 'list', ...])— those args win over Settings. Remove the arg to let Settings take effect:lf_language_switcher(). - Widget has its own saved style. Appearance → Widgets → find the Language Switcher widget → the Style dropdown there is independent of Settings. Change it there.
- Page/host cache serves stale HTML. Hit Save in Settings again (we purge LSCache / object-cache / WP Rocket / W3TC on every save now), then Cmd+Shift+R on the frontend.
EN switcher keeps me on the RU post
Cause: fixed in 1.0.3. On sites where every translation shares onepost_name, WordPress resolved /slug/ to whatever row came first in wp_posts. The plugin now runs its resolver for every language including the default, so the query swaps to the right post ID before WP loads the content.
Confirm you’re on 1.0.3+. If yes, check lf_url_format — in parameter mode (the common case), the default-language URL is bare /slug/ without ?lang=en. If your theme is caching this URL, purge and hard-reload.
Dropdown renders as an empty coloured rectangle
Cause: Settings has both “Show flags” and “Show language names” off. Old behaviour: empty box, no indication anything’s there. New (1.0.3+): falls back to uppercase language code (EN / RU / ES) + a▾ chevron.
If you’re on 1.0.3+ and still see blank: browser-cached old CSS. Hard-refresh. The plugin now uses filemtime() as the enqueue version so future edits invalidate immediately — this particular transition was the last time you’ll need a manual refresh.
Dropdown menu gets clipped by the header
Cause: theme has.header-bar { overflow: hidden } (or similar). The dropdown is position:absolute — any ancestor with overflow:hidden clips it.
Fix: in your theme’s style.css, change the offending rule to overflow: visible on the header container. No plugin code needed — this is a theme-integration requirement.
I removed a language but its posts are still reachable by direct URL
Cause: expected in 1.0.3+, with a prompt to resolve. After removing a language in Settings → Save, an orange admin notice appears listing each orphaned language with three buttons:- Leave publishedposts stay reachable by direct URL but don’t show in the switcher
- Move to Draftposts go to draft status (previously published URLs return 404)
- Delete permanently
wp_delete_post(force=true)for every post in that language, with confirmation
If you missed the notice, re-enable the language, Save, disable it again, Save — the notice reappears.
Arabic/Hebrew text typed in Visual Editor looks correct but cursor is on the left
Cause: fixed in 1.0.3. The target column hasdir="rtl" but contenteditable / input / textarea elements don’t inherit bidi direction from an ancestor attribute — browsers resolve direction per block. Plugin now forces direction:rtl; text-align:right; unicode-bidi:plaintext on RTL column form controls via CSS.
Confirm: view page source, search for .avl-editor-col[dir="rtl"] rules. If missing, pull latest.
Applied an AI QA suggestion — translation still shows the old text
Cause: fixed in 1.0.3. Title input had both.avl-title-input and .avl-segment-input classes; a naive iteration applied the replacement twice, producing duplicated suffixes like “Welcome to the Test Page for AI Translations for AI Translations”. Now uses seen tracking + replaceOnce for single-occurrence replacement.
If you still see stale text on 1.0.3+: reload the editor once. Server has the fix, client JS may be cached.
Dashboard chip shows the wrong credit balance between two plugins
Cause: bundle licensing across plugins didn’t always sync. Fixed whenForge_Credits_Widget::push_credits was added — every successful AI call pushes fresh numbers into all four plugin chips.
On a bundle license, the dashboard credits card + each plugin chip read from the same D1 row (credit_balances where product = 'bundle') — they should always match. If they disagree after a manual hard refresh, that’s a cache issue; check wp_cache_flush() ran on the last save or transient-clear.
After import / migration, /wp-login.php 302-redirects to /ru/ (or another language) instead of rendering the login form
Cause: fixed in 1.0.4. Lang Forge’s browser-language auto-detect ran on wp-login.php because WordPress’s is_admin() function returns false there (it only covers /wp-admin/*). When the visitor’s browser preferred a non-default language and the lf_autodetect_done cookie was absent (typical right after an All-in-One-Migration import, which doesn’t carry cookies), the plugin 302’d them to /{lang}/ before wp-login.php could render.
Symptom: visiting /wp-admin/ with an expired session bounces → /wp-login.php?redirect_to=... → /ru/ (or whichever language the browser preferred). Login form never appears.
Fix: the auto-detect guard now also excludes wp-login.php, wp-cron.php, admin-ajax.php (via DOING_AJAX), xmlrpc.php / XMLRPC_REQUEST, and any request URI containing /wp-json/, /wp-login.php, or /xmlrpc.php. The guard only runs on genuinely front-end page loads now.
If you’re on 1.0.4+ and still see the redirect: you’re hitting a cached redirect. Clear the lf_autodetect_done cookie OR hard-refresh the login URL with ?lf_autodetect_done=skip appended once to break out, then reload normally.
If you’re stuck on 1.0.3 or earlier and can’t update yet: visit /wp-admin/ directly — is_admin() returns true there, so the redirect never fires, and WordPress bounces you to wp-login.php server-side without Lang Forge’s hook running a second time. Then log in as usual.