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! |
---|