Skip to content

Conversation

@hbhalodia
Copy link

  • Add soft type safe check to wxr_cdata function, and typecast the incoming input to string.

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


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
Copy link

github-actions bot commented Dec 4, 2025

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 hbhalodia, westonruter.

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

@github-actions
Copy link

github-actions bot commented Dec 4, 2025

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

  • The Plugin and Theme Directories cannot be accessed within Playground.
  • 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.

@hbhalodia hbhalodia requested a review from westonruter December 5, 2025 04:54
Comment on lines 246 to 248
if ( ! is_string( $str ) ) {
return '';
}
Copy link
Member

@westonruter westonruter Dec 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe I may be contradicting a previous suggestion I had here, but here's the latest informed by my latest research:

Suggested change
if ( ! is_string( $str ) ) {
return '';
}
if ( ! is_string( $str ) && is_scalar( $str ) ) {
$str = (string) $str;
}

Copy link
Member

@westonruter westonruter Dec 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or:

Suggested change
if ( ! is_string( $str ) ) {
return '';
}
$str = (string) $str;

Copy link
Author

@hbhalodia hbhalodia Dec 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @westonruter, I guess the first suggestion should be something like below,

if ( ! is_string( $str ) || is_scalar( $str ) ) {
    $str = (string) $str;
}

This is because, what if data is null? ! is_string( null ) would evaluate to true, but is_scalar( null ) would evaluate to false, hence $str will remain as is and would not change to string, it would then gives the fatal for null value.

https://www.php.net/manual/en/function.is-scalar.php#:~:text=(PHP%204%20%3E=%204.0.,consider%20NULL%20to%20be%20scalar.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to go by casting it to str whatever value it is as per - https://core.trac.wordpress.org/ticket/64347#comment:14

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, interesting. I wasn't aware that is_scalar( null ) is false. That's news to me and counter-intuitive.

$wpdb->update(
$wpdb->posts,
array(
'post_excerpt' => null,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The post_excerpt field actually cannot be null:

post_excerpt text NOT NULL,

Therefore, this test doesn't test a null value here. I'll remove this test.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, but I have added that the usecase that even setting null would automatically convert to string, which will pass anyhow we add null or not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I tried running these tests against trunk without the fix applied, and this test didn't error, which means that null wasn't passed to wxr_cdata().

$wpdb->update(
$wpdb->users,
array(
'display_name' => null,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The display_name cannot be null:

display_name varchar(250) NOT NULL default '',

So this isn't actually passing a null value to wxr_cdata(). I'll remove this test.

Copy link
Member

@westonruter westonruter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me.

Review from Gemini:

The changes look solid and address the reported fatal error by explicitly casting the input to wxr_cdata() to a string, which satisfies the strict type requirement of wp_is_valid_utf8(). The added test cases cover posts, comments, and term meta, ensuring the fix works across different content types that might contain NULL meta values.

Here is a review of the changes:

src/wp-admin/includes/export.php

  • wxr_cdata():
    • The explicit cast $str = (string) $str; correctly handles NULL values by converting them to an empty string, preventing the TypeError in wp_is_valid_utf8().
    • The DocBlock update to @param string|null $str accurately reflects that the function can now safely accept (and expects) null values from the database.

tests/phpunit/tests/admin/exportWp.php

  • New Tests:
    • test_export_with_null_postmeta_values(): Correctly reproduces the issue by using $wpdb->insert() to bypass potentially strict sanitization in add_post_meta() that might otherwise cast NULL before insertion.
    • test_export_with_null_comment_values() and test_export_with_null_term_meta_values(): Appropriately cover the other metadata tables.
    • The assertions assertNotFalse( $xml ) and the check for channel->item count are sufficient to verify the export process completed without a fatal error.

General

  • Coding Standards: The code adheres to WordPress coding standards (spacing, indentation, casting).
  • Safety: The fix is backward compatible with the behavior of seems_utf8() (which was used previously) regarding NULL values, restoring functionality for exports containing NULL meta.

I have no requested changes. The patch is ready for commit.

pento pushed a commit that referenced this pull request Dec 24, 2025
…ng passed value to `string`.

This ensures that `wp_is_valid_utf8()` does not cause a type error since it only accepts strings. 

Developed in #10595

Follow-up to [60630].

Props hbhalodia, westonruter, desrosj, albigdd, jorbin.
See #38044.
Fixes #64347.


git-svn-id: https://develop.svn.wordpress.org/trunk@61405 602fd350-edb4-49c9-b593-d223f7449a82
@github-actions
Copy link

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 61405
GitHub commit: 814279b

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.

@github-actions github-actions bot closed this Dec 24, 2025
markjaquith pushed a commit to markjaquith/WordPress that referenced this pull request Dec 24, 2025
…ng passed value to `string`.

This ensures that `wp_is_valid_utf8()` does not cause a type error since it only accepts strings. 

Developed in WordPress/wordpress-develop#10595

Follow-up to [60630].

Props hbhalodia, westonruter, desrosj, albigdd, jorbin.
See #38044.
Fixes #64347.

Built from https://develop.svn.wordpress.org/trunk@61405


git-svn-id: http://core.svn.wordpress.org/trunk@60717 1a063a9b-81f0-0310-95a4-ce76da25c4cd
github-actions bot pushed a commit to gilzow/wordpress-performance that referenced this pull request Dec 24, 2025
…ng passed value to `string`.

This ensures that `wp_is_valid_utf8()` does not cause a type error since it only accepts strings. 

Developed in WordPress/wordpress-develop#10595

Follow-up to [60630].

Props hbhalodia, westonruter, desrosj, albigdd, jorbin.
See #38044.
Fixes #64347.

Built from https://develop.svn.wordpress.org/trunk@61405


git-svn-id: https://core.svn.wordpress.org/trunk@60717 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants