Privacy and Personal Data

The core tools work by email address: when an administrator processes a request, WordPress calls every registered exporter or eraser with that address. Data that no callback covers is neither exported nor erased, so the work starts with an inventory. Personal data includes email and IP addresses, names, user IDs combined with behaviour (what someone saved, viewed or bought), free text and identifiers in cookies. Core already covers user profiles, comments and uploaded media. For lumen-catalog:

Both kinds of callback are registered through a filter that returns an array keyed by a unique slug. The admin screen calls each callback over Ajax, one page per request, until it reports done, which keeps a large export within PHP’s time limit.

Source: Plugin Handbook: Adding the Personal Data Exporter to Your Plugin

The Ajax handlers validate every response and abort the request with errors such as "Expected done (boolean) in response array from exporter: Lumen Press wishlist." Callbacks are addressed by their position in the filtered list, so the list must be identical on every request; an exporter added only under some condition triggers "An exporter has improperly used the registration filter."

The code lives in Lumen\Catalog\Privacy, loaded by the plugin’s Composer autoloader (see Plugin Fundamentals). The lumen/wishlist block’s REST endpoint stores the wishlist as a list of array( 'book' => 123, 'added' => 1793059200 ) entries, each book at most once. Plugin::boot() calls Privacy::register(); Installer::activate() and Installer::deactivate() call Privacy::schedule() and Privacy::unschedule(); LUMEN_CATALOG_FILE is the main plugin file.

The test site is the standard stack from Local Development Environments with lumen-catalog active, three lp_book posts (IDs 4 to 6) and a subscriber rosa (rosa@example.com) whose wishlist holds all three. WP-CLI 2.12.0 has no privacy command, so the export uses privacy-export.php from SEO, Analytics and Privacy, which creates a confirmed request and drives every exporter through the admin screen’s filter:

Source: WP-CLI Commands: wp eval-file

export.json holds one object keyed "Personal Data Export for" plus the address, with the groups about, user, comments and lumen-wishlist; index.html shows them with a table of contents. The ZIP file has a random name in wp-content/uploads/wp-personal-data-exports/. The hourly wp_privacy_delete_old_export_files event deletes export files after three days (filter wp_privacy_export_expiration, default 3 * DAY_IN_SECONDS), and since 7.1 the daily wp_privacy_personal_data_cleanup_requests event marks requests left unconfirmed for a day as failed; before 7.1 that happened only when an administrator opened one of the two screens.

Its erasure counterpart, privacy-erase.php, is the same script with a remove_personal_data request, the callbacks from wp_privacy_personal_data_erasers and the wp_privacy_personal_data_erasure_page filter (arguments $response, $index, $email, $page, $request_id), which completes the request after the last eraser. Each line prints the friendly name and the two flags:

Source: WordPress.org Documentation: Tools Erase Personal Data Screen

After the first run wp user meta get rosa lp_wishlist prints nothing; the second run shows that erasers must be idempotent. The account itself remains; deleting it is a separate step under Users. On completion the erasure filter fires wp_privacy_personal_data_erased, which emails the person; the test container had no mail server, so that email failed with a sendmail error on standard error while the request still completed. Both scripts call admin internals (_wp_privacy_completed_request(), the erasure filter’s contract), so they should be re-run after each major update.

The request screens themselves had a flaw until WordPress 7.1.4: a data removal request could be created in a way that led to stored XSS on the administrator’s Erase Personal Data screen. The 7.1.4 security release (2026-10-28) fixes it, so a site that handles privacy requests must run that release or a later one.

Source: WordPress News: WordPress 7.1.4

Settings > Privacy > Policy Guide collects one section per plugin, added with wp_add_privacy_policy_content(). The text answers the default policy’s questions that apply: what is collected and why, how long it is kept, who receives it. Elements with the class privacy-policy-tutorial explain things to the site owner and are left out when the section is copied.

Source: Plugin Handbook: Suggesting text for the site privacy policy

The function only works in the admin, on or after admin_init; anywhere else it adds nothing and reports _doing_it_wrong() (visible with WP_DEBUG). A plain wp eval therefore finds no Lumen section until it sets an admin screen:

Source: Code Reference: wp_add_privacy_policy_content()

The Policy Guide also flags sections of deactivated plugins. The suggested text is a starting point, not legal wording.

The cheapest data to protect is data never stored. The wishlist keeps a book ID and a date, not the title, price or IP address; titles are looked up at export time. Guests' "recently viewed" list stays in their browser. The wishlist REST endpoint and the import command log failures with book IDs and HTTP status codes, never with email addresses, request bodies or cookies, and WP_DEBUG_LOG is on only in development (see Debugging, Site Health and Troubleshooting). When a value is needed for abuse prevention or statistics but the person is not, core’s anonymisation helpers reduce it:

Source: Code Reference: wp_privacy_anonymize_data()

The date type returns 0000-00-00 00:00:00, and the wp_privacy_anonymize_data filter changes any result. A truncated IP address still narrows a visitor down to a network; counting unique visitors per day only needs a salted hash whose salt rotates daily. Log files are storage too, with a retention period and a place in the inventory.

A retention period stated in the policy needs code that enforces it. The period comes from the settings option lp_catalog_settings (key wishlist_retention_days) and a daily event prunes older entries:

Source: Plugin Handbook: Scheduling WP Cron Events

wp cron event list shows lp_catalog_privacy_cleanup next to core’s wp_privacy_delete_old_export_files (hourly) and wp_privacy_personal_data_cleanup_requests (daily). With entries from 2024-08-19, 2026-09-28 and 2026-10-27 in Rosa’s wishlist, running the event removes the first:

Source: WP-CLI Commands: wp cron event run

WP-Cron runs only when the site receives traffic unless a system scheduler triggers it (see WP-Cron and Scheduled Tasks). With many readers, the job should handle a bounded batch per run, for example 500 users ordered by ID with the last ID kept in an option. On uninstall, uninstall.php removes the data of all users with delete_metadata( 'user', 0, 'lp_wishlist', '', true ).

Core sets few cookies (authentication and test cookies for logged-in users, comment author cookies only after the visitor ticks the opt-in box) and never asks for consent; a banner comes from a plugin or the site’s own code. A plugin that sets a cookie should make it conditional, describe it, and remove it when consent is withdrawn:

Source: WordPress.org Plugins: WP Consent API

The cookie is set on template_redirect, before any output, with the array form of setcookie() (PHP 7.3+) so that SameSite can be given. describe_cookie() runs on init because translating strings earlier triggers the just-in-time translation notice added in 6.7. wp_has_consent(), wp_add_cookie_info() and the wp_consent_api_registered_{$plugin} filter belong to the WP Consent API, a community plugin listed on WordPress.org, not part of core; the code checks function_exists() and treats a missing API as no consent. A banner plugin that supports the API sets the consent type for the visitor’s region and stores each choice in a wp_consent_<category> cookie. The trap: with the API active and no banner setting a consent type, wp_has_consent() returns true for every category. Requests for https://lumenpress.test/books/salt-and-ember/ (book ID 5) produced these Set-Cookie headers:

Whether a "recently viewed" list needs consent depends on the law that applies to the site’s readers; the code defaults to strict and lets the site owner decide through the lumen_catalog_recent_books_cookie_allowed filter. Embeds and tracking scripts must wait for consent in the browser as well. Plugins in the WordPress.org directory must not track users without consent (guideline 7; see Publishing to the Plugin Directory).

Personal data requests are per site (each site has its own user_request posts; only super admins hold the privacy capabilities), but user meta is shared by the network, so an erasure on one site removes a meta-based wishlist everywhere. Per-site user data belongs in update_user_option(), which prefixes the key with the site’s table prefix (see Multisite Networks).

The older books treat privacy from the site owner’s side (a policy page, a cookie banner plugin). None shows how a plugin registers its data with the export and erasure tools, suggests policy text or enforces a retention period, and one still describes IP anonymisation as an analytics setting to switch on, which does not apply to Google Analytics 4. Other corrections are listed in Where Older Books and Tutorials Are Outdated. Personal data in shop orders (WooCommerce has its own exporters, erasers and order retention settings) is covered in Store Setup and Launch.