[Resolved] WPML 4.7 - missing strings on multisite.
This thread is resolved. Here is a description of the problem and solution.
Problem:
The taxonomy "translation_priority" was missing on the client site.
Solution:
To fix this, you need to go to WPML > Languages.
There click on Add / Remove Language and click on the "Save" button without selecting anything else and wait for the Ajax process to complete.
Once this is done, please clear your browser cache and re-open WPML > String Translation page and filter by any domain that you wish.
Background of the issue:
I wanted to try the new 'Easy Theme & Plugin String Translations' feature. I installed WPML 4.7 on two of my websites. It works fine on infinityarchmedia.com, but on weigertimages.com, which is a multisite, I could not see my strings anymore. I reverted back to 4.6.x and everything is fine again.
Symptoms:
On weigertimages.com, a multisite, I could not see any strings anymore. When I chose all strings on all domains or on any domain and clicked on 'filter', I got the message: 'no strings found.'
Questions:
Why are strings not visible on my multisite after updating to WPML 4.7?
How can I resolve the issue of missing strings on a multisite with WPML 4.7?
The strings should appear just fine there.
Perhaps we have another issue or an issue with a 3rd party plugin.
Would it be possible that you enable debugging on that site so that we can see if there are any database related issues in the error log?
You can provide us with the log by setting this options in wp-config.php
// Turn debugging on
define('WP_DEBUG', true);
// Tell WordPress to log everything to /wp-content/debug.log
define('WP_DEBUG_LOG', true);
// Turn off the display of error messages on your site
define('WP_DEBUG_DISPLAY', false);
// For good measure, you can also add the follow code, which will hide errors from being displayed on-screen
@ini_set('display_errors', 0);
and reproducing the problem.
Then the error would be written to wp-content/debug.log file
Alternatively if it is possible, please provide temporary access so that we can check the issue on the site.
Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in /data/domains/weigertimages.com/web/webroot/wp-content/plugins/wpml-string-translation/classes/gettext-hooks/AutoRegisterSettings.php on line 181
I found out in debug mode, that I get the same error message on both websites, it is not related to the multisite issue! The string filtering still doesn't work on the multisite, there is a bug somewhere in the code.
I asked Google Gemini and ChatGPT and both solved me the error message above. I am on PHP 8.1 right now and after switching to 8.0 the error code disappeared. Or I can fix the code alternatively:
This is the problematic code in AutoRegisterSettings.php:
public function isAdminOrPackageDomain( $domain ) {
return 0 === strpos( $domain, \WPML_Admin_Texts::DOMAIN_NAME_PREFIX )
|| $this->package_domains->isPackage( $domain );
}
The corrected version by Google Gemini, which is basically identical to chatGPT's solution (it works, I tried it):
public function isAdminOrPackageDomain( $domain ) {
if ( $domain === null ) {
return false; // Or handle it differently if needed
}
"The issue you're encountering is caused by PHP 8.x's stricter type handling. The strpos() function is being called with a null value for its first parameter, $domain. In PHP 8.x, passing null to a parameter that expects a string is deprecated, resulting in the error message."
Hello!
Thank you for providing the error from the log and I will escalate the case to one of our developers.
Yes, indeed this can be fixed pretty easily, but I am afraid that this may mask a bigger underlaying issue on the sites that you have.
I feel that some of the strings that you may have may not be set properly and don't have a valid textdomain assigned to them.
The method \WPML\ST\Gettext\AutoRegisterSettings::isAdminOrPackageDomain indeed iterates over known textdomains. They are obtained from icl_strings table and the column "context" which is responsible for keeping the textdomain.
If you have a value for context there with NULL, this will produce a deprecated warning.
Since you have the pretty strict PHP 8.1 this deprecation warning may indeed trigger a fatal error.
However, my point here is that you should not have strings without set a textdomain.
e.g. you might have something like:
Regarding the debug error message: I checked it and there is no error message with the former version of WMPL + String Translation. I have the error message on both of my websites with the new version. It doesn't affect functionality, though. The real issue is that on my multisite, string filtering doesn't work at all with the new version.
I checked the icl_strings tables of both of my websites and I don't have any NULL values in the context columns.
I did not do anything special with the strings. I used the string translation normally from the dashboard by adding new tranlations with the + signs. I did not touch any code. I just used the WPML plugin normally as a user, so I guess any error I experience is a bug from development.
Well actually the value can be blank or a non-breaking space ("" or " ") instead of null - which will create the notice. I also feel that the context column, being varchar, cannot support NULL in this scenario, as we define the column as `NOT NULL` explicitly.
There is also another place in the code that refers to an option sub-key "wpml_st_auto_reg_excluded_contexts" if it is defined and having a bad (NULL or blank) value - so the issue may not be directly with icl_strings table, but rather a leftover config from the older version of WPML and String Translation.
All in all, the ticket is escalated to our developer and it will be addressed soon.
In the meantime, you can use the workaround that you discovered as it is safe in my opinion, at least until a patch version is released.
Please let me know if I can be of further assistance to you in regards to this issue, and if you need me to check for that value. In that case, I would need a temporary access (and to probably install a database management plugin) and I can activate the secure form where you can share the credentials with me.
Hello!
This is a bit of a separate case that we originally discussed in which I focused on strpos(): Passing null.
Please provide a temporary access credentials so that I can check the issue on your site.
Thank you for the package.
I deployed in locally, and for me, the strings are being displayed properly when I updated to latest WPML package for the main plugin and for String Translation plugin.
I am adding here a screenshot
That being the case, I feel that we might have some other issue over there - perhaps with cache or with the server itself - but I have to guess - it might be a firewall or another security measure.
Another possibility is that I may be missing a vital step on how to reproduce the problem - in which case, I feel it might be beneficial if you can record a short video showing the problem.
Thank you for the screenshot. I also have all the strings displayed when I open the page.
Did you make any filtering? Please choose for example plugin_ngg (or all domains) and make a filtering for it. The problem is that I get an empty screen here with the new version.
I stopped using cache plugins on my website.
If it is working on your side with the filtering, too, I'll make a video of the new version.
Thank you for the clarification on how to reproduce the problem
I see the issue.
To fix this, you need to go to WPML > Languages.
There click on Add / Remove Language and click on the "Save" button without selecting anything else and wait for the Ajax process to complete.
Once this is done, please clear your browser cache and re-open WPML > String Translation page and filter by any domain that you wish.
The issue should be resolved.
