Some pages of the site do not save content after changes. Perhaps due to the fact that these pages have the most content. Other pages with similar content are saved normally. So I think it’s about the amount of content.
If you make edits to the .md page file, they are displayed correctly. Problem when editing from admin panel.
How fix this error?
(Grav v1.7.35 - Admin v1.10.35)
1 Like
Hello!
Could you share a larger image? I don’t know if I fail with the use of the forum but I can’t see it correctly…
Reading the error you share (in the thread title), I think it’s a validation failure, so I would check the text entered in the “content” field to see what is causing that error.
Had this come up a couple of times.
Haven’t had time to see if ifs because of php / system.yaml config restriction.
But the workaround is
A) Edit the .md offline and upload it to the directory, as it not affected
B) Go into the admin panel, create your page, switch to expert mode, and save it, as it isn’t affected by the restriction and the error does not appear"
1 Like
This actually helped but it is sad that it is neccesarry.
Thanks a lot!
Yes, I have this error too. Using Grav v1.7.37.1 tried it with the default editor and Tiny. It occurs with very long texts, such as the privacy policy. In expert mode this error is not. Other CMS (Wordpress/Joomla) on the same server with the same php settings don’t have this problem. I think it is necessary that backend users can save large texts even without expert mode. It is a basic function of a CMS.
it may be due to a an error in the page it self.
I had just tested with plain text (no markdown) with an ipsum generator
with 100 paragraphs and 9157 words
On pretty basic php.ini settings
I do have the php yaml extension loaded
With most post sizes being seo optimal at about 1000 words
Have you tried just native text content and find out the bomb out point ?
Of course pure text will be easier to parse as there will be no error check.
Be interesting to see what makes your content fall over !
Please have look at issue 1.7.32: Why impose max sizes for field types? Admin fails on large content sizes. · Issue #3643 · getgrav/grav · GitHub.
For some reason, Grav 1.7.32 has added a default max size of 65536 bytes for text (multiline) and textarea fields of pages. Admin fails when adding larger content sizes because of this validation, however, Grav itself seems to be functioning fine with larger content sizes.
1 Like
thanks for the clarification, Pamtbaau that should be plenty enough for most people and really pages sizes that are really that long would be better with multiple pages and some pagination, as they would be so hard to navigate and read
Even thouse implemented sizes should be enough for microsoft (15,260) , tiktok (7,549) or apple T&C’s (7,134) lol 
@spamhater, The question is not whether 65536 is plenty enough for most people. The question is also not about the user experience when using large documents.
The question is why the size validation has been introduced. Until the release of Grav 1.7.32 (March 2022) the size didn’t seem to be a problem. So why introduce a breaking and undocumented change that people stumble upon?
As you said:
Had this come up a couple of times.
1 Like
Absolutely @anon76427325. I agree. It would help if this limitation exists and you get a helpful hint instead of just shortening the text without an error message.
Also: Each of my projects has at least 1 page that contains more than 65k text, namely the GDPR data protection declaration or general terms and conditions.
Maybe it would make sense to remove the restriction at least for SuperAdmins and to inform all other users about it.
Maybe it would make sense to remove the restriction at least for SuperAdmins and to inform all other users about it.
I can only imagine the size limit to be introduced for some technical reason. Any other reason, like UX or performance, is not up to Grav, but a responsibility of the designer.
If it is a technical reason, the privileges of the Admin user would not make any difference.
Also, in the case of a technical limitation, an error should be thrown by the core when a large file has been created using any text editor. Currently no error is thrown when using pages exceeding the limit.
I know it doesn’t belong here directly, but it is related and may indicate the cause and possible solutions better: I had the same error message when saving a particle module in Joomla (Gantry5). This module is very complex and extensive and I’m really scared that data that was previously laboriously maintained will be lost when saving now. Previously, there wasn’t this limitation because I could store the Particle module with all this data and without warn messages. Since migrating to Joomla 4 I’ve been getting this message. But I don’t know yet whether this message is generated by Joomla or by Gantry5.
@mD.SK, When using the combination of Grav + Admin, the issue is caused by adding form input field size validations in recent Grav versions.
When Admin saves a Page, Grav core validates the input fields and throws the error when input is too large.
This root cause has been explained in a prior reply. Also, see commit: Set default maximum length for text fields · getgrav/grav@3e7f67f · GitHub
Since you are using the combination Gantry + Joomla the changed behaviour must be caused either by Gantry or Joomla. I suggest you log an issue at the Gantry forum/Gantry repo or Joomla.