Home › Toolset Professional Support › [Resolved] Toolset view does not display translated content (WPML) according Toolset Access
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 |
---|---|---|---|---|---|---|
- | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | - |
- | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | - |
Supporter timezone: Europe/London (GMT+00:00)
Related documentation:
This topic contains 52 replies, has 5 voices.
Last updated by Nigel 4 years, 6 months ago.
Assisted by: Nigel.
hi, first of all, thanks.
About #1 Yes I understand this and it's fine.
About #2 OK
About #3 I understand that and it's fine.
<you sad>You want to set up a role such that these users don't have general read access to a post type, but you would like these users to be able to see some posts which you specify by adding them to a Post Group. They should be able to see the individual posts, but also when the posts are output by a View (or archive?). This also needs to work in conjunction with WPML, so that if there are translations of the posts included in the group, these should also be visible in the same way to the same users.</you sad>
Yes and this currently is working but for main language only.
Lets set acceptance criteria for that:
toolset_user has no permissions for Series post type.
toolset_user has permissions to see Posts Group "Preview Group"
Posts Group "Preview Group" has Preview INSIGHT Development Plan and Preview ES (the Spanish translation of Preview INSIGHT Development Plan Series) btw in some latest release notes a saw a message about that you dot need to add a translation of the posts to the same group that is managed by toolset access. So it's an open question do I need to add Spanish translation to the "Preview Group".
a. toolset_user has access to hidden link - OK
b. toolset_user has access to hidden link -NOK
c. toolset_user has access to hidden link and see a list of all series on current language (8 items in en) -OK
d. toolset_user has access to hidden link and see a list of all series on current language (1 item in es) -NOK
And yes you allowed installing whatever you need on the site.
Thanks
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
OK Mark, some good news, I have a solution.
I haven't tried it on your site because I'm not sure what you already implemented, I understand you've been registering conditional shortcodes for conditional checks etc.
I started from scratch on my own test site and have a working solution, so let me share that with you.
First, I can confirm/clarify that you must add translations of posts to the Post Group if you want the translations to be visible to the restricted users, it doesn't happen automatically. (I can imagine there may be use cases where you wouldn't want that to happen, but if you have a strong opinion about it let me know and I can share with the devs.)
So assuming you have set up the Post Group accordingly, you'll want to register the following custom shortcode:
/** * Check permission to read post */ add_shortcode('allowed', function () { $userid = get_current_user_id(); global $post; $allowed = apply_filters( 'toolset_access_api_get_post_permissions', true, $post, 'read', $userid, ICL_LANGUAGE_CODE ); $return = ( $allowed ) ? 1:0; return $return; });
It uses the public Access API filter toolset_access_api_get_post_permissions which can be used to check whether the current user has permission to read a post or not (https://toolset.com/documentation/programmer-reference/access-api-filters/#toolset_access_api_get_post_permissions).
It will return 1 if true, 0 otherwise.
After registering the custom shortcode at Toolset > Settings > Front-end Content you can use it inside a conditional shortcode in the output of your View, like so:
<wpv-loop> [wpv-conditional if="( '[allowed]' eq '1' )"]<h3>[wpv-post-link]</h3>[/wpv-conditional] </wpv-loop>
That View is inserted on some page (and the page is translated, and contains the same View).
Without my custom shortcode, if a user that has no rights to see the post type visits the View on the front end they will see all the posts (because Access doesn't affect the output of the View, even when the posts are added to a Post Group to make them visible to this user with the restricted role).
But with the custom shortcode the restricted user now only sees the posts belonging to the Post Group. If they switch to another language they will also only see posts belonging to the Post Group (remembering that the translations need to be added to the group).
Can you try the same on your own site?
Nigel, your solution helps me with filtering the output of the view, which is nice.
However, it doesn't solve the problem that translated content it's still not visible.
hidden link No items found
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
What I've proposed wouldn't be reponsible for the No items found message.
A View queries the database for posts. If not posts match the query you'll get the No items found message.
My solution only kicks in when there are results returned by the query. When the View iterates over those results, we use the conditional check with the custom shortcode to see if the current user is allowed to see each post in the loop, and only output it if they are.
So if you removed the conditional block altogether it would have no effect on the No items found message.
I know through the course of this thread (even before opening it) you have worked on other solutions. You'll need to remove those or disable any other related custom code.
To re-state the problem as I understand it, you have a custom role that does not have permission to read posts of some type, generally. The problem is that they are able to see such posts when they are output by a View, and should not. Some of the posts are assigned to an Access Post Group, and such users should see those in the output of the View, both in the original language and in translations.
That's what the steps in my previous reply achieve.
I can set up a test site online that demonstrates how to set it up if needed.
Nigel, I've tested your solution on Friday, and it works for the original language.
I had a custom solution for filtering view output before.
The problem that my custom solution and your solution work only for the original language.
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
I've created an online test site for you where you can see the solution working.
The site is in English and Spanish, and has a custom post type "Things" with several posts available in both languages.
The English post "Something", its translation "Algo", and another arbitrary Spanish post "Nada" are assigned to an Access Post Group.
The role "subsub" has no read rights to the Things post type, but it does have read rights to the 3 posts in the Post Group.
First, see it working by logging in to hidden link as the user 'ts-limited' with the password 'tssupp'.
Navigate to the English page hidden link where you will see just the post "Something".
Use the language switcher in the footer to switch to Spanish, where you will see the posts "Algo" and "Nada".
That's just the posts belonging to the Post Group you are seeing.
To check the set up, log into the same site as an admin, username ts-markw and the same passord.
Go to Toolset > Settings > Custom Code and note the custom shortcode 'allowed' is registered.
Go to Toolset > Views and edit the View "List Things". Note how the posts are only output subject to a conditional shortcode which checks whether the current user is allowed to see them.
Go to Toolset > Access Control and verify the settings for the custom post type and for the Post Group.
You know your site better than I do to understand what else you have going on that would prevent this solution from working.
Nigel, thanks for the test site. On your site, it's working as expected.
So I started to compare our site to your and the only major difference is that we use Elementor to add the view to the page and you use block editor.
When I switched to use block editor it worked. I can confirm that I can see filtered content in both languages.
That probably means the problem is in Elementor or Elemetor + WPML + Toolset interaction.
Do you have any thoughts about why it's happening?
Or maybe you can share some guesses what is the reason.
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
OK, let me add Elementor to my test site and see if inserting the View using Elementor breaks the solution.
I'll report back.
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
I set it up with Elementor on my local test site and it still works okay, and I've recreated that on the public test site.
If you visit hidden link with the test user and use the language switcher to check the Spanish page you will see that it still works okay.
So there must be something more specific on your site that accounts for the difference.
You are welcome to try things out on the test site that you suspect may be the cause.