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 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.

This topic contains 57 replies, has 2 voices.

Last updated by simonM-5 1 year, 5 months ago.

Assigned support staff: Jamal.

Author
Posts
#1605931

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

Hi Simon,

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.

#1605933

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

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?

#1605951

Hi Jamal

I have created a zip package. Please see if you can download that.

Thanks and regards
Simon

#1606021

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

It is still not working. Check hidden link
Probably because the archive does not contain wp-config.php file.

The archive seems to contain a database export neither. I created a database only package and I'll try with it.

#1606049

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

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.

#1606067

HI Jamal

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.

Kind regards
Simon

#1606907

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

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.

#1607001
#1608371

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

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.

#1608425

Hi Jamal

Have sent you the file by email

Cheers
Simon

#1609037

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

Hello Simon,

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

Can you check on the production site?

#1609711

HI Jamal

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.

Kind regards
Simon

#1612977

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

Hi Simon,

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

				if ( !class_exists( 'CustomerErrors' ) ) {
					require_once( __DIR__ . '/../controllers/custom_errors.php' );
				}

I am reporting this to our 2nd Tier for further analysis and I'll get back to you as soon as we have more info.

Thank you for your patience.

#1613941
Screenshot 2020-05-06 at 16.31.17.png
Screenshot 2020-05-06 at 16.30.43.png

Hi Jamal

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.

Thanks and best regards
Simon

#1614145

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+01:00)

Hi Simon,

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.

I'll get back to you as soon as possible.