Plugin Directory

Changeset 483641


Ignore:
Timestamp:
01/02/2012 09:25:57 PM (14 years ago)
Author:
asdasDan
Message:

Fixing up readme.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • advanced-post-privacy/trunk/readme.txt

    r483640 r483641  
    1313allows you to make exceptions to any content types that have been marked as private.
    1414
    15 **Possible Future Features**
    16 * Allowing exceptions on a per page/post basis.
    17 * Allowing protected posts/pages to be bypassed.
    18 * Integration with popular Member Plugins
    19 * Integration with Pods CMS.
    20 * Anything else requested.
    21 
     15**Possible Future Features:**   
     16* Allowing exceptions on a per page/post basis.   
     17* Allowing protected posts/pages to be bypassed.   
     18* Integration with popular Member Plugins.   
     19* Integration with Pods CMS.   
     20* Anything else requested.   
     21   
    2222
    2323== Installation ==
     
    3636private. I was able to do it using IP address, and this made the process much easier.
    3737
    38 Other uses could include:
    39    * Allowing certain roles (such as authors) to see private media.
    40    * Allowing certain users to see all private posts based on their IP address.
     38Other uses could include:     
     39   * Allowing certain roles (such as authors) to see private media.   
     40   * Allowing certain users to see all private posts based on their IP address.   
    4141
    4242
     
    6363     
    6464**Adding a type of Exclusion**   
    65       By default, Advanced Post Privacy (APP) has two types of exclusions, IP Address, and Role. It’s built in a mostly modular fashion, and is a configuration based plugin, meaning after adding your functionality, you need to explicitly tell the system about your new functionality, via the config.json file.
    66       If you wanted to add a new type of exclusion, for example IP Address Range, you would have to do the following.
    67       * Create a new directory inside the code folder, naming doesn’t matter much here, it could be called “ip-range”.
    68       * Create a file called exclusion.php, this will be a class which could be called “ipRangeExclusions”, this class must implement the “appExclusions” interface, and should (for posterity) extend the primary “advancedPostPrivacy” class. This will force the class to have 5 static methods, broken down as:
    69       * optionName() - Takes no arguments, and returns the name of the option in which all the exclusions will be stored in the database. This should be prefixed with the “APP_PREFIX” constant for uniqueness. This option will be completely removed on the uninstall (deletion) of the plugin.
    70       * getExclusion() - Takes an optional $identifier argument, without that argument it should contain the code that gets all exclusions of the IP Range type, with it, it will return exclusions for that specific IP Range.
    71       * setExclusion() - Takes an array of data that will set a single exclusion of that type. To comply with the other types, your code should contain a similar snippet on a successful added exclusion:
     65      By default, Advanced Post Privacy (APP) has two types of exclusions, IP Address, and Role. It’s built in a mostly modular fashion, and is a configuration based plugin, meaning after adding your functionality, you need to explicitly tell the system about your new functionality, via the config.json file.   
     66      If you wanted to add a new type of exclusion, for example IP Address Range, you would have to do the following.   
     67      * Create a new directory inside the code folder, naming doesn’t matter much here, it could be called “ip-range”.   
     68      * Create a file called exclusion.php, this will be a class which could be called “ipRangeExclusions”, this class must implement the “appExclusions” interface, and should (for posterity) extend the primary “advancedPostPrivacy” class. This will force the class to have 5 static methods, broken down as:   
     69      * optionName() - Takes no arguments, and returns the name of the option in which all the exclusions will be stored in the database. This should be prefixed with the “APP_PREFIX” constant for uniqueness. This option will be completely removed on the uninstall (deletion) of the plugin.   
     70      * getExclusion() - Takes an optional $identifier argument, without that argument it should contain the code that gets all exclusions of the IP Range type, with it, it will return exclusions for that specific IP Range.   
     71      * setExclusion() - Takes an array of data that will set a single exclusion of that type. To comply with the other types, your code should contain a similar snippet on a successful added exclusion:   
    7272       `do_action(APP_PREFIX .
    7373                             'add_' .
    7474                              self::getExclusionModuleData(__CLASS__, 'singular') .
    75                              '_exclusion', $exclusionData['excluded_ip']);`
    76                  This will create a hook for when an exclusion of your type is created. This method should also ignore any entries that already exist, just for good practice.
    77                  * removeExclusion() - This takes two arguments, the exclusions unique identifier (in this case it would be the IP Range), and the post type slug (“post”, “page”, etc). This code should remove the exclusion, and create an identical hook to the one in setExclusion(), only with the term remove instead of add.
    78                  * getExcludedPostIds() - This is the function that makes your exclusion type work, you do whatever checking you would need to here, in this case it would be checking if the users IP address (constant “VIEWER_IP_ADDRESS”) falls within any of the ranges in the database. It should return an array of private post Ids, that can be obtained by using:
     75                             '_exclusion', $exclusionData['excluded_ip']);`   
     76                 This will create a hook for when an exclusion of your type is created. This method should also ignore any entries that already exist, just for good practice.   
     77                 * removeExclusion() - This takes two arguments, the exclusions unique identifier (in this case it would be the IP Range), and the post type slug (“post”, “page”, etc). This code should remove the exclusion, and create an identical hook to the one in setExclusion(), only with the term remove instead of add.   
     78                 * getExcludedPostIds() - This is the function that makes your exclusion type work, you do whatever checking you would need to here, in this case it would be checking if the users IP address (constant “VIEWER_IP_ADDRESS”) falls within any of the ranges in the database. It should return an array of private post Ids, that can be obtained by using:   
    7979                 self::getPrivatePostIdsFromPostTypes($arrayOfPostTypes)
    80                  Ideally the array of post types would be obtained by calling self::getExclusion() with the IP range passed.
    81                  * Now, ajax files for the interface must be created, create a folder called ajax within the code folder, and create files called action.php, and js.php.
    82                  * With action.php, this will store the functionality of your ajax calls, the class should extend appAjaxAction, and actions should be added to the wp_ajax_action_name method, refer to the Wordpress Ajax API for more information.
    83                  * With js.php, this will store the javascript that triggers your ajax calls, the class should extend appAjaxJs, and all methods should be added to the admin_head hook. Again, following the practices of the Wordpress Ajax API.
    84                  * Now you can create the user interface “widget” (in the non-WP sense) to your exclusion type, this will be a php file in your directory named settings.php. This will be included on the settings page.
    85                  * Finally, all of this is done, but the system still doesn’t know your exclusion module exists, but once you tell it it’s there, it will function seamlessly with the rest of the system (configuration based ftw). We do this by modifying the config.json in the root directory, you may want to back it up since it’s easy to mess up the syntax. You’ll want to add 3 lines of json under the “exclusionModules” array item, this would be an example:
     80                 Ideally the array of post types would be obtained by calling self::getExclusion() with the IP range passed.   
     81                 * Now, ajax files for the interface must be created, create a folder called ajax within the code folder, and create files called action.php, and js.php.   
     82                 * With action.php, this will store the functionality of your ajax calls, the class should extend appAjaxAction, and actions should be added to the wp_ajax_action_name method, refer to the Wordpress Ajax API for more information.   
     83                 * With js.php, this will store the javascript that triggers your ajax calls, the class should extend appAjaxJs, and all methods should be added to the admin_head hook. Again, following the practices of the Wordpress Ajax API.   
     84                 * Now you can create the user interface “widget” (in the non-WP sense) to your exclusion type, this will be a php file in your directory named settings.php. This will be included on the settings page.   
     85                 * Finally, all of this is done, but the system still doesn’t know your exclusion module exists, but once you tell it it’s there, it will function seamlessly with the rest of the system (configuration based ftw). We do this by modifying the config.json in the root directory, you may want to back it up since it’s easy to mess up the syntax. You’ll want to add 3 lines of json under the “exclusionModules” array item, this would be an example:   
    8686                   `"ipAddressExclusions": {
    8787                                "singular":  "ip_address",
    8888                                            "directory": "code/ip-address"
    8989                                                    }`
    90 ipAddressExclusions must match the class name used in your exclusions.php file, the singular name is what will be used in hooks (and probably other places later), the directory is simply where your code lives from the plugin path, in this example it would be “code/ip-range”.
    91 
    92 Refresh your settings page, and you should see your system in effect!
     90ipAddressExclusions must match the class name used in your exclusions.php file, the singular name is what will be used in hooks (and probably other places later), the directory is simply where your code lives from the plugin path, in this example it would be “code/ip-range”.   
     91   
     92Refresh your settings page, and you should see your system in effect!   
    9393
    9494
Note: See TracChangeset for help on using the changeset viewer.