Is your enhancement related to a problem? Please describe.
PII and other sensitive data can be stored throughout a WordPress database. Whilst this does a good job of focusing on Users and Comments, it requires engineers to hook into the scrubbing process and manually scrub the data on each project.
Allowing engineers to set up a wp-scrubber.json file, outlining the data and fields that need to be scrubbed could be a very easy way to ease the barrier of entry for projects.
Designs
My idea for the structure would look something like this:
Post Types
name: Identifies the post type (e.g., post, page, custom post types).
fields: Lists the fields within the post type for scrubbing.
post_meta: Specifies post_meta fields and actions.
Taxonomies
name: Specifies the taxonomy (e.g., category, tag).
terms: Defines terms within the taxonomy for scrubbing.
term_meta: Details term_meta fields and scrubbing actions.
Options
Lists WordPress options (e.g., admin_email, API Keys etc) for scrubbing.
User Data
Covers user data fields (e.g., user_email, display_name) for scrubbing.
Custom Tables
name: Names of custom database tables.
columns: Specifies columns in these tables for scrubbing.
Truncate Tables
Lists tables for complete truncation.
Each section of fields (fields, post_meta, columns etc) above would hold an array of object which have the following properties:
action: Defines the scrubbing action (faker, replace, remove).
Is your enhancement related to a problem? Please describe.
PII and other sensitive data can be stored throughout a WordPress database. Whilst this does a good job of focusing on Users and Comments, it requires engineers to hook into the scrubbing process and manually scrub the data on each project.
Allowing engineers to set up a
wp-scrubber.json
file, outlining the data and fields that need to be scrubbed could be a very easy way to ease the barrier of entry for projects.Designs
My idea for the structure would look something like this:
Post Types
name
: Identifies the post type (e.g., post, page, custom post types).fields
: Lists the fields within the post type for scrubbing.post_meta
: Specifies post_meta fields and actions.Taxonomies
name
: Specifies the taxonomy (e.g., category, tag).terms
: Defines terms within the taxonomy for scrubbing.term_meta
: Details term_meta fields and scrubbing actions.Options
admin_email
, API Keys etc) for scrubbing.User Data
user_email
,display_name
) for scrubbing.Custom Tables
name
: Names of custom database tables.columns
: Specifies columns in these tables for scrubbing.Truncate Tables
Each section of fields (
fields
,post_meta
,columns
etc) above would hold an array of object which have the following properties:action
: Defines the scrubbing action (faker
,replace
,remove
).faker
: This would use https://fakerphp.github.io/ to set mock data.replace
: This would replace the data with a set string.remove
: This would replace the data with an empty string or delete the row, depending on the context.faker_type
: When usingfaker
, specifies the type of fake data (e.g., name, email).value
: Forreplace
action, the value to replace the original data.Put together, this would look something like:
Describe alternatives you've considered
I considered other formats, such as YAML, but they're a lot less human-readable than JSON, which is why we went with that approach.
I think this approach gives us the most amount of structure and flexibility, outside of defining out own scrubbing code for each project.
Code of Conduct