Opened 11 years ago
Last modified 4 years ago
#23275 new defect (bug)
WordPress Importer: line-ending mismatch corrupts serialized meta
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 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)
Change History (8)
#2
@
11 years ago
The issue:
I've noticed that on some installs (xampp, mampp) 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.
#4
@
11 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.
#6
follow-up:
↓ 7
@
8 years 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
#7
in reply to:
↑ 6
@
8 years 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
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.