[wp-trac] [WordPress Trac] #43809: Add personal data from posts to personal data export
WordPress Trac
noreply at wordpress.org
Wed Apr 25 01:21:50 UTC 2018
#43809: Add personal data from posts to personal data export
-------------------------------------------------+-------------------------
Reporter: TZ Media | Owner: tz-media
Type: enhancement | Status: assigned
Priority: normal | Milestone: 4.9.6
Component: General | Version:
Severity: normal | Resolution:
Keywords: gdpr has-patch 2nd-opinion | Focuses:
reporter-feedback needs-unit-tests |
-------------------------------------------------+-------------------------
Changes (by desrosj):
* keywords: gdpr has-patch 2nd-opinion => gdpr has-patch 2nd-opinion
reporter-feedback needs-unit-tests
Comment:
@TZ Media good first pass here. Some questions and feedback. These may
have been discussed already or not apply. I did my best to look for
answers to these questions but couldn't find anything.
- Using `strtolower()` on the email will not return results for users with
any uppercase letters in their email.
- If a user is not found by `get_user_by()`, should an error be returned?
- `get_post_stati()` is called twice. Can this be consolidated?
- Can't posts with the `auto-save` status be considered personal data? If
revision posts are included, maybe `auto-save`s should too?
- The `get_posts()` call has `posts` and `pages` hardcoded. What if there
are custom post types that plugins and themes want to be included in the
export? Should public and private post types be included by default?
Should this be passed to `register_post_type()` like `show_in_rest`, for
example?
- Was there a reason that `get_posts()` was chosen instead of a
`WP_Query`? `get_posts()` will surpress filters by default. Should plugins
be able to filter the `WHERE` and `JOIN` clauses?
- The user data ticket also mentions user meta, but there are no mentions
of post meta here. Should that be included here, or addressed in a
separate ticket?
- `$post_data_to_export[] = array( 'name' => $name, 'value' => $value );`:
these should each be on their own lines.
- `$done` is evaluated based on the current number of posts retrieved with
no context of where the process is. If a `WP_Query` is used instead, it
would know the total number of results, and one iteration of the function
could be prevented when there are the same number of posts as the
`$number`.
- Was there a reason that `500` was chosen for number? That could be high,
especially if post meta is added and posts have lots of meta data. Should
this number be filterable? On servers with more resources, a site owner
may want to process more at once.
- Functions need inline documentation.
- Needs unit tests.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/43809#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list