| 1 | # How to Connect Your Plugin to Core's New Personal Data Eraser |
|---|
| 2 | |
|---|
| 3 | ## Background |
|---|
| 4 | |
|---|
| 5 | In WordPress 4.9.x, new tools were added to make compliance easier with laws |
|---|
| 6 | like the European Union's General Data Protection Regulation, or GDPR for |
|---|
| 7 | short. Among the tools added is a Personal Data Removal tool which supports |
|---|
| 8 | erasing/anonymizing personal data for a given user. It does NOT delete |
|---|
| 9 | registered user accounts - that is still a separate step the admin can |
|---|
| 10 | choose whether or not to do. |
|---|
| 11 | |
|---|
| 12 | In addition to the personal data stored in things like WordPress comments, |
|---|
| 13 | plugins can also hook into the eraser feature to erase the personal |
|---|
| 14 | data they collect, whether it be in something like postmeta or even an |
|---|
| 15 | entirely new Custom Post Type (CPT). |
|---|
| 16 | |
|---|
| 17 | ## How It Works |
|---|
| 18 | |
|---|
| 19 | Like the exporters, the "key" for all the erasers is the user's email address - |
|---|
| 20 | this was chosen because it supports erasing personal data for both full-fledged |
|---|
| 21 | registered users and also unregistered users (e.g. like a logged out commenter). |
|---|
| 22 | |
|---|
| 23 | However, since performing a personal data erase is a destructive process, we |
|---|
| 24 | don't want to just do it without confirming the request, so the admin-facing |
|---|
| 25 | UX starts all requests by having the admin enter the username or email address |
|---|
| 26 | making the request and then sends then a link to click to confirm their |
|---|
| 27 | request. |
|---|
| 28 | |
|---|
| 29 | A list of requests and whether they have been confirmed is available to |
|---|
| 30 | the administrator in the same user interface. Once a request has been |
|---|
| 31 | confirmed, the admin can kick off personal data erasure for the user. |
|---|
| 32 | |
|---|
| 33 | ## Design Internals |
|---|
| 34 | |
|---|
| 35 | The way the personal data export is erased is similar to how the personal data |
|---|
| 36 | exporters - and relies on hooking "eraser" callbacks to do the dirty work |
|---|
| 37 | of erasing the data. |
|---|
| 38 | |
|---|
| 39 | When the admin clicks on the remove personal data link, an AJAX loop begins |
|---|
| 40 | that iterates over all the erasers registered in the system, one at a time. |
|---|
| 41 | In addition to erasers built into core, plugins can register their own |
|---|
| 42 | eraser callbacks. |
|---|
| 43 | |
|---|
| 44 | The eraser callback interface is designed to be as simple as possible. |
|---|
| 45 | An eraser callback receives the email address we are working with, |
|---|
| 46 | and a page parameter as well. The page parameter (which starts at 1) is |
|---|
| 47 | used to avoid plugins potentially causing timeouts by attempting to erase |
|---|
| 48 | all the personal data they've collected at once. |
|---|
| 49 | |
|---|
| 50 | The eraser callback replies whether items containing personal data were |
|---|
| 51 | erased, whether any items containing personal data were retained, an |
|---|
| 52 | array of messages to present to the admin (explaining why items that were |
|---|
| 53 | retained were retained) and whether it is done or not. If an eraser |
|---|
| 54 | callback reports that it is not done, it will be called again (in a |
|---|
| 55 | separate request) with the page parameter incremented by 1. |
|---|
| 56 | |
|---|
| 57 | When all the exporters have been called to completion, the UX is updated to |
|---|
| 58 | show whether or not all personal data found was erased, and any messages |
|---|
| 59 | explaining why personal data was retained. |
|---|
| 60 | |
|---|
| 61 | A good example is a plugin that takes e-commerce orders. The plugin's settings |
|---|
| 62 | could say that personal data should be retained for orders < XXX days old. The |
|---|
| 63 | plugin's order eraser could look at that setting against each order |
|---|
| 64 | and decide whether or not to remove it. If it decides not to remove it, |
|---|
| 65 | it can emit a message in the AJAX to say as much to the admin (i.e. Order |
|---|
| 66 | 1234 was not erased because it is less than XXX days old.) |
|---|
| 67 | |
|---|
| 68 | The intention for now is that plugins may choose to expose erasure controls |
|---|
| 69 | in their own settings user interfaces where it makes the most contextual sense. |
|---|
| 70 | |
|---|
| 71 | ## What to Do |
|---|
| 72 | |
|---|
| 73 | A plugin can register one or more erasers, but most plugins will only |
|---|
| 74 | need one. Let's work on a hypothetical plugin which adds commenter location |
|---|
| 75 | data to comments. |
|---|
| 76 | |
|---|
| 77 | Let's assume the plugin has used `add_comment_meta` to add location |
|---|
| 78 | data using `meta_key`s of `latitude` and `longitude` |
|---|
| 79 | |
|---|
| 80 | The first thing the plugin needs to do is to create an eraser function |
|---|
| 81 | that accepts an email address and a page, e.g.: |
|---|
| 82 | |
|---|
| 83 | ``` |
|---|
| 84 | function my_plugin_eraser( $email_address, $page = 1 ) { |
|---|
| 85 | $number = 500; // Limit us to avoid timing out |
|---|
| 86 | $page = (int) $page; |
|---|
| 87 | |
|---|
| 88 | $export_items = array(); |
|---|
| 89 | |
|---|
| 90 | $comments = get_comments( |
|---|
| 91 | array( |
|---|
| 92 | 'author_email' => $email_address, |
|---|
| 93 | 'number' => $number, |
|---|
| 94 | 'paged' => $page, |
|---|
| 95 | 'order_by' => 'comment_ID', |
|---|
| 96 | 'order' => 'ASC', |
|---|
| 97 | ) |
|---|
| 98 | ); |
|---|
| 99 | |
|---|
| 100 | $items_removed = false; |
|---|
| 101 | |
|---|
| 102 | foreach ( (array) $comments as $comment ) { |
|---|
| 103 | $latitude = get_comment_meta( $comment->comment_ID, 'latitude', true ); |
|---|
| 104 | $longitude = get_comment_meta( $comment->comment_ID, 'longitude', true ); |
|---|
| 105 | |
|---|
| 106 | if ( ! empty( $latitude ) ) { |
|---|
| 107 | delete_comment_meta( $comment->comment_ID, 'latitude' ); |
|---|
| 108 | $items_removed = true; |
|---|
| 109 | } |
|---|
| 110 | |
|---|
| 111 | if ( ! empty( $longitude ) ) { |
|---|
| 112 | delete_comment_meta( $comment->comment_ID, 'longitude' ); |
|---|
| 113 | $items_removed = true; |
|---|
| 114 | } |
|---|
| 115 | } |
|---|
| 116 | |
|---|
| 117 | // Tell core if we have more comments to work on still |
|---|
| 118 | $done = count( $comments ) < $number; |
|---|
| 119 | |
|---|
| 120 | return array( |
|---|
| 121 | 'items_removed' => $items_removed, |
|---|
| 122 | 'items_retained' => false, // always false in this example |
|---|
| 123 | 'messages' => array(), // no messages in this example |
|---|
| 124 | 'done' => $done, |
|---|
| 125 | ); |
|---|
| 126 | } |
|---|
| 127 | ``` |
|---|
| 128 | |
|---|
| 129 | The next thing the plugin needs to do is to register the callback by |
|---|
| 130 | filtering the eraser array using the `wp_privacy_personal_data_erasers` |
|---|
| 131 | filter. |
|---|
| 132 | |
|---|
| 133 | When registering you provide a friendly name for the eraser (to aid in |
|---|
| 134 | debugging - this friendly name is not shown to anyone at this time) |
|---|
| 135 | and the callback, e.g. |
|---|
| 136 | |
|---|
| 137 | ``` |
|---|
| 138 | function register_my_plugin_eraser( $erasers ) { |
|---|
| 139 | $erasers[] = array( |
|---|
| 140 | 'eraser_friendly_name' => __( 'Comment Location Plugin' ), |
|---|
| 141 | 'callback' => 'my_plugin_eraser', |
|---|
| 142 | ); |
|---|
| 143 | return $erasers; |
|---|
| 144 | } |
|---|
| 145 | |
|---|
| 146 | add_filter( |
|---|
| 147 | 'wp_privacy_personal_data_erasers', |
|---|
| 148 | 'register_my_plugin_eraser', |
|---|
| 149 | 10 |
|---|
| 150 | ); |
|---|
| 151 | ``` |
|---|
| 152 | |
|---|
| 153 | And that's all there is to it! Your plugin will now clean up its personal |
|---|
| 154 | data! |
|---|