WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 years 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:

Description

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

Attachments (1)

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

Download all attachments as: .zip

Change History (6)

comment:1 @johnbillion2 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.

@WraithKenny2 years ago

comment:2 @WraithKenny2 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 2 years ago by WraithKenny (previous) (diff)

comment:3 @WraithKenny2 years ago

  • Keywords reporter-feedback removed

comment:4 @WraithKenny2 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 @SergeyBiryukov2 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to WordPress.org
Note: See TracTickets for help on using tickets.