WordPress.org

Make WordPress Core

Opened 15 months ago

Last modified 15 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:

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 15 months ago.

Download all attachments as: .zip

Change History (6)

comment:1 johnbillion15 months 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.

WraithKenny15 months ago

comment:2 WraithKenny15 months 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 15 months ago by WraithKenny (previous) (diff)

comment:3 WraithKenny15 months ago

  • Keywords reporter-feedback removed

comment:4 WraithKenny15 months 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 SergeyBiryukov15 months ago

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