Violation of access restriction in Link selection list

Hi Karl,

You wrote:

When creating a new post and adding a link referring to existing posts…

Were you just adding hard links to these posts in the text editor? Unfortunately the plugin can’t handle such a case. What you enter in the editor is more or less plain HTML which is totally unconnected to the WordPress internal post selecting functions.

You could add all posts in question to a category (lets call it “Editables” by now), and offer your users a category archive page for posts selection. This archive page will list up only these posts, a user has reading access to.
In order to show only posts a user has edit access to, you simply set the value of “who can edit” to the same value as “who can read”. (If you a huge bunch of posts WordPress’ bulk edit feature will help you.)

If you want to set up a hierarchical permission structure (similar to a free / pro / premium membership model) this article may be helpful: https://github.com/mcguffin/wp-access-areas/wiki/Inferior%20Roles

Hope I could help. Please let me know if not.
regards, j?rn

Maybe I was not clear enough.

I am not inserting hardlinks.
I do the following steps:

– Login with role “Interessent”
– Create a new posts as “Interessent”
– Write a text “blabla”
– Selecting the text
– Using Button “Add Link”
Now you can enter a Hardlink or you can open a list widget where you can select existing posts and pages. In this list all posts will be shown to “Interessent”, which seems not correct for me.
Of course “Interessent” will see only the head line of the posts, but this already enough to know what other roles are discussing.
When inserting the link in the post and selecting the link a 404 message appears which is correct. I am talking only about the shown headline in the “add link” dialog.

For example: In widget Recent Posts and Recent Comments in start page the behavior is correct and “Interessent” will see only the restricted posts and comments.

I hope I was clear enough.

Karl …

Okay, now I got it…
Yep, sure. This is a bug. There is a (suspiciuosly easy) fix for this, but it would require further testing, to detect if other WP parts may be affected.

As a hot-fix this line of code added somewhere in your theme functions.php may help for the moment:

add_action( ‘pre_get_posts’ , function( $wp_query ){ $wp_query->set(‘suppress_filters’,false); } );

j.

Hi J?rn,

thanks for your quick and professional support.
I will check the line of code later on and I will wait for an update.
I will do now a 5* rating and I will close this topic.

Thanks again.

Karl …