This issue stems from Killes' comment. Should form field maxlengths be consistent with corresponding database field sizes or should unicode encoding be accounted for?

This is especially in light of the fact that 4.7 now converts all existing databases to UTF-8, but also retains support for (MySQL) 3.23.58.

Or should we just not use maxlengths at all?

Thanks
-K

Comments

morbus iff’s picture

morbus iff
they/them
commented

Selfbump.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Active » Postponed

> Should form field maxlengths be consistent with corresponding database field sizes or should unicode encoding be accounted for?

The maxlengths and field lengths in each case should should be referring to number of characters, not bytes, so this should not be applicable I don't think?

But in any case, yes they should match. I attempted this tonight, but the deal is that form element IDs and database field names do not always match up, so it requires manually looking through, which means this would be really tedious to audit. :P

I spot-checked a few places and they all seemed to match, but if you find any that don't please submit a patch for those issues.

> Or should we just not use maxlengths at all?

Maxlength is not required, but it is a usability thing. It prevents people from typing in a long string that ends up getting truncated when it gets submitted to MySQL.

lilou’s picture

lilou commented
Version: x.y.z » 7.x-dev
Crell’s picture

Crell commented
Status: Postponed » Closed (won't fix)

I don't know that there's any way to automate syncing up the field with the database except manually hitting schema case-by-case. Certainly the logic involved would be very crazy, since forms do not (and should not) map 1:1 to database tables/fields.

I don't think there's a general solution here; individual inconsistencies should be fixed case by case in separate patches.