WordPress Importer: line-ending mismatch corrupts serialized meta

[WraithKenny]

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
				'!s:(\d+):"(.*?)";!se',
				"'s:'.strlen('$2').':\"$2\";'",
				$meta['value']
			)
		);

	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;
}

[johnbillion]

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.

[WraithKenny]

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.

[WraithKenny]

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.

[jjeaton]

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

[netweb]

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