[Closed] Redirect non-logged in users to custom login URLs for certain custom post types

[Author]

Posts

[simonM-5]

Hi Support

We want to be able to redirect non-logged in users to our custom login URLs first if they are not logged in. For example, we want to send a notification when they have received a new message using our internal messaging system built with Toolset, but if they are not logged in they should be sent first to the custom login URLs for the specific WPML languages (en and de):

hidden link (English)
hidden link (German)

After successful login, they should then be redirected to the originally requested URL.

The same kind of background logic should apply when URLs try to access full single posts of the Toolset custom post types: nanny, family, nanny-ad, job-ad, message.

I have seen various posts on the Toolset forum which seem to indicate that this should be possible. I cannot find a plugin which matches our requirements.

I envision some complications involved with our current use of Toolset Access. For example, we have a Toolset View "Find a Native Nanny Guest Search and Results View" which allows a "basic" viewing by guest role of the custom post type "nanny-ad", but the Page containing this view is only accessible for guest role. The Toolset View "Find a Native Nanny Search and Results View", however, is on a Page only accessible to logged in users of one of the family roles (family, subscribed_family, lapsed_family) in order to view the complete single nanny-ad post type. This page access is controlled using Toolset Access. So I can't "ban" guest role from seeing the post type nanny-ad.

Analogously, we have a similar issue with post type job-ad, which currently shows basic fields from post type job-ad in the view "Find a Job Guest Search and Results View" on a Page only accessible using Toolset Access by role guest, and a view "Find a Job Search and Results View" which is only accessible on a Page controlled by Toolset Access using role "native_nanny".

It seems I may have used what now appears to be a "workaround" of controlling access to Pages rather than checking whether a user is logged in, before accessing any of the custom post types nanny, family, nanny-ad, job-ad, message.

Is there a way to achieve our goals? For example by adding something to the single Content Templates perhaps?

I hope my explanation is clear. Please let me know if something is unclear.

Kind regards
Simon

[Waqar]

Hi Simon,

Thank you for contacting us and I'd be happy to assist.

Through the Toolset Access plugin, you can control to show different content to different users based on the user role or logged-in status, however it doesn't offer any redirection feature.

For something like this, you can include some custom code, that can redirect the visitors to the login page, depending on the set conditions or excluded pages.

You'll find example of such a code, in this forum reply:
https://toolset.com/forums/topic/redirect-users-to-login-page/#post-1737361

I hope this helps and please let me know if you need further assistance.

regards,
Waqar

[simonM-5]

Hi Waqar

Thanks a lot for your update.

I had already come across that post you mentioned while searching the forum for a solution, however that code does not fully meet our requirements, including how to handle WPML-enabled sites.

We would need the code to ensure that the correct language version of the login page as mentioned above (in our case English or German) would be triggered if the user clicked a link to a post in an email. For example from the notification of a new post of post type "message".

From what I understand the code is doing, it's basically redirecting ALL users to login, EXCEPT for pages that are only intended for guest only access, correct?

What that code also doesn't appear to handle is pages that are accessible to both logged in AND guest roles, for example most of the links in our footer. We already had to use another plugin as a workaround to handle our footer links, "Visibility Logic" for Elementor, to get around this.

I think it would be great if Toolset Access (or Blocks/Views) could handle all this automatically, since it already allows us to create non-guest Custom Roles with various capabilities (screenshot).Implicitly then, it could be able to know that certain post types can only be visited by logged in users. Alternatively, the core Toolset software (probably Blocks), might also be modified with an option on the Custom Post Type itself, which would force a secure auto-redirect to a WordPress standard or custom login page if the post type was attempted to be accessed by a guest user.

Toolset often advertises itself as the easy tool for creating directory or member sites, and I've seen on the forum that many other users encounter the same problem with member-only content, so it would seem like an obvious and very useful enhancement.

Thanks and regards
Simon

[Waqar]

Thank you for sharing your feedback.

I can understand that having a role based redirection feature can be useful in a number of ways. But, with the pause on new features ( ref: https://toolset.com/2022/06/whats-next-for-toolset/ ), it would be very difficult to predict if and when something like this is introduced.

Until then, I see two possible approaches:

1. Display logic, without redirection:

You can use Toolset Access to display different content templates to different user roles, including the login form:
https://toolset.com/course-chapter/templates-for-visitors-and-members/

OR

2. Custom code based redirection:

Your understanding about the code snippet from the other ticket is correct. It redirects all visitors who are not logged-in, to login page, except for the pages that are only intended for guests.

But that code is just an example. If the redirection is an absolute requirement, It can be further customized as needed to properly take care of correct language, accessible pages and the user roles etc.

With a website with many sections and pages, it can be challenging to make and maintain a code like this 'airtight'. So, my personal recommendation would be sticking with the built-in 'display logic' option.

[simonM-5]

HI Waqar

Thanks for your response. I was not aware of the technique described by https://toolset.com/course-chapter/templates-for-visitors-and-members/.

I would have to give that a try. Alternatively, I was thinking of getting AI to create the custom code for me, since I am not a PHP programmer. If I had a stab at it, would you be able to help out if it doesn't work (perhaps just be troubleshooting the AI code?)

Kind regards
Simon

[simonM-5]

PS Forgot to mention I won't be able to access this ticket again until next Tuesday at the earliest!

[Waqar]

Sure, please take your time and the ticket will stay open for a couple of weeks.