I've been having wordpress backend issue and sluggish backend performance and been talking to the site hosting tech. They have scanned my backend and one of the issue is this below. I'm not sure if this is wpml-related so thought to ask. If this is related, what is the best way to resolve this?
I am also seeing some deprecations (old processes that are incompatible
with newer versions) with the plugin sitepress-multilingual-cms:
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type
string is deprecated in
/home/dh_2iqi49/evto.ca/wp-content/plugins/sitepress-multilingual-cms/lib/mobile-detect.php
on line 562
That would require checking with the support of the plugin to check on
why is this happening.
They refer to that in a future version, like PHP 8.2 the function will not longer operate as expected, but at the moment such notices should not harm the site after all.
Anyhow, I will try to recreate this issue on a new test site and let you know.
About the site performance:
Could you please increase your WP Memory limit to 256M? 128M is the minimum required by WPML.
Your current values are:
PHP MemoryLimit 256M
WP Memory Limit 40M
Add this code to your wp-config.php to increase WP memory:
define('WP_MEMORY_LIMIT', '256M');
Paste it just before:
/ That's all, stop editing! Happy blogging. /
Now, verify the current settings at WPML > Support > WordPress.
These settings can be limited directly by your hosting provider, so I recommend you contact and ask them to modify them directly.
If you can get even higher values It would be great.
https://wpml.org/home/minimum-requirements/
Note: WPML needs a minimum WP Memory limit of 128M to work only under a minimal environment, which means, with a default theme and no other plugins installed.
I can sadly not confirm this Deprecated Notice on a new WordPress install with WPML on WPML 8.1 which means that the issue might be linked to specific settings that are not activated on my test site, or the issue only occurs when a specific third plugin is used.
I would like to request temporary access (wp-admin and FTP) to your site to take a better look at the issue. It would be better for a testing site where the issue is replicated.
You will find the needed fields for this below the comment area when you log in to leave your next reply. The information you will enter is private which means only you and I can see and have access to it.
Maybe I'll need to replicate your site locally. For this, I’ll need to temporarily install a plugin called “All In One WP Migration” on your site. This will allow me to create a copy of your site and your content. Once the problem is resolved I will delete the local site. Let me know if this is ok with you and take note, that creating such a package requires sufficient available space on your server.
IMPORTANT
Please make a backup of site files and database before providing us access.
If you do not see the wp-admin/FTP fields this means your post & website login details will be made PUBLIC. DO NOT post your website details unless you see the required wp-admin/FTP fields. If you do not, please ask me to enable the private box. The private box looks like this: hidden link
The steps are also shown in this video: hidden link
It is correct that after migrating the website I do see the mentioned error on the debug.log, but I am unable to recreate it.
On the copy, I started troubleshooting by removing the /mu-plugins/ folder, then deleting the debug.log file and refreshing the website.
On the new debug.log I do not longer see the mentioned error:
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type
string is deprecated in
/home/dh_2iqi49/evto.ca/wp-content/plugins/sitepress-multilingual-cms/lib/mobile-detect.php
on line 562
For now, there is nothing I could do, as I can not confirm that this Notice keeps occurring - usually, the error should show up right away again if is a current Deprecated Notice, but it does not.
Also, take note that our Devs always keep track of such issues and we solve any of them, only in this case, I can not recreate it any longer - it is like the Notice only showed up once right after migration - it does not show up again if I downgrade PHP and update it again to 8.1 - it neither shows up again if I disable WPML and enable it again.
This is why I have to ask you to ignore this Notice for now.
Apart from that there are still many errors, but not any directly related to WPML - which means I see WPML in the Call Stacks, but those errors that I see are WordPress Core related, as even WP Core is not yet fully optimized for PHP 8.1.
Also, take note that those errors only mean, that something on your site will no longer work as expected if you update to PHP 8.2 - there should not be any issue running 8.1 and if you run 8.0 then you will not even see those Notices.
Here are some Deprecated Notices that you will even get on a new WordPress Install with WP 6.1.1 with Twenty Twenty Two and no plugins installed:
PHP Deprecated: Return type of Requests_Cookie_Jar::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wp-includes\Requests\Cookie\Jar.php on line 63
PHP Deprecated: Return type of Requests_Cookie_Jar::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wp-includes\Requests\Cookie\Jar.php on line 73
PHP Deprecated: Return type of Requests_Cookie_Jar::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wp-includes\Requests\Cookie\Jar.php on line 89
PHP Deprecated: Return type of Requests_Cookie_Jar::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wp-includes\Requests\Cookie\Jar.php on line 102
PHP Deprecated: Return type of Requests_Cookie_Jar::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wp-includes\Requests\Cookie\Jar.php on line 111
PHP Deprecated: http_build_query(): Passing null to parameter #2 ($numeric_prefix) of type string is deprecated in \wp-includes\Requests\Transport\cURL.php on line 530
PHP Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wp-includes\Requests\Utility\CaseInsensitiveDictionary.php on line 40
PHP Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wp-includes\Requests\Utility\CaseInsensitiveDictionary.php on line 51
PHP Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wp-includes\Requests\Utility\CaseInsensitiveDictionary.php on line 68
PHP Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wp-includes\Requests\Utility\CaseInsensitiveDictionary.php on line 82
PHP Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in \wp-includes\Requests\Utility\CaseInsensitiveDictionary.php on line 91
I am sending you this, in order to clarify, that even WP Core is not fully optimized for the latest PHP Version 8.2 and those are issues that might get solved sooner with the update to WP 6.2. or later versions.
Best regards
Andreas
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
