Skip Navigation

[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, 7 months 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.

Sun Mon Tue Wed Thu Fri Sat
9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 - - 9:00 – 13:00
14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 - - 14:00 – 18:00

Supporter timezone: Africa/Casablanca (GMT+01:00)

This topic contains 57 replies, has 2 voices.

Last updated by simonM-5 4 years, 5 months ago.

Assisted by: Jamal.

Author
Posts
#1599449

These errors are preventing you from logging in.

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.

#1599467

Hi Jamal

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.

Kind regards
Simon

#1599489

Thank you Simon. I'll get back to you as soon as I found something.

#1600707

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.

#1600711

Hi Jamal

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.

Kind regards
Simon

#1602821

Hi Jamal

Is it worth trying to use the Toolset > Settings > Access > Reset Access Settings > Remove Access Settings from my Database?

I have all the settings I used documented and could quickly reinstate these.

What do you think? Am I going to end up at the same crossroads?

Would appreciate your advice, as this issue is posing more and more of a problem for us.

Thanks and regards
Simon

#1604035

Hello Simon and my apologies for the late reply, I do not work on Mondays.

In fact, removing access settings from the database will get the default WordPress permissions. And you can reconfigure the permissions for your custom roles, custom types, forms, and the post groups if you need them. Check this article https://toolset.com/documentation/user-guides/access-control/how-to-reset-access-settings/

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.

#1604291

Hi Jamal

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.

Best regards
Simon

#1604389

Hi Simon,

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.

Best regards,
Jamal

#1604399

Hi Jamal

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?

Thanks and regards
Simon

#1605443

HI Jamal

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.

Kind regards
Simon

#1605673

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.

#1605827

HI Jamal

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.

Thanks for checking up on the documentation. They state quite clearly that controlling standard post types is permitted. (https://toolset.com/documentation/user-guides/access-control/setting-access-control/)

Any further ideas?

Thanks and regards
Simon

#1605857

Thank you Simon.

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.

Best regards,
Jamal

#1605923

Hi Jamal

Forgive me, but I feel all the links regarding Cloudways etc aren't relevant or lead me to some support sites for software that I do not use.

1) I have just created a manual Package with Duplicator Pro. You can login to our site and grab it.

2) What changes did you make on the migrated site, to get Toolset Access working?

Kind regards
Simon