[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 3 years, 12 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.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
My apologies for CloudWays links, I am biased with my previous experience with CloudWays servers. I have been used to deactivate Varnish while debugging an issue.
1) I am downloading the duplicator copy, and hopefully, it will build locally this time. Can you also create another copy on a zip archive that is easier to build manually?
2) First, I deactivated all plugins to be able to log in, then I activated the required plugins. Then I disabled posts/pages from Access management, and now I reactivated them while using the minimum plugins for the theme and the issue to be reproduced.
I was not able to build the copy locally. Check this screenshot hidden link
The copy is a daf archive from Duplicator, I do not know how to open it and take files from it manually.
Can you create another Duplicator copy as a zip archive rather than a daf file?
I have now a local copy of your website and I needed to deactivate really-simple-ssl and woocommerce-pdf-invoice to be able to log in.
Currently, Access is not managing any post type. And I have the following:
- The root page is returning 404 (/)
- Both languages homepage are working fine (/en/ and /de/)
This issue need to be debugged while WPML is activated. I'll work on it tomorrow morning and get back to you.
The reason Access is not managing any post type is because I deleted them all as part of trying to solve this issue today and haven't set the values to that which we had previously, although you can see that in your migrated site.
I have all my settings documented in Excel if you like, I can send that to you in a private reply if that's helpful.
We don't use the root page because we have WPML, so it's just the /en and /de sites. /de is not working for many Pages because we are building our prototype in English and then translating everything later, so please focus on getting the /en working.
Hi Simon. Indeed, I would like to test the same setting here for more analysis. Your next reply will be private to let you share your excel file safely.
Sorry but the access are not working for me. The server name is not connecting, but I was able to connect to hidden link with the provided credentials. Unfortunately, it does not contain the xl file. You can use my email jamal.b(at)onthegosystems.com and reply here to return the ticket to my queue.
I think that we were digging the wrong hole. It seems that you are actually using a root page in WPML. hidden link
The root page is a regular WordPress page that was private. Guest users can't view a private page. That's why:
- Path /: the root page was private.
- Path /en/: the English homepage is working.
- Path /de/: the German homepage is working.
I made the page public and the error seems resolved for the homepage. Check it with a private browser window hidden link
Thanks for the update. I'm not sure if I can concur with your findings, based on follow-up testing:
I tested
- setting the root page back to Private and am still able to open the homepage and root page successfully.
- setting it back to Public and am still able to open the homepage and root page successfully.
- The root page has been Private since we have started developing and hasn't been an issue up until this version of Access. I can get the root page and homepages to display as expected regardless of whether the root page is set to Private or Public.
-- Root page set to Private: hidden link displays just the header and footer with no "body" - correct
-- Root page set to Public: hidden link displays the header, root page in the middle and footer - correct
I would expect nobody except the admins (and possibly also a page author) to be able to view Private pages. Surely that is the point of marking a page as private - so that only the owner (and admins) can see it?
This doesn't address the core erroneous behaviour of Toolset Access when trying to make Access manage the security for Posts. As soon as I activate it under Access > Posts > Managed by Access > Save, the site crashes and I can't open
- dev.native-nanny.com or
- dev.native-nanny.com/en or
- dev.native-nanny.com/de
Hence from my tests, THIS would appear to be the core issue, since the root page and the homepages display correctly when Access is NOT managing security for the category Posts, regardless of whether the root page is set to Private or Public.
Indeed, when a page is private, it should be visible only to the author of the page and to admins. That's why you are still able to visit the root page when it is private. If you test with a private window(not logged in as admin), the root page will actually display the header and footer but it is 404 page. Check this screenshot hidden link
I won't expect the root page to work for guest users when it is set as private. If Access allowed this previously, it is probably a bug. I would not be sure and I'll find out with our 2nd Tier if it is so. The root page is meant to be accessed by all types of visitors, specifically guest users.
The homepages for both languages(/en/ and /de/ ) are public pages, they will be accessible to guests too.
In fact, as soon as we activate Access management for posts, there is an error. I was able to reproduce this issue on a clean install with Toolset Access, WPML and Avada, and without having a root homepage.
A quick workaround would be to add the following code at line 399 of types-access/application/models/wpml_settings.php
On testing again with a private window, the behaviour is I described previously, I don't get a 404. See screenshots. It's not a big deal, as we will be leaving it on Public, but I just wanted to prove the current behaviour to you.
1) What is the purpose of this code exactly? I'm not a PHP developer (yet 😀), but have good technical knowledge from other IT fields.
2) Yes, please escalate this ticket as it has been open for a while now and I don't feel we are much closer to a solution or a workaround.
I escalated the ticket with a clean Duplicator copy to our 2nd Tier. After some activation/deactivation of themes and plugins he reported that the issue disappeared. I tried it on my local copy and the clean install and in your test site to no avail. So I escalated a copy of your site and I am still waiting for a reply.
I am not sure what causes the issue, but it seems that Avada has an integration code with WPML that calls a function before the time where all its dependencies are loaded. The patch consists actually of loading one dependency if it is not yet loaded.
I'll wait for our 2nd Tier before making any conclusions on that.
