Dutch van Andel

You can use Page Security’s column functions as callbacks on your own post types. The WordPress hooks you’ll want to use are ‘manage_{$post_type}_posts_columns’ and ‘manage_{$post_type}_custom_column’…

Like so…

//add the column to your list tables
add_filter('manage_yourtype_posts_columns', array('CTXPS_Components','add_list_protection_column'));

//add the protection data to each item
add_filter('manage_yourtype_custom_column',array('CTXPS_Components','render_list_protection_column'),10,2);

I don’t see any problems on those lines.

Example (line 206)…
return sprintf( '<tr><td colspan="4">%s</td></tr>',sprintf(__('You are not currently a member of any groups.','contexture-page-security'),admin_url('users.php?page=ps_groups')));

How many white doves did you need to sacrifice before it detected that memcached was active on your server? And yes, I made sure the daemon was running and even installed a memcached gui to monitor it.

Also, mind you, I am not talking about memcache (obsolete/deprecated, but which seems to be readily supported by W3 Total Cache) but Memcached.

Page Security obeys usual WordPress role principles, in that anyone in the Administrator role has unrestricted access to everything on the site, including site settings. There are no plans to change that since Page Security is primarily focused on front-end users and restricting Administrators would fundamentally go against the way WordPress is designed to function.

Instead, you should use Author (or Editor, if elevated privileges are needed) roles, where appropriate, for users who should have limited access to content. You may also want to look into a plugin that offers custom Roles if you need more back-end control over what your users can see and access.

Ethan,

Page Security is still being maintained when bug reports are submitted, but we rarely respond to support requests directly unless a bug is involved, and we do not regularly read these forums. Your post involved a problem with BuddyPress, and Page Security does not appear to be directly involved.

Hi Ethan,

This error is coming from BuddyPress, not Page Security. Notice the file path you posted…

/wp-content/plugins/buddypress/bp-core/bp-core-filters.php on line 641

Although Page Security is based on block-only principles to keep things simple, I’ve added a new feature in 1.5.15 that allows you to specify pages that should ALWAYS be public.

Update the plugin, then go to Settings > Page Security and look under the Force Public Pages option. There, you can enter a comma-separated list of page ids (numeric page ids) that you want to be exempted from security checks. The pages you list in this field will always be available to the public and any other security you set for those pages will be ignored.

This is fixed in this morning’s update.

Can you clarify? Do you mean the user profile page?

If you are talking about a user’s profile page, there shouldn’t be any posts there at all… unless you are using a plugin that adds them.

Page Security can only filter posts that use actual WordPress APIs and techniques to query content. There are a LOT of plugins that make custom database queries against best practices, and Page Security will not be able to filter those cases.

Honestly, I’m not sure since I’m not familiar with the inner workings of Jetpack subscriptions. PSC tries to operate at the lowest level possible by intercepting the $wpdb object, but if a plugin is bypassing that (making custom queries, for example) then there’s nothing that can be done.

Restrictions do not apply to people with editor or higher privileges as they, by default, have edit rights to all site content.

Action links are handled manually, however you see fit. You can create a new method, say, process_link_action() to handle your custom action links… and then you just need to call that from within prepare_items() so that it can be handled just like like process_bulk_action().

Yes. A php file that ends in php (as opposed to, say, HTML) should NOT have a closing php tag.

To my knowledge, there hasn’t been any changes to WP_List_Table that would break bulk actions you’ve defined in your own list table… although bulk action hooks have been a contentious issue for years. This really depends on what and how you are doing things.

The plugin includes directions for this. The hard-coded “movie” data is for example/educational purposes.

The prepare_items() method is where you will query your own data and manipulate it. In that method, you will see a comment block that says “In a real-world situation, this is where you would place your query.” – that is where you would make your custom database query.

The easiest way to approach the plugin is to simple read it top to bottom, and make customizations along the way according to the comments and your needs.