Hello Simon,
Our 2nd Tier has confirmed that it is a bug that appears with PHP 7.3 and is now analyzing it to find a solution or workaround for it.
I'll keep you posted as soon as we got more news.
Best regards,
Jamal
HI Jamal
Thanks for the update. It's good to know the root cause has been found.
Kind regards
Simon
Hello Simon,
Please replace the existing wpml_settings.php file in plugins/types-access/application/models/ with the file from this file hidden link
I checked it against my local copy and it worked. Let me know if it will work for your live site.
Best regards,
Jamal
HI Jamal
I replaced the file as requested and retested.
As soon as I saved the Posts after marking them as "Managed by Access" again, I got the WP standard recovery email "Your Site is Experiencing a Technical Issue", however I am not able to ascertain what that technical issue is. As far as I can see it seems to be working again, with the setting activated, however I'm concerned that something is still not right, otherwise that email wouldn't have been triggered.
I tested undoing the setting, saving, then activating "Managed by Access" again and saving, but the email didn't get triggered the second time, which is annoying. So I'm left with the uneasy feeling that something invisible in the background is not working as it should do, but I can't see it .
How did your site behave when you activated it for the first time after applying the workaround?
Kind regards
Simon
Before I tested the patch on my local setup, I visited the homepage and I made sure that it was triggering the fatal error. Then I applied the patch(replacing the file) and the homepage was working fine.
Please activate PHP debugging for a couple of hours to see if the same error will be written again on the debug.log file. Let me know then what you will get.
Hi Jamal
Apologies for the late response. I haven't had a chance to activate the logging yet - will do so either tonight or tomorrow and give you a further update. Otherwise the robot will close this ticket 🙂
Thanks and regards
Simon
Hi Simon and thank you for your feedback.
I'll make sure the Robot will not close the ticket for enough time to get this issue resolved. Three weeks should be enough 😉
So I am setting this ticket as waiting for your feedback.
Looking forward to seeing the results you will get.
HI Jamal
I have activated PHP debugging logging. Changing the Toolset Access setting didn't trigger any warnings in the log file so far.
Is Dev working to patch this in the next update? Or how long approximately do you think the permanent fix will take? (Of course I appreciate you cannot give an exact response, but are we talking days, weeks or months?
Thanks and regards
Simon
Hello Simon,
I can't tell when is the coming version will be released. We, at support, have no visibility on it. But I can see that the fix for this case(with Avada), has been tested and ready to be merged on the code. But, I am not sure if it will be merged on the next release or another one.
I'll set this ticket as resolved in the next release, and when Toolset Access is released, I'll check it again and get back to you, sounds good?
Stay safe.
HI Jamal
That's fine for me, as it is not causing us issues at the moment. Good suggestion.
Was it related to the fact that we are using Avada as well?
Thanks and regards
Simon
Hello Simon,
Yes, indeed. This issue appears when all these conditions are met:
- Avada theme.
- WPML Multilingual CMS.
- Toolset Access.
- Posts permissions are managed by Toolset Access.
Avada tries to load some settings before Toolset plugins have loaded. I'll get back to you as soon as we publish a new Toolset Access version.
HI Jamal
Just to let you know, I just updated to the latest release from a few days ago and the issue is not resolved. As soon as I set Access to control Post permissions I get the following error message:
Thanks and regards
Simon
Fatal error: Uncaught Error: Class 'OTGS\Toolset\Access\Controllers\CustomErrors' not found in /var/www/kle1116-204/apps/dev/wp-content/plugins/types-access/application/models/wpml_settings.php:400 Stack trace: #0 /var/www/kle1116-204/apps/dev/wp-includes/class-wp-hook.php(287): OTGS\Toolset\Access\Models\WPMLSettings->check_language_edit_permissions(Array, Array) #1 /var/www/kle1116-204/apps/dev/wp-includes/plugin.php(206): WP_Hook->apply_filters(Array, Array) #2 /var/www/kle1116-204/apps/dev/wp-content/plugins/sitepress-multilingual-cms/sitepress.class.php(2800): apply_filters('wpml_active_lan...', Array, Array) #3 /var/www/kle1116-204/apps/dev/wp-content/plugins/sitepress-multilingual-cms/inc/template-functions.php(110): SitePress->get_ls_languages(Array) #4 /var/www/kle1116-204/apps/dev/wp-content/themes/Avada/includes/lib/inc/class-fusion-multilingual.php(225): icl_get_languages('skip_missing=0') #5 /var/www/kle1116-204/apps/dev/wp-content/themes/Avada/includes/lib/inc/class-fusion-multilingual.php(123): Fusion_Multi in /var/www/kle1116-204/apps/dev/wp-content/plugins/types-access/application/models/wpml_settings.php on line 400
Hi Jamal
Are these the fixes for our issue? I'm hesitant to update the plugin...
Thanks and regards
Simon
Hello Simon,
Indeed the fix was also released on this week's update. I also replied to your other ticket. I am replying here to change this ticket status.
I tested it on my local copy and it works no 404 errors or fatal errors on the homepage when pages and posts are managed by Toolset. The WPML root page should be public though, otherwise, guest users will get a 404 on the root URL.
Best regards,
Jamal
Hi Jamal
Thanks. I'll give it a whirl and give you feedback.
Best regards
Simon
