Textfield maxLength in panel not accepted

running 2.4.0 i have a text panelfield with maxLength set to 1500. char count in my texteditor shows 1500 chars for my dummy text. panel char counter above textarea shows 1500/1500. dummy text is copy pasted on windows system, possible from a word or pdf document.

BUT page can not be saved in panel. field is flagged as not valid. if i remove all linebreaks all is well. maybe there is something wrong in the panel/validator when validating concerning linebreaks or other hidden chars?

The validator does no more than check the string length:

'maxLength' => function($value, $max) {
  return str::length(trim($value)) <= $max;

public static function length($str) {
    return MB ? mb_strlen($str, 'UTF-8') : strlen($str);

So I guess the issue is rather due to hidden characters.

It’s probably not recommendable to copy/paste from a Word or PDF document, my experience is that is causes all sorts of problems due to hidden characters.

but why does panel show 1500/1500 chars but does not allow saving? it does not show 1506/1500, so its not counting the hidden chars there. i have to remove the chars linebreaks (and hidden chars with them maybe) bringing panel counter to 1494/1500 until i can save it. so 6 chars difference. two for each linebreak.

so panel counter does not count the same way the validator does. is that ok that way?

Yes, you are right, I just tested this with a Lorem Ipsum generator and inserted some line breaks. The counter says 1500, but does not save. So it doesn’t seem to be related to hidden Word characters after all.

glad to hear that. it was driving me nuts. :wink:

do you know how to fix it then? i would like to hotfix this for my client asap and not wait for next release?

I think the problem is caused by the JavaScript counter, but I can’t find a fix.

I researched a bit and found the culprit.

For reasons unknown, jQuery always converts all newlines in the value of a <textarea> to a single character. That is, if the browser gives it \r\n for a newline, jQuery makes sure it’s just \n in the return value of .val().

Source: http://stackoverflow.com/questions/10030921/chrome-counts-characters-wrong-in-textarea-with-maxlength-attribute

PHP counts the same way as the browser, two characters for each new line. That’s why the length you see on the front-end is different from the length PHP sees on the backend.

Adding this .replace() method at panel/app/fields/text/assets/js/counter.js solves the issue:

// line 19
length = $.trim(field.val().replace(/\r(?!\n)|\n(?!\r)/g, "\r\n")).length;

// Credit: http://stackoverflow.com/a/21487955

The file above is not loaded directly by the panel, if you want to apply this quick fix before it’s fixed in Kirby, edit the compiled file at: panel/assets/js/dist/form.min.js


Yep, that fixes it. Could you create a pull request, please, @pedroborges?

That’s what I’m working on right now :wink:

Edit: PR sent



Great, thanks, @pedroborges!

1 Like