[Resolved] Custom User Role – just to view pages on the front-end

[Author]

Posts

[Shane]

Hi Georg,

I checked the video, please standby for an update.

Can you update to the latest versions of our plugins ?
hidden link

These updates contains compatibility updates for version 5.8 of wordpress and could help resolve the issue. Before we can debug further we need to update these then check again.

Thanks,
Shane

[georgK-2]

I update everything and it is still not working

[georgK-2]

Any news? It is 10 days into this problem. Thanks

[Shane]

Hi George,

I'll try to get this one resolved today but I can't make any promises since we are still trying to get to the root cause of the issue.

Thanks,
Shane

[Shane]

Hi George,

Just an update here to help move things along.

In checking on the site and the copy I have I found that you were using the WPForms to do the login. Are you aware of any redirection settings on this form ?

Secondly when I try to access the /wp-admin page for the wordpress default login i'm redirected to the page below.
hidden link

Are you able to try logging into your site using the Default wordpress login page using one of the accounts where the issue occurs when logging in using the WPForms plugin.

This is the next step as it appears that WPForms might be imposing its own redirect when trying to log in. In my testing on my end whenever I try to log in using a test account I created on the copy locally I was able to login successfully without any redirection issues when using the /wp-admin page.

Thanks,
Shane

[georgK-2]

Hi - wpforms is not doing any redirects. The error also occurs when you use the standard wordpress login.
We tried a bit to update the htaccess file, without success. You should be able to login via hidden link. Our client is on our toes already. We have this problem for over 10 days. How do we proceed? let me know - thanks

[Shane]

Hi George,

So i've narrowed it down a bit to the issue being the professional role as you mentioned.

From what I can see this role wasn't created with our Access plugin and was created using the code you shared in your previous post.

I've created a user role similar to the Professional role with Toolset Access and tried logging . The user that was created was "Shane" and the password is "pass1234"

You will see that you're able to log in without issues.

Also your site itself has plenty of redirects and i'm not sure if this was something that was added in the .htaccess file of the site but when debugging I would advise removing all of the redirects while testing to see if the user login works without any issues. From there we should be able to dive further into the issue.

The reason this is taking some time is because Toolset doesn't do any redirects unless you are logging in using our Frontend form in which case you will need our Views plugin but this isn't the case. So we need to take debugging one step at a time by eliminating possible causes.

Thanks,
Shane

[georgK-2]

Hi

I tried with your user - as you said you can log in but you can not view any frontend pages
check this short video - hidden link
problem is still the same
I also show you in the video the htaccess which is all fine.
as soon as we switch off the access plugin it all works fine
but we need the plugin to handle all the different user-language-editors

[Shane]

Hi George,

I've come up with a temporary workaround for you as well as able to confirm the redirect issue now being access.

Currently i've installed the User Role plugin on the site which essentially functions the same as our Access plugin. So you're able to control your user role permissions.

This should at least get the client to be able to launch and give us a bit more time unless you are using more components of Access than just the user roles.

However you are able to setup your post type permissions on this as well. At least now i'm able to have a bit more direction on this.

Thanks,
Shane

[georgK-2]

Hi,

but this plugin will not limit a user to a certain languages. The reason why we bought Toolset was, because we need one editor for each language. Otherwise users will publish on other countries sites.

Hope you figure things out. Thanks Georg

[Shane]

Hi George,

I believe I've found the issue at hand now.

The problem is stemming from your read permissions of your WPML group. I was able to confirm this by changing my role to a UK editor amongst a few other tests.

You're going to have to setup the permissions correctly for your Professionals role. Currently this user has no permissions to access any pages which appears to be the cause of the infinite redirects as they essentially have no access to any of the frontpage items.

Thanks,
Shane

[georgK-2]

Can you tell me then please the correct settings? Where do I have to make the changes? Thanks

[Christian Cox]

Can you tell me then please the correct settings? Where do I have to make the changes? Thanks
Hello, Shane is on holiday this week so I'm looking into his tickets. I hope that's okay. Shane's most recent comment said that he thought the redirect problem happens because the Professional role does not have "read" permission in the WPML group. I assume he meant the WPML group containing the redirect destination post. Your site has WPML groups set up, which will restrict access to specific content based on the post type of the content, the language of the content, and the User role. He thought that the problem is related to the Professional role and the WPML group that contains the redirect destination post. He thought that allowing Professionals to have "read" access for the redirect destination post would help solve the problem.

So what is the redirect destination post? Where does the Professional User end up after login? Based on the video I assume the redirect destination should be the Welcome page, at /enuk. If this is correct, then you should make changes in all the language-specific WPML Groups that are associated with the Pages post type, because /enuk is a Page. If there are multiple different destinations, you should allow read access in all the necessary groups that correspond to all those destination posts in all the different languages.

WPML Group permissions are managed in Toolset > Access Control > WPML Group tab. You will find a section of settings for each WPML Group. A WPML Group usually consists of one post type and one language. So I assume Shane meant you should make changes in all the groups corresponding to the Pages post type. This means you should change:
Austria Pages
Czech Pages
French Pages
...and so on, including all the possible languages involved in this login and redirect.

In the settings for each group, you should check the checkbox in the "Professional" row, in the "Read" column. This will give Professional Users the ability to read Pages in that language. I have attached a screenshot showing the location of the checkbox in the Austria Pages WPML Group. I deleted a few rows from the image so the entire table is visible in a single picture. Your actual WPML Group will have more rows, but you get the idea here.

Will this work for your needs, or is there still a misunderstanding about the requirements to solve this problem?

[georgK-2]

So you mean if a user is logged in - and the read checkbox is not checked - he will not be able to see the page/post on the frontend, but he can see it, if he is not locked in. - Correct?

[Christian Cox]

So you mean if a user is logged in - and the read checkbox is not checked - he will not be able to see the page/post on the frontend, but he can see it, if he is not locked in. - Correct?
The behavior for non-logged in Users depends on the permissions you give to Guests in each WPML Group. If the "Read" checkbox is checked for Guests, then yes, you are correct.