💎 PREMIUM: Ticket/ - Collection

Get WordPress

Make WordPress Core

Opened 4 weeks ago

Last modified 6 days ago

#64347 reopened defect (bug)

Fatal error when `wxr_cdata()` is called with non-string value

Reported by: desrosj's profile desrosj Owned by: westonruter's profile westonruter
Milestone: 6.9.1 Priority: normal
Severity: normal Version: 6.9
Component: Export Keywords: has-patch has-unit-tests dev-feedback fixed-major
Focuses: Cc:

Description

From ​this issue on the wp.org Support forums:

Hi

During export, a page opens with this message: “This site is unreachable. Website at ​https://kamerydrogowe.wlkp.net.pl/wp-admin/export.php?.. may be temporarily unavailable or may have been permanently moved to a new internet address. ERR_INVALID_RESPONSE”

WordPress, themes, plugins – updated. Theme enabled on Twenty tweny – still a problem. Plugin cache cleared, web browser cache and cookies cleared – still the problem. All plugins disabled – export downloads, but only 1.1 Mb instead of about 16 Mb.

I also got the message: “The old WordPress core file was not removed during the update: wp-includes/SimplePie/src/Core.php”

The following log output was followed in a follow up response:

[03-Dec-2025 20:47:17 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /wp-config.php:103) in /wp-includes/functions.php on line 7182
[03-Dec-2025 20:47:17 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /wp-config.php:103) in /wp-admin/includes/export.php on line 96
[03-Dec-2025 20:47:17 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /wp-config.php:103) in /wp-admin/includes/export.php on line 97
[03-Dec-2025 20:47:17 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /wp-config.php:103) in /wp-admin/includes/export.php on line 98
[03-Dec-2025 20:47:17 UTC] PHP Fatal error:  Uncaught TypeError: wp_is_valid_utf8(): Argument #1 ($bytes) must be of type string, null given, called in /wp-admin/includes/export.php on line 246 and defined in /wp-includes/utf8.php:39
Stack trace:
#0
/wp-admin/includes/export.php(246): wp_is_valid_utf8(NULL)
#1
/wp-admin/includes/export.php(682): wxr_cdata(NULL)
#2
/wp-admin/export.php(123): export_wp(Array)
#3 {main}
  thrown in
/wp-includes/utf8.php on line 39

Change History (18)

#1 @desrosj
4 weeks ago

Looking through wp-admin/includes/export.php, it seems that there are a few possible culprits.

If a plugin or theme is using a filter (the_title_export/the_content_export/the_excerpt_export) to return a value a non-string value such as NULL or an integer, there is no protection in place for this and a fatal error will occur due to the string type safety defined for wp_is_valid_utf8(). Though that seems to be a scenario that could come up, I don't think that's the root cause in this case because the user is still seeing the issue after disabling all plugins.

The other possibility is that a plugin or some custom code has explicitly set a meta value to a non-string value. Because export_wp() performs direct database queries to retrieve post/term/comment metadata, there's no guarantee that non-string values will be converted to strings as expected.

#2 @swissspidy
4 weeks ago

#64351 was marked as a duplicate.

This ticket was mentioned in ​PR #10595 on ​WordPress/wordpress-develop by ​@hbhalodia.
4 weeks ago #3

  • Keywords has-patch added
  • 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

#4 @hbhalodia
4 weeks ago

Hi @swissspidy @desrosj

Since wp_is_valid_utf8 function is always expecting the incoming data to be string, we need o make sure what we send is always a string. Hence I have created a PR ​https://github.com/WordPress/wordpress-develop/pull/10595, which adds the soft type-safe, Since we do not know what can be input to wxr_cdata function, hence strict type check won't be feasible at the moment (let me know if needs to be stricter check), but then we need to make sure where this function is called, the param should passed as string, else it can throw the fatal on this function.

#5 follow-up: @desrosj
4 weeks ago

Thanks for the pull request, @hbhalodia!

Before we decide which specific solution is best, I think there are a few things we should do.

First, we should look into how were NULL or other non-string values exported in WordPress 6.8? Are they preserved? Converted to a string? Something else?

We should also write some unit tests that tests NULL

@hbhalodia are you able to help with either of these?

#6 in reply to: ↑ 5 @hbhalodia
4 weeks ago

Replying to desrosj:

Thanks for the pull request, @hbhalodia!

Before we decide which specific solution is best, I think there are a few things we should do.

First, we should look into how were NULL or other non-string values exported in WordPress 6.8? Are they preserved? Converted to a string? Something else?

We should also write some unit tests that tests NULL

@hbhalodia are you able to help with either of these?

Sure, I will work on this and would provide an update soon.

This ticket was mentioned in ​Slack in #forums by threadi. ​View the logs.
3 weeks ago

This ticket was mentioned in ​Slack in #core by skithund. ​View the logs.
3 weeks ago

#9 @albigdd
3 weeks ago

Thank you @hbhalodia for your patch. It fixed this issue for us.

#10 @westonruter
3 weeks ago

#64396 was marked as a duplicate.