Sanitize 'update_plugins' and 'update_themes' transients.

[siliconforks]

WordPress stores plugin and theme update information in the 'update_plugins' and 'update_themes' transients respectively.

If the wp_options table uses a legacy character set (e.g., utf8mb3), then it is possible that plugin or theme update information may contain characters which cannot be represented in the database.

If that happens, then the transients cannot be saved to the database, which will prevent updates from occurring.

To avoid this, we need to call $wpdb->strip_invalid_text_for_column() on the transients before they are serialized and stored in the database.

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

Use of AI Tools

None

---

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.

[siliconforks]

Some notes for people testing and/or reviewing this PR...

To run the test suite with the new test, I ran the following command:

./vendor/bin/phpunit --filter Tests_Option_SanitizeOption

Then I edited my wp-tests-config.php file and changed this line:

define( 'DB_CHARSET', 'utf8mb4' );

to this:

define( 'DB_CHARSET', 'utf8mb3' );

Then I ran the test suite again.

This works (and it is similar to the way Tests_Option_SanitizeOption::test_emoji_in_blogname_and_description() works) but it is rather clumsy and it means the actual sanitization won't get tested unless someone deliberately configures the database to use utf8mb3. Is there a better way to test this?

[adamsilverstein]

Any risk in touching every field? which field have actual user controlled data, can/should we limit to just those?

[siliconforks]

We could skip some fields. But one problem is that plugins can use the Update URI header field and the update_plugins_{$hostname} filter to basically put whatever they want in any field. So even if there are some fields that will never contain anything but ASCII for plugins hosted in the wordpress.org plugin directory, there may be other third-party plugins which get their update information from some external server, and that information could basically contain anything anywhere.

[adamsilverstein]

Overall I like this approach better and while it doesn't exclude landing the error handling from #12596 I'm not sure we need that PR unless there is an actual route to triggering an error.

[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 siliconforks, adamsilverstein.

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.