I am trying to: Restrict access (homepage, archive, single posts, WP main query) to logged in post author only.
I visited this URL: Access Control
I expected to see: "Read Own" within the Managed by Access table.
Instead, I got: I read a support ticket from last year stating that this feature is not available; is it still not? if so, what alternatives do you suggest that does conflict with views filter queries?
Read is a setting that applies to all posts (content)
There is no "Read Own" setting.
For this you can use HTML conditional as example, by cehcking if the current logged in user is also the author of the Post:
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/
Thanks Beda; I did try this option but had a problem with pagination. The content of the post will not be visible if logged in user is Not Author/Owner, but:
1. Pagination links will still link to previous and next posts.
2. A skeleton of the empty post is still visible If manually entered the post URL in the browser bar.
What condition should i use for this?
Another relevant question, how can I construct conditional output based on dynamic taxonomies i-e parent, child or both:
1. If the user selects only parent or only child or both or a parent with multiple children.
2. Not having to add redundant conditions to cover all scenarios.
3. Not having to add newly added either parent or child taxonomies across all conditions.
1. Pagination links will still link to previous and next posts.
In any Toolset Pagination instance you can wrap also the pagination in HTML conditionals.
BUt I know what you mean, if you have 10 posts and then paginate by one, the first is not readable it will stil appear as a post (althoug empty)
What if you put a "placeholder" there?
Or another post information?
2. A skeleton of the empty post is still visible If manually entered the post URL in the browser bar.
Yes, but you should use HTML conditonal there as well and maybe present other content in case the user can not view it.
There is no way with Access to set something like "read by author only"
You can create Views though, that show only posts of the curernt user (Post author is the same as the logged in user), and you can (for now) use Custom Code to show single Posts to it's author only, or a Conditional HTML.
What I can do, is ask the developers if it's possible to add this as a feature in Access, as I think it could be useful.
Hi Beda - conditional output is great, but it does not do the trick in this scenario.
I believe adding this feature would simply make Access a complete user security solution, without needing to try to achieve this with additional plugins or playing with WP code. I don't think Toolset would go wrong with implementing it.
Appreciate if you could get back to me when you have an answer from the developers and maybe a time frame.
Thanks again.
I can already say, that any ETA is out of purpose.
We receive so many requests, we can not promise to implement this now and that tomorrow or even in 3 months.
But I will update you here ASAP when teh Developer gets back at me with news on this.
Meanwhile, until eventual future development you can use HTML conditional or Custom Access Groups.
https://toolset.com/documentation/user-guides/conditional-html-output-in-views/
https://toolset.com/documentation/user-guides/limiting-read-access-specific-content/
As I elaborated previously, If you want to only grant access to posts in WP queries and Views queries to the author of posts, instead of taking from all users the "read" capability and then grant the "read_own" capability back, you can use Views filters directly.
https://toolset.com/forums/topic/how-to-best-achieve-read-own-from-within-access/#post-431077
For Views and WordPress Archives, there is a query filter that only returns posts from the current logged in user. If no user is logged in, it returns nothing.
The only glitch missing is for author archives, where this filter does not work, since you here display posts of the author that you view the archive of.
WordPress does not have a read_own capability on its own, and our Developers do not think it is easy or wise to add it.
Yes, for single items it might be simple (check the curret post author, the current user, and compare) but for queries... it does not work that way, it would be a higher usage of resources.
Therefore, we will not implement this.
Thanks Beda, appreciated.
