[Resolved] Activating Toolset Access crashes the site
This thread is resolved. Here is a description of the problem and solution.
Problem:
The user site crashes after activating Toolset Access.
Solution:
This is an issue that happened when:
- Using Avada theme.
- Using WPML.
- Managing the default post types(posts, pages) with Toolset Access.
The issue was resolved in Types 3.3.11 and Access 2.8.6
This support ticket is created 4 years ago. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
In my case, I have disabled all plugins using FTP, by renaming the plugins folder. Then I logged in. Then I renamed the plugins folder back and activated some plugins.
It seems that there is an error between Toolset Access and WPML. But this error is happening on some special cases and does not block me from logging in to the backend.
I deactivated Toolset Access and WPML plugins, this should let you log in to the backend.
Please reactivate the plugins and check which page is causing this issue.
Also, reactivate Access for products and check if the issue with the homepage is reproduced.
I activated all the necessary plugins to make the site work at a basic level (and deleted a couple of them from the standard installation) and loading the homepage works fine until I activate Toolset Access.
Once I try to load the homepage after activating Toolset Access I see these errors:
Fatal error: Uncaught Error: Class 'OTGS\Toolset\Access\Controllers\CustomErrors' not found in /mnt/BLOCKSTORAGE/home/219772.cloudwaysapps.com/snkvzuwbjs/public_html/wp-content/plugins/types-access/application/models/wpml_settings.php:400 Stack trace: #0 /mnt/BLOCKSTORAGE/home/219772.cloudwaysapps.com/snkvzuwbjs/public_html/wp-includes/class-wp-hook.php(287): OTGS\Toolset\Access\Models\WPMLSettings->check_language_edit_permissions(Array, Array) #1 /mnt/BLOCKSTORAGE/home/219772.cloudwaysapps.com/snkvzuwbjs/public_html/wp-includes/plugin.php(206): WP_Hook->apply_filters(Array, Array) #2 /mnt/BLOCKSTORAGE/home/219772.cloudwaysapps.com/snkvzuwbjs/public_html/wp-content/plugins/sitepress-multilingual-cms/sitepress.class.php(2798): apply_filters('wpml_active_lan...', Array, Array) #3 /mnt/BLOCKSTORAGE/home/219772.cloudwaysapps.com/snkvzuwbjs/public_html/wp-content/plugins/sitepress-multilingual-cms/inc/template-functions.php(110): SitePress->get_ls_languages(Array) #4 /mnt/BLOCKSTORAGE/home/219772.cloudwaysapps.com/snkvzuwbjs/p in /mnt/BLOCKSTORAGE/home/219772.cloudwaysapps.com/snkvzuwbjs/public_html/wp-content/plugins/types-access/application/models/wpml_settings.php on line 400
There has been a critical error on your website.
This error occurs, despite the fact that Toolset Access is configured to NOT manage the Woo Products.
From what I gathered so far, posts and pages were managed by Access but there were not enough permissions given to default roles. Once I deactivated posts and pages from Access management the error was not reproduced anymore.
Before deactivating pages from Access management, the default language was returning 404.
Can you elaborate more on why did you managed posts and pages by Access and deny default roles from access to them? If I understand better what you try to do, I'll advice better.
I currently cannot access my WP admin on my original site, so I'll have to work getting that accessible again, probably in the same fashion as you suggested using FTP to rename plugins folder etc.
We don't use Posts at all, so that was all set to Admin only.
We use Pages, and its settings were set to different roles. If these settings have been lost by reinstallation it is not a problem, I have them all documented in Excel. If you like, I can share an Excel document with you with how I set all the Toolset Access rules, however don't want that to be in a public response.
I believe that both posts and pages should be at least read by all roles, guests included. Otherwise, default features will not work correctly.
Then you can customize your post types depending on the custom roles.
I just caught your email there. I just wanted to know, are you still investigating on your side what went wrong on our site or are you waiting for my feedback first? I'm working on another project today, but don't want to delay you unnecessarily.
I actually stopped debugging investigating the local copy when I found that pages and posts were deactivated. I believe this is what was crashing the site. Settings Access control on other post types, even if it may show issues, it will not crash the website.
Pages must be accessible(read) to all roles even guests. Then you can disable some pages with post groups, or you can show/hide content on pages with conditionals.
Posts seem to contribute to the issue. I'll suggest keeping the default access Control for default roles and customize it for custom roles. If you are not creating a blog page and no posts, then no issues will emerge.
Finally, regarding other custom post types(products as an example), you can define Access Control the way you want and if you encounter an issue, we can check it.
I cannot find anywhere in the documentation that states that Posts should be set to read for all users. We have had Posts on Admin only from Day 1, it was the first things I switched off and everything worked fine up until a few days ago. Which documentation are you referring to?
Also where is it stated that all Pages must be accessible (read) to all roles even Guests? Am I missing something in the documentation? I can see that your suggested logic would work theoretically for Pages.
Nevertheless, I will start with resetting everything and setting it as we had it before with the exception of Products and work from there.
Please can you point me to the info in the docs that I have missed?
I've done some testing and have an easy reproducible case.
1) Open Toolset > Toolset Settings > Access tab > Remove Access settings from my database > Remove Access settings from the database (but keep the Custom Roles) > Reset Access settings. Confirmation received: "All done! Access settings are back to default now"
2) Open Toolset > Access Control > Post Types > Posts
3) Activate "Managed by Access" with standard default WordPress settings and click Save >> website immediately not available on homepage
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(2798): 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
4) Deactivate "Managed by Access" on Posts and click Save >> website immediately loadable again on homepage.
HOWEVER, on refresh of the WP Admin page, I can see Access has somehow deleted all the default settings on Posts (all the ticks have disappeared, except on Administrator).
5) Only way to restore default ticks is to repeat Step 1.
So basically I am unable to use Access at the moment.
Hello Simon and my apologies for the late reply. I had to perform additional testing before getting back to you.
I checked the migrated site and it is working with Fusion, WooCommerce, Toolset, WPML plugins, Toolset Access activated.
We still have the migrated settings for Toolset. Posts and Products are managed by Toolset and are accessible only for admins. Pages are accessible to admins and readable by other roles.
I suspect that you have a server caching system that is causing this issue. I think Cloudways has Varnish activated, can you deactivate it and test again?
You are right, I could not find some documentations that prevents to manage default types(posts and pages) by Toolset, it was my mistake. I thought that while you are having pages(like the homepage), you will at least make them readable to guests. I also thought that WPML may need it.
Please check if disabling caching on Cloudways will let you activate Toolset Access without issue.
I had already deactivated and deleted Cloudways after the migration was successful as I don't like having extraneous plugins installed. Also, this was installed by you for the first time AFTER we had had the error, so it could never have contributed to the error in the first place.
I meant by Cloudways cache a server-side caching implemented outside of WordPress. Check this article hidden link
Check here how to disable Varnish hidden link
If this does not help. We can try another migration. If the migrated site presents the issue we'll investigate it further. If it does not, we'll still suspect something with your server.
