[wp-trac] [WordPress Trac] #43443: Add a method for confirmation of requests for deleting or anonymizing of personal data

[WordPress Trac]

#43443: Add a method for confirmation of requests for deleting or anonymizing of
personal data
--------------------------------------------+-------------------------
 Reporter:  azaozz                          |       Owner:  mikejolley
     Type:  enhancement                     |      Status:  assigned
 Priority:  normal                          |   Milestone:  4.9.6
Component:  General                         |     Version:
 Severity:  normal                          |  Resolution:
 Keywords:  gdpr needs-testing needs-patch  |     Focuses:
--------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:31 mikejolley]:
 > CPT is much heavier just to store a hash/key, and I disagree you need
 logs for that type of activity where it's a) automated and b) something
 that happens more or less in the background. Look at the existing system;
 it's just meta.

 Hm, if we plan for this to be reusable in the future, imho we should also
 plan for the log to be reusable.

 Yeah, at first CPT may look heavier but the options table is just the
 wrong place to store this type of data. All options get loaded on each
 request, including on the front-end, which makes it a lot heavier than a
 CPT which is going to me loaded only when an admin visits the privacy
 screen.

 Another big disadvantage is that the hash, time, email are stored in a CSV
 which makes it impossible to look them up separately. If I remember right
 that was one of the main reasons a new DB table was so attractive. Given
 that such table will stay mostly empty on the great majority of sites, a
 CPT is the next best thing.

 > > Perhaps we can abstract the CPT a bit, make it more generic, then set
 different `post_name` depending on request type?
 >
 > We implemented the 2 CPT for the requests to take advantage of
 wp_count_posts. We'll need lots of custom queries otherwise on our screens
 to do the status filtering.

 Hm, don't think so. `wp_count_posts()` uses a simple db query to count. We
 actually can do better as it has some specific stuff for posts and pages
 that is not needed. Making another similar function which is adapted to
 our needs would be the right thing in any case.

 > > The main reason we started using CPTs was to not store the
 verification key in the options table :)
 >
 > No, the main reason for CPTs was to get a list table log without lots of
 heavy custom queries on meta data, since no one liked the idea of a custom
 table.

 Hmm, think there has been some miscommunication here :) As a custom table
 would have been empty or almost empty on the great majority of sites, it
 didn't make sense to add one. Even if we add one it will also need a whole
 new set of low-level functions to become useful. For example we would need
 to add or duplicate most stuff that drive the list tables UI.

 CPTs are the next best thing to a custom table. They can store a lot of
 information quite efficiently. Not using them to store the simple data
 needed for implementing email verification doesn't seem right. In
 addition, having two almost identical custom post types doesn't seem best.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43443#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform