You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of the problem
EE has a long-standing problem with field content larger than 64KB. I understand that this relates to SQL column widths, and is in theory possible to work around by increasing those widths, but this is not a reasonable expectation for most users.
There are two issues here. The first is the existence of a limit. While most people will likely never hit the 64KB limit, there are real situations in which the limit might be exceeded. The following link is to an EE forum discussion of several years ago after I hit the 64KB limit with a real use-case. Note also a recent post to that thread, in which another user describes losing data after unknowingly hitting the 64KB limit with real content.
In the context of Medium-like long-form writing, and short fiction, with a reasonable amount of markup, it's not at all unlikely that 64KB will be exceeded for a single content field. EE should be able to handle this.
The second issue relates to how EE handles exceeding an existing limit. The current limit is undocumented, and no native warnings are provided that the limit has been exceeded. In the environment described below, saving an entry with a content field larger than 64KB results in an SQL exception. Note also that in the EE forum discussion linked earlier, a user describes content being truncated with no error/warning.
Anything which has the potential to cause the loss of user data should be treated seriously. As a minimum, the 64KB limit should be documented, and a warning should be provided, to avoid potential loss of data. Ideally, EE should seamlessly handle data larger than this.
How To Reproduce
Create/save an entry with a content field larger than 64KB.
Error Messages
SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column
Thanks for posting this issue. We discussed this yesterday after in came up in slack. The following is our current plan to move forward.
In EE 5.4 (and 6) we'll be adding the ability to change the DB storage type of fields to be TEXT, MEDIUMTEXT, or LONGTEXT
In EE 6 we're also adding an additional JS check on the publish / edit screen for content length on appropriate native fields and will warn the user accordingly.
Description of the problem
EE has a long-standing problem with field content larger than 64KB. I understand that this relates to SQL column widths, and is in theory possible to work around by increasing those widths, but this is not a reasonable expectation for most users.
There are two issues here. The first is the existence of a limit. While most people will likely never hit the 64KB limit, there are real situations in which the limit might be exceeded. The following link is to an EE forum discussion of several years ago after I hit the 64KB limit with a real use-case. Note also a recent post to that thread, in which another user describes losing data after unknowingly hitting the 64KB limit with real content.
https://expressionengine.com/forums/topic/250764/better-handling-of-64kb-content-fields
In the context of Medium-like long-form writing, and short fiction, with a reasonable amount of markup, it's not at all unlikely that 64KB will be exceeded for a single content field. EE should be able to handle this.
The second issue relates to how EE handles exceeding an existing limit. The current limit is undocumented, and no native warnings are provided that the limit has been exceeded. In the environment described below, saving an entry with a content field larger than 64KB results in an SQL exception. Note also that in the EE forum discussion linked earlier, a user describes content being truncated with no error/warning.
Anything which has the potential to cause the loss of user data should be treated seriously. As a minimum, the 64KB limit should be documented, and a warning should be provided, to avoid potential loss of data. Ideally, EE should seamlessly handle data larger than this.
How To Reproduce
Create/save an entry with a content field larger than 64KB.
Error Messages
SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column
Environment Details:
The text was updated successfully, but these errors were encountered: