The column name length is limited to 50 characters

I think the idea was to try to keep it light but 50 was really stingy. I've extended it to 256, lmk if that works for you.

I do recommend still doing some kind of string handling on your end to prevent issues. 256 will give you more breathing room, but just like when you try to save a node with an extra long title, you'll run into issues when setting values programatically.

Thanks, @brantwynn! Our industry is very wordy!

Removing based on comments received.

Thanks for providing the update hook but you may be shooting yourself in the foot using that designation, 8701.

Chances are I will never get to a version 7, but if I do, you'll have an old Update hook and the wrong index to key off of.

8701 would be the FIRST update hook (01) from version 8.x-7.x

Had there been a release, and then an initial update changing this, then you would need an update hook. And it would be like, 8101.

It's a common mistake to confuse the second number in update hooks for the minor version of core. I see it a lot, but its wrong. As long as the developer stays consistent, it works, but it doesn't follow the docs.

First slot, drupal version. E.g. 8
Second slot, module version. E.g. 1
Second two for version update #'s up to 01-99

No idea what they want us to do after the 99th update hook. Cut a new version I guess? :)

Its an absolute HAMMER to use a fake update hook here. So hopefully you didn't do this to your prod site. Because that means update module is now looking for any updates that are a higher number than 8701. If I do an 8.x-1.1 and provide an 8101 update hook, changing something else, you won't get that update.

The other thing you'll want to avoid is having functions declared from within another function. That's just a general thing not expected in Drupal. It *may* work in PHP but there's probably a Drupal doc somewhere about why that's not a best practice?

The better way to fix this problem would be to introduce that function (apparently lifted from https://www.drupal.org/project/title_length/issues/2950092#comment-12635254) and put it in a custom module (or perhaps wrap it in a drush command?)

Then you could do something like this: drush eval " db_change_varchar_field('basic_data', 'name', 256);" as a one-off, fixing your existing site. You could even use remote aliases to fix remote sites this way.

Thanks for this clarification. I hacked together the solution from: https://www.drupal.org/docs/8/api/update-api/updating-database-schema-an...

But it doesn't do a great job of telling one where to put that code...

It's not a prod site. I'll probably just manually drop the row that shows the database update has run and remove this code. Thanks again!

And while I do appreciate you marking the issue as "Fixed' - what you want to use is "Reviewed and Tested by the Community"

Its supposed to really just be maintainers that change that flag. I am a chillaxed maintainer and don't really care, but other people won't approve sometimes.

Thanks again for the collaboration, JSI team :)