[wp-trac] [WordPress Trac] #44498: Make `_wp_personal_data_cleanup_requests()` run on cron

[WordPress Trac]

#44498: Make `_wp_personal_data_cleanup_requests()` run on cron
-------------------------------------+---------------------
 Reporter:  desrosj                  |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Privacy                  |     Version:  4.9.6
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-test-info  |     Focuses:
-------------------------------------+---------------------
Changes (by khokansardar):

 * keywords:  has-patch needs-unit-tests => has-patch has-test-info


Comment:

 == Patch testing report ==

 '''Patch / PR tested'''
 * https://github.com/WordPress/wordpress-develop/pull/11444
 * trunk @ 6782f0eecc with PR diff applied

 '''Environment'''

   WordPress: 7.1-alpha-62161-src
   MySQL: 8.4.9
   OS: macOS 26.3.1
   Browser: Chromium, desktop viewport
   Local wordpress-develop @ http://localhost:8889

 '''Steps'''
   1. Confirmed on trunk: no wp_privacy_personal_data_cleanup_requests cron
 event
      exists — only wp_privacy_delete_old_export_files is scheduled.
   2. Confirmed on trunk: privacy-tools.php uses 'column' =>
 'post_modified_gmt'
      in the date_query (timezone bug present).
   3. Created a test pending export request via WP-CLI and backdated
      post_modified to 2 days ago via SQL to simulate an expired request.
   4. Confirmed on trunk: the expired request stays request-pending — it is
 only
      transitioned to request-failed when an admin visits
      /wp-admin/export-personal-data.php (page visit triggers the cleanup).
   5. Applied PR #11444 (fetched as refs/pull/11444/head).
   6. Verified three code changes are present:
      - privacy-tools.php: 'column' changed from post_modified_gmt to
 post_modified.
      - functions.php: wp_schedule_personal_data_cleanup_requests() and
        wp_cron_personal_data_cleanup_requests() added.
      - default-filters.php: both functions hooked to init and the cron
 event.
   7. Loaded a page to trigger init; confirmed
      wp_privacy_personal_data_cleanup_requests is now scheduled (daily
 recurrence).
   8. Created a new pending request and backdated it 2 days via SQL.
   9. Fired the cron event manually with wp cron event run — without
 visiting
      any admin page.
   10. Confirmed the request transitioned to request-failed via cron alone.

 '''Results'''
   - Cron event absent on trunk: pass — no
 wp_privacy_personal_data_cleanup_requests
     event found before patch.
   - Timezone bug present on trunk: pass — post_modified_gmt confirmed in
 query.
   - Cron event registered after patch: pass —
 wp_privacy_personal_data_cleanup_requests
     scheduled daily after first init.
   - Cron cleanup without admin page visit: pass — expired request
 transitioned from
     request-pending to request-failed by firing the cron event directly,
     with no admin privacy page loaded.
   - Backward compatibility: pass — existing synchronous cleanup on admin
 page visit
     continues to work as before.

 '''Conclusion'''
 PR #11444 correctly schedules _wp_personal_data_cleanup_requests() as a
 daily cron event and fixes the timezone mismatch in the expiry date query.
 Expired unconfirmed privacy requests are now cleaned up automatically
 without requiring an admin to visit the privacy management screens.
 Recommend commit.

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