Auto-generated term slugs can be greater than 200 characters, giving "Could not insert term into the database." error

[mikejolley]

When a slug is not user defined, WordPress attempts to generate it from the term name within wp_insert_term. If the slug exists, when inserting subcategories, WordPress prefixes the slug with the top level term name.

https://core.trac.wordpress.org/browser/tags/5.0.2/src/wp-includes/taxonomy.php#L2093

Because of this, long term names can go over the slug length limit and error. WordPress admin simply shows:

Could not insert term into the database.

There is no reasoning provided, and when using wp_insert_term programatically it's hard to know what's at fault.

This issue is more apparent when using cyrillic characters since they are stored encoded in the DB.

Take "Категория на продукта" as an example. In the database this gets stored as:

%d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d1%8f-%d0%bd%d0%b0-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0

This is 116 characters. The maximum allowed slug length defined in the wp_terms database schema is 200 characters.

Steps to reproduce:

• Add a top level category "Категория на продукта"
• Add another "Категория на продукта" term as a subcategory of "Категория на продукта"
• See error

This is what WordPress attempted to insert into the database:

(
    [name] => Категория на продукта
    [slug] => %d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d1%8f-%d0%bd%d0%b0-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0-%d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d1%8f-%d0%bd%d0%b0-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0
    [term_group] => 0
)

The slug is too long. We either need error checking for this, or we need to truncate the slug length to avoid the issue and keep slug < 200 chars.

[mikejolley]

@subrataemfluence just a note on that diff, whilst it makes sense in technical terms, a user using cyrillic probably won't understand the length issue as they only typed 21.

I wonder if a better slug generation is needed here, or a fallback.

[subrataemfluence]

While generating a slug, option is always there to truncate (let's call this the fallback) it to the maximum allowed characters.

Technically it sounds ok, but not sure whether its a good idea from SEO perspective!

When auto-generated truncate is probably the best option, apart from throwing an error and stopping it from getting added into the database.

Any suggestion on better slug generation would be nice!

[mikejolley]

Any suggestion on better slug generation would be nice!

If it cannot prefix the parent term due to length, could it not just append -2, -3 etc. Obviously it's not ideal, but it's better than the error message, and the end-user can edit it if needed manually.

[callumbw95]

Hi All,
I have taken a look at this now that this with the latest version of WordPress and It appears there is a string length limit in place now to stop this from erroring when inserting into the database. It no longer throughs up an error message as before, but instead just truncates behind the scenes without any notification that it has done this.
In regards to the string length due to the encoding, this still appears to be prevalent, but I really cannot think of a solution to get around this issue, and I am not sure that there will be one.
As the main complaint from this ticket looks to be resolved in the latest releases, I believe we can close this ticket down?

[mindctrl]

Term insert error when length exceeded.

[mindctrl]

Hi all, I'm able to reproduce the issue using the same category names in the ticket description, and the error is still generic.

…db insert errors (Ticket #46010)

This PR adds a truncation check to ensure that term slugs longer than 200 characters are properly shortened before insertion.
This prevents database errors that occur when creating categories, tags, or other terms with very long names.

Trac ticket: https://core.trac.wordpress.org/ticket/46010

[nikunjraj29]

The patch ensures that: Auto‑generated slugs are properly truncated to fit within the database’s maximum length. Term insertion no longer fails due to long slugs. Identifying and fixing a core bug that directly impacts database integrity. Contributing a clean, minimal patch that’s easy for reviewers to test and merge.

[nikunjraj29]

Uploading refreshed patch: - Cleans up unrelated file changes - Keeps only taxonomy.php modification for truncating slugs over 200 chars This replaces the previous patch attachment. Keywords: has-patch needs-testing

[mindctrl]

If taking a truncating approach, I wonder if the logic should go inside of wp_unique_term_slug() instead, which would also cover wp_update_term().