I've noticed that when I create a node with too much data in the body field subsequent edits will not save. Or rather, the save goes ahead and I am taken back to viewing the node, but the content hasn't changed.

After extensive trial and error I was able to determine that any save which had a body length of less than 64 Kb saved fine but anything more than that would not save.

What is the cause of this and is there any way to get around it?

3 Answers 3


The reason of the problem is a regular expression that causes PCRE to reach the limit set for pcre.backtrack_limit or pcre.recursion_limit.
There was an issue report on drupal.org about truncated body content; the length of the text that is possible to enter before it gets truncated depends from the characters used (English text can be longer than a text containing all Unicode characters), and from the values set for pcre.backtrack_limit and pcre.recursion_limit.

The issue report I am speaking of is Document possible preg memory issues. Gerhard Killesreiter's comment is the following one:

This issue [the body content being truncated] is due to the limits of the perl regular expressions that we use to validate that you posted valid UTF8.

If you increase the limits in your settings.php file you will see the text.

ini_set('pcre.backtrack_limit', 200000);
ini_set('pcre.recursion_limit', 200000);

You will need to experiment which values work for you.

node_schema() defines the body field of the node_revisions table as "big text". This means that with MySQL the maximum length of a node body is 4 GB, and with PostgreSQL there isn't (theoretically) any limit; in both the cases, the limit is not the 64KB you are observing.

The default.settings.php file contains the following comment:

 * If you encounter a situation where users post a large amount of text, and
 * the result is stripped out upon viewing but can still be edited, Drupal's
 * output filter may not have sufficient memory to process it.  If you
 * experience this issue, you may wish to uncomment the following two lines
 * and increase the limits of these variables.  For more information, see
 * http://php.net/manual/en/pcre.configuration.php.
# ini_set('pcre.backtrack_limit', 200000);
# ini_set('pcre.recursion_limit', 200000);
  • Thanks for that. I tried really large values for those settings, but it did not help. I believe that in my case it is not a problem with the input filters - the data I'm submitting isn't even making it into the DB. When I look in node_revisions there is a row for that revision but it's body field is empty. I also tried using an input filter that did no processing at all, but it didn't make any difference. The input filters are only used for displaying data, not changing what ends up in the DB Mar 21, 2011 at 22:22

For sites with Suhosin enabled, this is likely to be the default limit on POST value lenght.

suhosin.post.max_value_length=65000 is Suhosin's default (and may not be in /etc/php5/conf.d/suhosin.ini until you add it).

This setting will be visible in the output of phpinfo().


Some distributions include patches that enforce additional limits on incoming requests in the name of security. I've had problems with webform submissions that contain "too many" parameters which was resolved by increasing the limit enforced by the security patch that Debian includes in PHP.

You might want to look in your PHP and/or HTTP server error logs and see if you can find any mention of requests that are too long, etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.