Home›Topic Tag: Controlling access to front-end content
Topic Tag: Controlling access to front-end content
Access plugin allows you to limit front-end read access to specific pages, posts or custom types and define who will be able to access that content. It also provides the functionality to set access control for specific blocks inside page content, in order to place texts that are visible to or hidden from certain user types.
When you ask for help or report issues, make sure to tell us on which content and user types you are trying to apply access control.
Viewing 15 topics - 391 through 405 (of 436 total)
Problem: My Users View shows "no results found" when sorting by a custom field.
Solution: WordPress has a quirk when sorting by a custom field. If the User (or post or term) does not have a value for that custom field, it will not be part of the results.
Problem: There appears to be a conflict between Yoast and Access. I expected to see a login form but instead I see the actual page, which should be protected.
Solution: An erratum has been published and the latest version of our plugins includes a permanent fix for this issue.
1) Edit the page "Registrazione NCC", section "Post Group", choose option as :
No Post Group selected.
2) Dashboard-> Toolset-> Access Control-> CRED form
in section "CRED Users Frontend Access",
find "Create Custom User with CRED Form "Registrazione NCC"", enable option for guest user.
Solution:
If you auto-generate a CRED form you can mark that it should add a reCaptcha field, or you can add it to an existing form using the Post Fields button (the reCaptcha field appears under "Extra fields").
Problem:
What are the options for displaying different content to different users on the front-end?
Solution:
To display different content on the front-end according to some criteria you essentially have two options.
If the thing being tested relates to the person doing the looking (the user browsing the website is registered and has a certain role because they have paid for a particular membership, for example) then you can use Access to restrict the visibility of whole pages, or to selectively show certain content on a page (as described here: https://toolset.com/documentation/user-guides/access-control-texts-inside-page-content/).
If the thing being tested relates to the thing being looked at then you would need to add custom fields to the content being viewed and then use the wpv-conditional shortcodes to test the content of those custom fields and selectively display what is wrapped in the shortcode, as described here: https://toolset.com/documentation/user-guides/conditional-html-output-in-views/
Problem:
A user with a role of Editor is unable to edit custom posts with WPML, only the administrator can.
Solution:
In WPML > Translation Management > Multilingual Content Setup the first option is to Create translations manually or Use the translation editor.
If you select 1 then you can use Access to set the ability of different roles to edit translations.
If you select 2 then you *must* create a translator within WPML and assign translation jobs to them.