Repository navigation
Fixed: Plugin Token reported as invalid on WPML sites with a directory per language - #335
Conversation
Multilingual plugins like WPML (directory per language) filter home_url() to include the current language's directory (e.g. example.com/fr). That ended up in the pre-filled Domain Name, so the Plugin Token never matched the site's domain and was reported as invalid.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ⬇️ Low Change: Bug fix Merge Risk: ⚪ Minimal · up to
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
A customer using WPML (a directory per language) got "Oops! The Plugin Token you used is invalid" during setup, even with a freshly created token.
Cause
When no Domain Name is saved yet,
Helpers::get_domain()falls back tohome_url(), stripping only the scheme andwww.. WPML filtershome_url()to include the current language's directory, e.g.https://www.example.com/fr. The Domain Name field gets pre-filled withexample.com/frand saved like that, soClient::validate_api_token()never matches the token's domain (example.com) and reports the token as invalid.Fix
The fallback now uses the unfiltered
get_option( 'home' ). Multilingual plugins hook into thehome_urlfilter, so their language directory no longer ends up in the domain. Subdirectory installs (e.g.example.com/blog) behave exactly as before.Sites that already saved
example.com/fraren't fixed automatically; correcting the Domain Name in the settings resolves it there.Tests
testGetDomainIgnoresLanguageDirectoryInHomeUrl: filtershome_urlto append/frand checks the domain doesn't contain it.AssetsTesterrors I get locally also occur on a cleandevelop.Summary by CodeRabbit
Bug Fixes
Documentation