內容簡介
Advanced Post Privacy 利用了目前私人張貼功能尚未完善的狀況。它允許您對標記為私人的任何內容類型進行例外處理。
可能的未來功能：
* 允許針對每一個頁面/文章進行例外處理
* 允許繞過受保護的文章/頁面
* 與熱門會員外掛整合
* 與 Pods CMS 整合
* 其他任何要求
用法
這個外掛的用法因情況而異，我創建它的原因是因為需要在一個項目中做一些非常簡單的事情，但是它並沒有被建立起來，這使得搜索引擎可以爬取私人張貼，同時仍然保持為私人。我能夠使用 IP 地址來實現這一點，這讓過程變得更加輕鬆。
其他用途可能包括：
* 允許某些角色（例如作者）查看私人媒體。
* 根據使用者的 IP 地址，允許某些使用者查看所有私人發佈。
擴展
注意：此時添加到外掛的所有其他文件夾將在升級時被刪除。在我找到解決方法之前，如果您開發了任何想保留的模塊，它們都必須在升級之前移出外掛文件夾，然後再移到回去。
Advanced Post Privacy （APP）是以一種非常模塊化的方式構建的，通過鉤子/過濾器進行擴展，或者通過添加自己的排除模塊進行擴展。每種排除類型都在自己的代碼中，因此與角色排除相關的所有代碼都在 /code/role 目錄中。
可用的動作：
* adv_pp_add_ip_address_exclusion（1個參數，被添加的 IP 地址）
* adv_pp_remove_ip_address_exclusion（2個參數，被刪除的 IP 地址和發佈類型標識）
* adv_pp_uninstall（無參數，在卸載時運行）
可用的篩選器：
* adv_pp_applicable_post_types（APP 可訪問的縮略名 => 標籤文章類型數組）
* adv_pp_post_type_labels（文章類型的標籤數組）
* adv_pp_bypassed_post_ids（當前使用者可以繞過的發佈 ID 數組）
添加一種排除類型
默認情況下，Advanced Post Privacy （APP）具有兩種排除類型，IP 地址和角色。它以一種大多數模塊化的方式構建，並且是一個基於配置的插件，這意味著在添加自己的功能之後，您需要明確告訴系統您的新功能，並在 config.json 文件中進行配置。
例如，如果您想添加一種新的排除類型，例如 IP 地址範圍，您需要完成以下工作：
* 在代碼文件夾內創建一個新的目錄，名稱不太重要，可以叫做“ip-range”。
* 創建一個名為 exclusion.php 的文件，這將是一個類，可以稱為“ipRangeExclusions”，這個類必須實現“appExclusions”接口，並且應（出于記錄）擴展主要的“advancedPostPrivacy”類。這將強制該類有 5 個靜態方法，分解為：
* optionName() – 不帶參數，返回所有排除將存儲在數據庫中的選項的名稱。這應該以“APP_PREFIX”常量為前綴，使其獨一無二。此選項將在卸載（刪除）插件時完全刪除
* getExclusion() – 接受一個可選的$identifier參數，如果沒有該參數，則它應該包含獲取 IP 範圍排除的所有排除的代碼，否則它將返回該具體 IP 範圍的排除。
* setExclusion() – 接受將設置單個排除項的數據數組。為了符合其他類型，在您的代碼中，應包含一個 s
外掛標籤
開發者團隊
原文外掛簡介
Advanced Post Privacy takes advantage of the current underdeveloped functionality of private posts. It
allows you to make exceptions to any content types that have been marked as private.
Possible Future Features:
* Allowing exceptions on a per page/post basis.
* Allowing protected posts/pages to be bypassed.
* Integration with popular Member Plugins.
* Integration with Pods CMS.
* Anything else requested.
Usage
The usage of this plugin varies, I created it after having to do something very simple for a
project that wasn’t built in, allowing a search engine to crawl private posts while remaining
private. I was able to do it using IP address, and this made the process much easier.
Other uses could include:
* Allowing certain roles (such as authors) to see private media.
* Allowing certain users to see all private posts based on their IP address.
Extending
Note: At this point all additional folders that are added to the plugin will be deleted upon upgrade.
Until I figure out how I want to work around that, if you develop any modules you want to keep, they will
have to be moved out of the plugin folder before upgrade and then moved back in.
Advanced Post Privacy (APP) is built in a very modular way, that allows for extending upon
via hooks/filters, or in the way of adding your own exclusion module. Each type of exclusion
is within it’s own code, so all code related to the role exclusion is found within the /code/role
directory.
Available Actions:
* adv_pp_add_ip_address_exclusion (1 arg, the IP address being added)
* adv_pp_remove_ip_address_exclusion (2 args, the IP address, and the post type slug being removed)
* adv_pp_uninstall (No arguments, runs on uninstall)
Available Filters:
* adv_pp_applicable_post_types (Array of slug => label post types that APP can access.)
* adv_pp_post_type_labels (Array of labels for Post Types)
* adv_pp_bypassed_post_ids (Array of Post Ids the current user can bypass)
Adding a type of Exclusion
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.
If you wanted to add a new type of exclusion, for example IP Address Range, you would have to do the following –
* Create a new directory inside the code folder, naming doesn’t matter much here, it could be called “ip-range”.
* 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:
* 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.
* 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.
* 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:
do_action(APP_PREFIX .
‘add_’ .
self::getExclusionModuleData(CLASS, ‘singular’) .
‘_exclusion’, $exclusionData[‘excluded_ip’]);
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.
* 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.
* 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:
self::getPrivatePostIdsFromPostTypes($arrayOfPostTypes)
Ideally the array of post types would be obtained by calling self::getExclusion() with the IP range passed.
* 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.
* 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.
* 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.
* 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.
* 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:
“ipAddressExclusions”: {
“singular”: “ip_address”,
“directory”: “code/ip-address”
}
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”.
Refresh your settings page, and you should see your system in effect!
Data available to your Exclusion Module
If you followed the conventions, all of your classes will ultimately extend the core advancedPostPrivacy class,
meaning you have access to all the methods within the class, however most of them may be made private in the
future as they are really for the core. The protected static property of $_json_config is stored here,
and has the complete array of the loaded json configuration file.
Assets Available
jQuery chosen js, and css, is enqueued via APP, and can be called on any pages as it is normally called.
Constants
APP_PREFIX (adv_pp_)
APP_PATH
APP_CODE_PATH
APP_DESIGN_PATH
APP_PLUGIN_URL
APP_DESIGN_URL
APP_CONFIG_FILE (path to the config.json file)
VIEWER_IP_ADDRESS (users REMOTE_ADDR from $_SERVER)
