[salvatorecorsi]

When multiple personal-data exporters contribute to the same group and item, wp_privacy_process_personal_data_export_page() prepends each later response to the earlier data. This reverses exporter priority and page order. Reused string keys can also cause later name/value records to be discarded.

Append each incoming name/value record to the item's existing list. This preserves every record in the order it was exported, including records with numeric, sparse numeric, or reused string keys. Grouping, response handling and metadata cleanup remain in the existing processing flow.

Trac ticket: https://core.trac.wordpress.org/ticket/44151

This follows robobot3000's append proposal in 44151.3.patch. Thanks to allendav for confirming the report and providing a corrected exporter-registration example in the ticket. The historical proposal is being refreshed with regression coverage; this does not claim prior maintainer acceptance.

Reproduction and regression coverage

1. Register two callable exporters at filter priorities 5 and 10, both contributing to the same group_id and item_id.
2. Process two pages from each exporter, using distinct name/value records on each page.
3. Inspect _export_data_grouped during wp_privacy_personal_data_export_file.
4. Expect the records from exporter 1, pages 1 and 2, followed by exporter 2, pages 1 and 2. Before this change, the numeric-key records appear in the reverse page order. With the same two string keys on each page, only the first page's two records survive instead of all eight.

Four integration cases cover numeric keys, sparse numeric keys, colliding string keys, and empty data. The callbacks are registered in reverse order to verify that filter priorities establish their processing order. Tests invoke those callbacks and the real processing function against a user-request post and its metadata, capturing grouped data at the export-file action. They also check distinct groups and items, callback sequence, unchanged response data and completion flags, the download URL, and removal of temporary metadata. The original exporter hook and the test's action callback are restored after each case.

The test class's existing setup disables archive generation. These new tests do not execute email delivery, archive generation, or the AJAX transport.

Validation

• Frozen-base RED on e46ac23b14711601e6cb17aafe63af6673c03591: 4 tests, 52 assertions, 3 expected failures. The empty-data control passed.
• Fixed-runtime focused regression: 4 tests, 76 assertions passed with the same test file.
• Complete processing-function test class: 28 tests, 118 assertions passed.
• Complete privacy PHPUnit group: 284 tests, 673 assertions passed.
• WordPress coding standards and PHP compatibility checks passed for both changed files.
• Scoped PHPStan for privacy-tools.php: zero errors. PHP syntax and git diff --check passed.
• Full npm run build after the runtime fix: passed. Built and source wp-admin/includes/privacy-tools.php are byte-identical (SHA-256). Existing Node deprecation and webpack asset-size/performance warnings remain nonfatal.
• A separate Codex agent reviewed the complete implementation and test diff, contract, and validation evidence without actionable findings.

PHPUnit ran through the laboratory's serialized runner against its isolated, disposable MariaDB database. The runner executed these checkout-local commands:

php vendor/bin/phpunit -c phpunit.xml.dist --filter test_grouped_data_preserves_exporter_and_page_order
php vendor/bin/phpunit -c phpunit.xml.dist --filter ^Tests_Privacy_wpPrivacyProcessPersonalDataExportPage::
php vendor/bin/phpunit -c phpunit.xml.dist --group privacy
php vendor/squizlabs/php_codesniffer/bin/phpcs --report=summary,source --parallel=1 src/wp-admin/includes/privacy-tools.php tests/phpunit/tests/privacy/wpPrivacyProcessPersonalDataExportPage.php
php vendor/squizlabs/php_codesniffer/bin/phpcs --standard=phpcompat.xml.dist --report=summary,source --parallel=1 src/wp-admin/includes/privacy-tools.php tests/phpunit/tests/privacy/wpPrivacyProcessPersonalDataExportPage.php
php vendor/bin/phpstan analyse --memory-limit=2G --no-progress --error-format=json src/wp-admin/includes/privacy-tools.php
php -l src/wp-admin/includes/privacy-tools.php
php -l tests/phpunit/tests/privacy/wpPrivacyProcessPersonalDataExportPage.php
git diff --check

PHPUnit reported the existing deprecated XML configuration schema notice. No new warning suppression was added. The full repository PHPUnit suite, multisite and Docker-based tests were not run.

Use of AI Tools

AI assistance: Yes
Tool(s): OpenAI Codex
Used for: Issue investigation, implementation, regression tests, validation and this PR description. A separate Codex agent reviewed the complete implementation, test diff and validation evidence. No human review by the account owner is claimed; contributor and maintainer review is requested.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props salvatorecorsi.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.