🐛 Fixed slugs from exceeding db limit

[aileen]

closes #8143

Fixed a potential issue (edge-case), where our generated and validated (in terms of check for existance and add a counter) would return a slug, that will exceed the maximum length of the slug fields (191 chars).

This is mostly possible for the post title, which can be 255 chars long and would generate a slug with the same length. This would prevent the user from actually saving a post.

I tried first to determine the expected length for a slug that already exists, but decided that the easier and simplyfied implementation is to always cut a slug to 185 chars (+ counter). This makes it easier to find duplicates and includes a possible high number of counts (edge-edge-case).

[aileen]

@kirrg001 I would like to hear your thought about that. I am not entirely sure, if I might've forgotten a case...

I tried for quite a while to implement it in a different way, but take this situation:

• slug gets generates with 191 chars
• another slug is about to get generated, but is actually a duplicate, so I remove the - and the counter that is about to get added and trim the slug by the same amount. Let's say, it's now 189 chars long.
• our fn checks again, if this slug exists and comes to the conclusion that it doesn't so the returned slug would then the the 189 chars long one (without - and count).
• only for the third time then, we would add a counter to it.

We could definitely implement this logic, but IMO this is a but too much for such edge cases and I therefore vote for my solution.

[kirrg001]

This is a good fix. I can't of a simpler/better solution at the moment. It protects a validation error when the input source (post title, user name) is greater than 191. It does not auto-fix slugs to import. The user has to fix this alone, because a slug can represent an existing url. This is an edge case anyway, because e.g. post titles are usually not so long, same for user names.