This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
WordPress 6.7 has introduced a new issue that impact translations, please update WooCommerce and WPML to the latest versions before you report issues. More about this here - https://wpml.org/errata/php-error-wp-6-7-notice-function-_load_textdomain_just_in_time-was-called/
Can you try to move the plugin to the wp-content/plugins folder, scan it for strings, and then move it back to the mu-plugins folder? This might do the trick and have it scanned for strings.
This answer suggests that this is a known issue that can't be resolved without back flips like this. I can't just move the plugin around in this way, the entire site is under revision control and this is unrealistic.
Shall I just assume that this is beyond WPML's capability for now?
There shouldn't be any issue scanning the plugin from the /mu-plugins/ folder. I just created a simple plugin where I added just this code:
function mu_plugin_test_function(){
echo __('this is my test', 'my-basics-plugin');
}
add_action('wp_footer','mu_plugin_test_function');
and the this is my test was scanned once I went to WPML → Theme and plugins localization and scanned the test plugin I created.
Now, there are two more things you can try, other than temporarily moving the plugin to the /plugins/ folder:
1. Make sure that the WP memory limit is at least 128M (256M recommended) - https://wpml.org/home/minimum-requirements/. You can check this value on WPML → Support area. Sometimes, the strings scanning process is not working well if the memory limit is too low;
2. Deactivate all the plugins except for WPML, activate a default theme like Twenty Twenty, and try again to scan the mu-plugin for strings. This way we can make sure that the other plugins that you're using (or the theme) are not the ones causing this issue.
I looked on the WordPress Codes and I found this about the /mu-plugins/: WordPress only looks for PHP files right inside the mu-plugins directory, and (unlike for normal plugins) not for files in subdirectories. You may want to create a proxy PHP loader file inside the mu-plugins directory
Please re-read the ticket and look at the attached screen shot.
1. The plugin is in a folder ('liberal-core')
2. The plugin has a loader that works ('loader-liberal-core.php')
The issue is with WPML, not the plugin.
Try this. Take your plugin that scanned correctly, put it into a subfolder, add a loader, and then see if WPML picks up the strings. Make sure to change them so you're not simply getting the previous scan.
I tested this one as you explained and I was able to replicate the same behavior. I tried to find why is this happening but it seems that this is more complex than I expected. That's why I asked my colleagues for more details about this. I will keep you posted as soon as I have any updates from them.
In the meantime, temporarily moving the plugin into the /plugins/ folder lets you scan it for strings (until I get some updates about this).
I will keep you posted about the progress we're making on this. For now, my colleagues found the part that's making the strings from must-use plugins not be scanned. They are still talking about how we should fix this one.
I will definitely let you know about what we'll do about the strings from the must-use plugins.
Hello! Just following up on this. Would it be better to open a new ticket? I'm facing the same issue as Mike reported, since we use a similar structure, and it's a pretty common practice for mu-plugins that are more complex.
I checked the status of this thread and there's no update about it for now. Our plugin is made to handle the plugins returned by wp_get_mu_plugins, from what my colleagues mentioned in our internal thread. We need to make some changes to our plugin to be able to handle more complex MU plugins.
I will update the status on this ticket as soon as my colleagues will investigate this a bit closer and make the needed changes.
Hi,
We have same issue here, WPML doesn't scan files that are included/required in MU-plugins, only the "init" file.
So for example a MU-plugin containing: (from PHP recommended structure)
<?php // mu-plugins/load.php
require WPMU_PLUGIN_DIR.'/my-plugin/my-plugin.php'; ?>
--> nothing is scanned on the "proxied" file my-plugin.php
We also have this issue, so a +1 for getting it fixed. I understand this works in "the WordPress way" in that it uses wp_get_mu_plugins() - but it doesn't reflect the way a lot of developers build large/complex WordPress sites.
It'd be great to see this way of working supported in WPML; even if it is via filter where we have to manually include files (ideally just the main plugin file within each subdirectory).
