kris-o3world

your concerns are entirely valid. someone else had similar issues discovered by inclusion of the ‘recent comments’ widget in the sidebar, which appears to disregard the filtering of posts by the pre_get_posts hook on which this plugin entirely relies…

our limited use case was to show content relevant to one set of users versus another on a ‘sales team portal’… that site required login to view anything, so i wasn’t concerned with access control on a per-post basis.

with that said, it makes sense to me now the more general need to redirect to the login page if attempting to access a post that is deemed ‘private’.

re: #1, i was only able to replicate this issue by adding a post to both a public and private category… as long as your posts are in mutually-exclusive sets, everything works fine; just tested on a fresh install of wordpress 3.4.1 running the twentyeleven theme.

in other words, if a post is meant to be seen by anyone, then Do Not assign it to any private category.

re: #2 it’s definitely true that you can assign each post to as many private categories as appropriate. in my test i created three categories (public, private one, private two) and four posts (one each for the three categories, and a fourth assigned to both private categories) and two test users with access only to private one or two. they each see 3 of those four posts.

re: #3 our use case didn’t require private/public pages but it’s an interesting thought!

to replicate your issue…

i created two categories named private one and private two, and a public category named public. i created posts in all 3. i created two test subscriber users. i logged in as the first and left a comment on private one. i logged out and logged in as the second and left a comment on private two.

and it’s definitely true that i can access those posts by following the links in the recent comments sidebar widget.

someone else had a similar issue with the provided categories widget showing private categories to anonymous users.

i believe this is an issue with how those widgets were engineered i.e. they do not respect the WP_Query parameter for supress_filters => false. which is to say, they are bypassing the filtering being done in my plugin.

in place of the categories widget, give this a try:

<li class="widget_categories">
	<h3>Categories</h3>
	<ul>
<?php foreach( get_categories( ) as $cat ) {
	$cat_current = ( $cat->cat_ID == $curr_cat_id ? " current-menu-item" : "" );
	$cat_link = get_category_link( $cat->cat_ID );
	echo '<li class="menu-item'
		. $cat_current . '"><a href="'
		. $cat_link . '"><span>'
		. $cat->name . '</span></a></li>' . "\n";
?>
<?php } ?>
	</ul>
</li>

downloaded and looked at starkers’ code… don’t see anything necessarily that would affect the categories… i assume its sidebar uses the wordpress standard Categories widget? if so, then this may bring to light an inherent flaw in the Categories widget itself.

jknurse – what wordpress theme are you using?
not all of them ‘play nice’ w/ regards to how categories/menus are rendered i.e. may or may not respect filtering to be done in WP_Query or query_posts.

not sure about a quick-and-dirty fix but depending on what plugins and theme(s) you’re trying to use, i would see which ones actually respect and use the suppress_filters parameter passed to the pre_get_posts hook, on which this plugin heavily relies.

for example, if a given ‘categories widget’ (not sure about the ‘built-in’ one’s behavior) sets supress_filters => false, then it will bypass the filtering that this plugin does to show/hide posts in certain categories, entirely.

this is entirely by design.

to designate a category as a ‘private’ category,
you do so on the Privacy settings page.
as such, you must be an Administrator to do so.

to assign a user to a category that’s been set to ‘private’
(and thus, ‘grant them access’) you must be able to Edit users.
typically only an Administrator can do that.

updated to version 1.02 — just added code to account for presence of suppress_filters in the $query object passed to pre_get_posts…

in english — anything that’s supposed to be “left well enough alone” (menus, attachments, etc.) now will be.

give it a try and see if it resolves your issue.

in the theme you tried to use, is there an add_action for ‘pre_get_posts’ ? it might be overriding my plugin’s use of that hook.

in the plugin file, you may add an empty function with the same name as the one that call_user_func is attempting to call…

function o3_moc_edit_categories( ) {
}

before ‘function o3_moc_category_input’ is a good place to put it.

thanks for the bug report; on my end i didn’t notice it because call_user_func was “failing silently” rather than the php warning you saw.

when you say “changed the template” you mean changed your blog theme?

i just switched from Twenty Ten to Twenty Eleven and back again and everything’s kosher on my install.