Content restriction plugin 05

3-minute read

The base framework for the restriction plugin is in place.

Base is done

I’ve added more unit and functional tests to test the basic functions of the post restriction framework and am satisfied with its current incarnation.
The code to add a basic access restriction to posts discriminating on whether users are logged in or not I’ve shown in an earlier post should be retouched a little to make it work:


/**
     * Plugin Name: Logged Users content restriction
     * Plugin URI: http://theAverageDev.com
     * Description: Restriction based on a user being logged-in or not.
     * Version: 1.1
     * Author: theAverageDev
     * Author URI: http://theAverageDev.com
     * License: GPL 2.0
     */
    
    // Register the restriction taxonomy

    add_action('init', 'lr_register_logged_in_taxonomy');
    function lr_register_logged_in_taxonomy(){
        register_taxonomy('logged_in', array('post', 'page'));
    }
    
    // On activation add the taxonomy terms

    register_activation_hook(__FILE__, 'lr_activate')
    function lr_activate(){
        lr_register_logged_in_taxonomy();
        wp_insert_term('yes', 'logged_in');
        wp_insert_term('no', 'logged_in');
    }
    
    // During loading register with the restriction framework

    add_action('plugins_loaded', 'lr_load');
    function ('lr_load') {
        // use the `logged_in` taxonomy to restrict posts
        trc_Cor_Plugin::instance()->taxonomies->add('logged_in');

        // set the post types to be restricted
        trc_Core_Plugin::instance()->post_types->add_restricted_post_type( 'post' );

        // when asked for the user slugs use this class
        trc_Core_Plugin::instance()->user->add_user_slug_provider('logged_in', new lr_LoggedInUser());
    }
    
    // Define a class that will take care of providing the slugs for the user

    class lr_LoggedInUser implements trc_Public_UserSlugProviderInterface {
        public function get_taxonomy_name(){
            return 'logged_in';
        }

        public function get_user_slugs(){
            return is_user_logged_in() ? array('yes', 'no') : array('no');
        }
    }

What’s different is the added possibility to specify the post types to be restricted in place of assuming any post type the restricting taxonomy applies to has to be restricted: this covers the case where I might want to use the category taxonomy to restrict the notice post type but not to restrict the post and page post types.

Filters versus classes

As an object-oriented programming practitioner I like the current interface the plugin exposes to add and register the parameters needed for a taxonomy-based restriction to be put into place but can understand that might not be everyone’s preference.
I think this code as readable and maintainable:


add_action('plugins_loaded', 'lr_load');
    function ('lr_load') {
        // use the `logged_in` taxonomy to restrict posts
        trc_Plugin::instance()->taxonomies->add('logged_in');

        // set the post types to be restricted
        trc_Core_Plugin::instance()->post_types->add_restricted_post_type( 'post' );

        // when asked for the user slugs use this class
        trc_Plugin::instance()->user->add_user_slug_provider('logged_in', new lr_LoggedInUser());
    }

but want to keep the possibility open to do the same thing with a filter approach like


/**
     * Plugin Name: Logged Users content restriction
     * Plugin URI: http://theAverageDev.com
     * Description: Restriction based on a user being logged-in or not.
     * Version: 1.2
     * Author: theAverageDev
     * Author URI: http://theAverageDev.com
     * License: GPL 2.0
     */
    
    // Register the restriction taxonomy

    add_action('init', 'lr_register_logged_in_taxonomy');
    function lr_register_logged_in_taxonomy(){
        register_taxonomy('logged_in', array('post', 'page'));
    }
    
    // On activation add the taxonomy terms

    register_activation_hook(__FILE__, 'lr_activate')
    function lr_activate(){
        lr_register_logged_in_taxonomy();
        wp_insert_term('yes', 'logged_in');
        wp_insert_term('no', 'logged_in');
    }
    
    // During loading register with the restriction framework
   
    function lr_restricting_taxonomies(array $taxonomies){
        $taxonomies[] = 'logged_in';

        return $taxonomies;
    }

    function lr_restricted_post_types(array $post_types){
        // override defaults
        $post_types = array('notice');

        return $post_types;
    }

    function lr_user_slugs_for($can_access, WP_Post $post){
        if(post->post_type != 'notice'){
            return $can_access;
        }

        return is_user_logged_in() ? array('yes', 'no') : array('no');
    }

    add_action('plugins_loaded', 'lr_load');
    function ('lr_load') {

        // use the `logged_in` taxonomy to restrict posts
        add_filter('trc_restricting_taxonomies', 'lr_restricting_taxonomies');

        // set the post types to be restricted
        add_filter('trc_restricted_post_types', 'lr_restricted_post_types');
 
        // when asked for the user slugs return values
        add_filter('trc_user_slugs_for', 'lr_user_slugs_for', 10, 2);
    }

Just another way to do it.

Next

I will test out more the possibilities offered by the framework using functional tests and will then move into development of some core restriction plugins (logged in or not, user role and so on…) to try my hand at what that could do.