WordPress: the biography remains after erasing personal data

Why “Completed” is not enough for the biography

A personal-data erasure request is marked completed in WordPress. Yet reopening the profile still reveals the Biographical Info text. This is the symptom described on the WordPress.org forum. On a site displaying biographies, the text may also remain visible in a post's author box or an author archive. Check these observations separately: a biography still stored may be absent from the public site, and a biography removed from the profile may remain visible elsewhere.

Core distinguishes export from erasure. The profile exporter can read the account description. In the core examined, the eraser registered by default handles personal data in comments; no native profile eraser empties this field. The native biography is account metadata named description. A comment's presence or absence therefore does not trigger its erasure. A plugin can register its own processing: the observed result with a given configuration also depends on those processes.

Treat the request status for what it indicates: the erasure workflow has reached its final state. To know what disappeared, check the targeted fields and screens. If the request concerns only the biography, you can handle that field independently of the account, display name and post attribution. If it also covers names, comments or plugin data, open a separate check for each source; an empty biography tells you nothing about those other data.

1. Identify the account through the usual handling channel and record its internal ID. Two authors can share a display name; a public page or pseudonym is insufficient to confirm the target.
2. Classify the observation: “field populated in profile”, “text visible to a visitor”, or both. Record affected URLs in a restricted-access tracking record.
3. Identify a post that must remain attributed to the account. It will serve as a control after the intervention. Record the expected result: the biography disappears, the post remains readable and attributed to the same account.

Reproduce the workflow with a dummy account

Use an isolated WordPress copy. If you want to understand the theme or a plugin's role, retain the affected site's configuration on that copy. Capture staging emails in a test inbox before creating the request. If the copy's mail still goes externally or plugins notify real accounts, stop here and isolate them. Diagnosis needs neither the person's text nor an export of their data.

On the copy, create a test author with a recognizable marker, such as BIO-RECETTE-741. Publish a test post attributed to that account only in staging. Check whether the theme exposes the marker on the post or author archive. A theme without a biography block may produce a negative public result despite a populated field. This initial result serves as a control: it distinguishes a page that never displayed the field from a page actually corrected.

A test comment is optional. If you add one to compare mechanisms, associate it with the dummy address used for the request. Changed comment data alongside an intact biography confirms two separate processing paths on this copy. Leave other profile values unchanged and use the same author ID throughout. Avoid forced erasure for this scenario: the normal path helps establish when to reread the field.

1. Under Users > All Users, edit the dummy author. Save the marker in Biographical Info, then reopen the record and check that it was retained.
2. Under Tools > Erase Personal Data, create a request for the dummy address. Confirm it through the captured message, then run erasure for the confirmed request from the dashboard. Labels may vary by translation.
3. Wait for the final state and record any messages about retained items. If the process fails or remains pending, record that state separately: you have not yet tested behavior after completed erasure.
4. Reopen the profile, then check the same URLs anonymously. If the biography is already empty, record the test configuration and look for additional processing that may have changed it before concluding.

Empty the native field while retaining the account

On a copy, start with the profile form: the change is limited to one field and verification is immediate. To apply the same correction to your team's case, make sure this change is part of the validated request and your account can edit the affected profile. If the screen redirects to your own profile or the save button is unavailable, change nothing: involve the person authorized to edit the target account.

Deleting the account is a different operation. Depending on the selected option, it may delete or reassign content; it is not a shortcut for removing a biography while retaining the author. Similarly, hiding the theme's author box may reduce visibility on one page but leaves the native value in the database and potentially available to another template. The correct first action is to empty the field at its source, then assess remaining copies.

In multisite, the WordPress profile and user metadata are shared at network level. Opening a subsite's administration area does not make the native biography specific to that subsite. If the change should affect only one subsite, first check whether the text belongs to a theme or plugin's local field. Have network scope validated before changing the shared profile.

1. Open Users > All Users > Edit for the verified ID. Under About the User, locate Biographical Info. Change neither role, address nor display name.
2. Select all field content, including spaces or line breaks, leave it empty and click Update User. If a plugin form sits beside it, check that you changed the native field.
3. Leave the record, then reopen it from the user list. If the text returns immediately, the source is still being populated: check the correct ID, saving and any profile import or synchronization mechanism.
4. View the control post in a private window. Check the display name and post attribution, then the biography's presence or absence in its previous location. Record form and public-page results separately.

Trace text that remains visible

If the profile is empty but the text still appears, first open the exact URL and identify the element containing it. On a post, it may be an author box in the template, a manually edited block or a quotation in the body. On a team page, the text may come from WordPress content independent of the account. In the Site Editor, when offered by the theme, check the template used by that URL; in a page builder, check the corresponding element. The same “Biography” label may refer to different fields depending on the template.

To distinguish a copy from an active source, compare the visitor page with a fresh response from the same template in staging. Use the host's designated cache bypass if available and you can confirm what it bypasses. A private window removes most local history, but site or CDN cache remains shared by visitors. Adding a query string to the URL is not proof of bypass: some layers ignore it. If you cannot safely obtain a fresh response, have the cache owner check that layer.

An empty native profile with text present in a fresh response points to a second source. Edit the identified source: a membership-plugin field, team entry, reused block or copy written in a post. In staging, you can temporarily replace its dummy text with another marker to see which pages follow the change. This comparison is more precise than disabling every component. If a fresh response no longer contains the text but visitors still receive it, purge affected URLs after correcting their source and follow WordPress cache diagnosis.

1. Record one URL where the text was visible and one control URL where it was not. Compare responses without using an administration session as the public-view control.
2. If text remains in a fresh response, locate its source with a different marker in staging. Correct that source and recheck the URL before purging.
3. If text remains only in an old response, purge the page and related surfaces containing that copy, then open them as a new visitor. If one page remains positive, resume its diagnosis instead of randomly expanding the purge.

Check the field with WP-CLI without displaying its value

This variant helps when you have an authorized terminal on the copy, several records look similar or you want repeated checks without copying the text. It verifies that the ID matches an account, then reports only whether the native metadata is empty after trimming surrounding whitespace. It does not list accounts, read plugin fields or decide whether data is publicly visible. An unexpected value is reported as an error: retain this distinction from an “empty” result.

Save the code below as /chemin/prive/verifier-bio.php, outside the public root. Replace the dummy folder, URL and ID in wp --path="/chemin/recette" --url="https://recette.example.test" eval-file "/chemin/prive/verifier-bio.php" 123. First verify the installation and environment following the WP-CLI targeting guide. The --url option selects site context; it does not isolate a multisite subsite's user data. This command loads WordPress. Do not run it on an uncertain target or add --skip-wordpress, because the script uses WordPress functions.

A BIO_PRESENTE result indicates stored content remains, even if a theme ignores it. BIO_VIDE means the field read contains no text relevant to this check. After saving the profile, rerun the same command and compare both states. If an error occurs or a plugin populates the biography from another value, return to checking the profile and relevant component. Avoid a command that displays metadata directly: its content would end up in the terminal or execution trace.

<?php
$id = filter_var($args[0] ?? null, FILTER_VALIDATE_INT, [
    'options' => ['min_range' => 1],
]);
if (count($args) !== 1 || $id === false) {
    WP_CLI::error('Indiquez un seul ID de compte entier et positif.');
}
if (!get_userdata($id)) {
    WP_CLI::error('Compte introuvable sur cette installation.');
}
$description = get_user_meta($id, 'description', true);
if (!is_string($description)) {
    WP_CLI::error('Format inattendu pour la biographie native.');
}
WP_CLI::log(trim($description) === '' ? 'BIO_VIDE' : 'BIO_PRESENTE');

Decide whether the correction can be closed

You need separate results for storage, display and site integrity. In the profile, the value must remain empty after reopening. On pages where the biography was visible, visitors must no longer receive the text, including in page source if the theme retains it in a hidden block. The author link and posts that must be retained must still work. If a page fails any check, the tracking record must state which one. Positive results on two surfaces do not establish the third's state.

Depending on the site, also check paginated author pages, language variants, mobile templates loading a different response or the member profile presenting the same person. Feeds and other publishing outputs do not necessarily reproduce visible-page content. Check only outputs actually offered by the site, for example those identified through the WordPress feed-checking method. Do not reuse an old data export as a current-state test: it is a copy created at another date. There is no need for a new full export if the question concerns only the native field.

For tracking, record the date, roles used, internal ID in the authorized record, request status and “present” or “absent” results per surface. Use the dummy value for staging screenshots. In the real case, include neither biography text, exports nor addresses in shared screenshots and logs. If an external copy remains visible, document its owner and status separately: emptying the WordPress profile does not remove a page controlled by a third party.

1. Check the field after reopening and repeat the public check after purging or the planned cache interval, using a session without an account.
2. Check at least one post attributed to the account and its author destination. If the author changed or the post disappeared, stop and examine the change before declaring the case closed.
3. Distinguish what you checked, what depends on a plugin and what remains to handle outside the site. If the request covers other data, continue those checks in the same record.

Plan rollback without republishing the biography

In staging, you can restore the dummy marker in the profile to confirm the connection between source and display, then erase it again before finishing. On a real site, if the wrong account was changed or content was affected, stop changes and have the person responsible for handling the request validate the correction. For a layout problem, repair the template or display condition: restoring the biography to conceal a visual fault would republish the text.

A broader restore can reintroduce an already-removed biography. When restoration is necessary for another incident, check the isolated copy and reapply relevant corrections before returning it to service. Backups, logs and previous exports have their own handling scope: WordPress's status does not establish their state. Do not create a new copy of the data to demonstrate that it was deleted from the profile.

If the field fills again despite changing the correct account, identify what writes the value: member synchronization, scheduled import or profile plugin. Another purge will not stop that write. If uncertain, provide a reduced staging case with the dummy marker, the time the value returned, active profile-management components and affected surfaces. The team can reproduce the problem without personal text.

Prepare automation without confusing an exporter with an eraser

For a recurring need, a developer can integrate processing through the wp_privacy_personal_data_erasers filter. This mechanism receives a request address and page number; each processor must report removed items, retained items, messages and completion. A profile exporter's existence does not automatically create this eraser.

Before writing the integration, define the exact field to handle, how to identify the account and network scope. Processing must be repeatable without additional effects, leave posts attributed and report write failure instead of announcing success. A synchronized biography also requires addressing the source that reintroduces it. Test a dummy account with a biography, an account without one, a request without a matching account and a second pass on the same request.

For one case, emptying Biographical Info in the profile remains the free native solution and is easier to verify. Use a generic privacy plugin only if its documentation explicitly covers this field and your staging test confirms it. The global Completed status does not replace rereading the field and public surfaces.