🇧🇷 Leia em português

WPML Fix for Ally Accessibility

A lightweight WordPress mu-plugin that fixes the Ally (Pojo Accessibility) plugin by Elementor when used alongside WPML.

The Problem

The Ally accessibility plugin stores your site's home_url() when you first connect it to your Elementor account. It then compares this stored URL with the current home_url() on every page load to verify the connection.

When WPML is active, home_url() returns a different URL for each language. For example:

Note: This issue happens regardless of which language is set as default. Whether your default language is English, Portuguese, Spanish, or any other, the problem is the same: the Ally plugin only remembers one URL, and WPML changes it per language.

If you connect Ally while viewing your site in the default language, it saves https://yoursite.com. When a visitor opens a secondary language, home_url() returns https://yoursite.com/en, the comparison fails, and the accessibility widget disappears.

If you reconnect Ally while in a secondary language, it overwrites the stored URL, and the widget stops working in the default language. It's a never-ending cycle.

This happens regardless of your WPML URL structure:

• ❌ Subdirectories (site.com/en)
• ❌ Different domains (site.com / site.com.br)
• ❌ URL parameters (site.com?lang=en)

Root Cause

The Ally plugin (v4.1.0) has a Cache_Compatibility component that registers a filter called ally_connect_home_url intended to fix this exact issue. However, this filter is never actually called anywhere in the codebase — it's a dead filter. The connection check in Utils.php compares the stored URL directly with home_url() without applying any filter.

The Fix

This mu-plugin intercepts the WordPress option read for ea11y_home_url (where the stored URL lives) and returns the current home_url() instead. This makes the connection check always pass, regardless of the active WPML language.

Stored URL:  https://yoursite.com       (saved at connect time)
Current URL: https://yoursite.com/en    (WPML adds /en)

Without fix:  "yoursite.com" !== "yoursite.com/en"  → FAIL → widget hidden
With fix:     "yoursite.com/en" === "yoursite.com/en" → PASS → widget visible ✅

The fix only activates when:

1. WPML is installed and active
2. The Ally plugin has already been connected (option exists)

It does not modify any files, database values, or the Ally plugin itself.

Installation

1. Download ea11y-wpml-fix.php
2. Upload it to your WordPress installation:

   wp-content/mu-plugins/ea11y-wpml-fix.php

3. If the mu-plugins folder doesn't exist, create it inside wp-content/.

That's it. Mu-plugins load automatically — no activation needed.

Note: You only need to connect Ally to your Elementor account once (in any language). After installing this fix, it will work across all WPML languages automatically.

Requirements

• WordPress 5.0+
• Ally - Web Accessibility & Usability (Pojo Accessibility) by Elementor
• WPML

FAQ

Is this safe?

Yes. The plugin contains a single filter function that:

• Reads no user input
• Writes nothing to the database
• Makes no external requests
• Only runs when WPML is active

Will it break if Ally updates?

No. It uses WordPress's standard option_{name} filter, which is a core WordPress API. Unless Elementor fundamentally changes how they store the home URL (which would break other things too), this fix will continue to work.

Can I remove it later?

Yes. Just delete the file from mu-plugins/. Since it doesn't modify any data, removing it will revert to the original behavior.

Does it work with Polylang or TranslatePress?

This fix is specifically for WPML (it checks for the ICL_SITEPRESS_VERSION constant). However, the same underlying issue may affect other multilingual plugins. If you need support for Polylang or TranslatePress, please open an issue.

License

GPL v2 or later — same as WordPress.

Author

in9ti — João Batista CJ