Make WordPress Core

Opened 3 years ago

Last modified 4 months ago

#23275 new defect (bug)

WordPress Importer: line-ending mismatch corrupts serialized meta

Reported by: WraithKenny Owned by:
Milestone: WordPress.org Priority: normal
Severity: normal Version:
Component: Import Keywords: has-patch
Focuses: Cc:


A possible solution:

if ( $key ) {
	// export gets meta straight from the DB so could have a serialized string
	if ( ! $value )
		$value = maybe_unserialize( $meta['value'] );
	// Occationally, line-endings break unserialize()
	if ( empty( $value ) ) // Try normalizing...
		$value = maybe_unserialize( str_replace( array("\r\n", "\r", "\n"), "\r\n", $meta['value'] ) );
	if ( empty( $value ) ) // Adjust string length if needed
		$value = maybe_unserialize(
			preg_replace( // e flag deprecated in PHP 5.5.0 I think

	add_post_meta( $post_id, $key, $value );
	do_action( 'import_post_meta', $post_id, $key, $value );

	// if the post has a featured image, take note of this in case of remap
	if ( '_thumbnail_id' == $key )
		$this->featured_images[$post_id] = (int) $value;

Attachments (1)

23275.patch (1.1 KB) - added by WraithKenny 3 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 @johnbillion3 years ago

  • Keywords reporter-feedback added

Are you able to submit this as a patch Kenny? Or a pointer to which file and line it affects. A little more detail would be good too, such as what the problem is exactly and what this is fixing.

@WraithKenny3 years ago

comment:2 @WraithKenny3 years ago

The issue:

I've noticed that on some installs (xampp, mampp, so basically all my local installs) the parsing of the import file into php, and then the attempt to unserialize fails do to line-ending mismatches. This patch attempts to normalize the line-endings if first pass fails, and adjusts the s-length if the second pass fails.

Alternatively, finding out which step causes the line-endings to change/conflict and preventing it there might be a better/cleaner solution, but that might be with how plugins store meta_data. My own plugin seems to save different endings via html post or ajax save. It doesn't effect the functioning of the plugin tho, only the importing of the meta_data. This should be fine anyway, except that when the file is saved (either by the browser, or up to the server or when the file is processed), then line-endings change, corrupting data or the s:length.

The patch was what I could get working.

Last edited 3 years ago by WraithKenny (previous) (diff)

comment:3 @WraithKenny3 years ago

  • Keywords reporter-feedback removed

comment:4 @WraithKenny3 years ago

It just occurred to me that git might have altered the import file, but I'm fairly certain I also tested fresh export files that didn't go through git. Since this just occurred to me I haven't tested thoroughly.

comment:5 @SergeyBiryukov3 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to WordPress.org

comment:6 follow-up: @jjeaton4 months ago

I just ran into this issue. A mismatch wasn't the problem for me, but having any windows line endings inside a serialized array (even without any other types of line endings).

This appears to be a PHP bug first filed in 2008: https://bugs.php.net/bug.php?id=45573&edit=3. I'm not sure why it never got any attention.

I can reproduce it here: Test case in a PHP Repl

comment:7 in reply to: ↑ 6 @netweb4 months ago

Replying to jjeaton:

I can reproduce it here: Test case in a PHP Repl

Perfect excuse to test some code in all the PHP versions http://3v4l.org/X0pFQ

Note: See TracTickets for help on using tickets.