jeroenM-12
|
+1 for getting this fixed. We run into the same issue. The setup described, using a proxy PHP loader + actual plugin within a subdirectory, actually ironically seems to be "the WordPress way", as can be read on the link posted earlier in this thread (here again: https://wordpress.org/documentation/article/must-use-plugins/#caveats)
Just to summarize:
- We have two plugins (that have to run) in the mu-plugins folder. Both in in their own subdirectory.
- Both plugins are being loaded with the proxy PHP loader file, which loads the mentioned plugins using require_once.
- WPML only finds the loader file (which doesn't have a text domain) and doesn't find the actual plugins (which do have a text domain).
- The strings in the plugins can not be translated, even though they are being called using the proper __() functions, which gets passed the textdomain at any time.
Expected behaviour: the plugins within the subdirectories within the /mu-plugins directory should show up in WPML, with the correct text domains. They should be "scanable" for string, so the strings become translatable.
|
ondrejd-2
|
This thread was started back in 2020. 3 freaking years and your so called team did nothing about it. Can you please move your lazy asses and do something already? I am sick of trying to find hacks to get WPML to behave as expected.
Every single time I come here for advice I find unresolved tickets.
Every single time I contact you your answers are vague and not helpful at all.
Bunch of unprofessional morons if you ask me.
This plugin caused more headaches than all other plugins combined together.
|
martinA-36
|
This should be fixed asap, it can't be more than 4-5hours of work to read out the php files of the mu-plugins folder.
|
mikeD-5
|
Has there been any movement on this? It would seem that you know what the issue is given https://wpml.org/errata/must-use-plugin-not-available-for-string-scanning-in-theme-and-plugins-localization/ so I don't really understand why this is still a thing.
|
