[wp-trac] [WordPress Trac] #25851: post_content lost when inserting Posts with large base64-encoded images

[WordPress Trac]

#25851: post_content lost when inserting Posts with large base64-encoded images
-----------------------------+-----------------------------
 Reporter:  ctayloroomphinc  |      Owner:
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Formatting       |    Version:  trunk
 Severity:  critical         |   Keywords:
-----------------------------+-----------------------------
 post_content will be silently blanked-out during a wp_insert_post() call
 that contains large base64-encoded images within Post HTML content.

 I've found the source of this problem to be the wp_pre_kses_less_than()
 function. In the scenario described above, the call to
 preg_replace_callback() fails, causing a NULL to be returned from
 wp_pre_kses_less_than(), instead of a string. In this case
 preg_replace_callback() returns NULL because of a
 PREG_BACKTRACK_LIMIT_ERROR.

 The error can be worked around by setting a higher pcre.backtrack_limit in
 php.ini, but I still consider this to be a bug because the
 wp_pre_kses_less_than() should at least emit a warning to the debug.log
 informing someone that there was an internal PHP error (silent in this
 case, regardless of error_reporting settings).

 Beyond this, the function should check the return value of
 preg_replace_callback(), and if it is NULL, perhaps consider returning the
 original string as it was passed by the caller, so the caller does not end
 up with unexpectedly empty post_content.

 Another option would be to look in to tweaking the regex so that it does
 need exceed the default resources as configured by pcre.backtrack_limit,
 which is 100000 by default.

 More info: http://www.php.net/manual/en/pcre.configuration.php#ini.pcre
 .backtrack-limit

 I have attached a file that shows how to re-produce this bug. Run the file
 via WP-CLI like so:

 wp eval-file wp_pre_kses_less_than_bug_repro.php

 I'm setting the Severity of this bug to critical, since it results in
 unexpected data loss.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25851>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software