CPTUI allow non unique slug

[sebastienserre]

Hello,

I'm Sébastien from Polylang (support) team.

We have several users/customers in common which fail in the same issue and I think you should keep them from it.
In our side, we will think about a behavior to prevent Editor fatal error.

Today, each admin can create CPT and Taxonomy thanks to CPTUI, and they're allowed to create CPT and Taxonomy with the same slug. More over, they can use already existing slug.

It's problematic as the Rest Api used by the editor has a problem to retrieve correctly the content by choosing the wrong content due to several contents with the same slug.

In Polylang Case, it retrieves content without translation for a translatable content... and it produces a JS fatal error in the editor. We'll manage it to prevent bad experiences.

To avoid having this. Should it be possible to check on CPT and Taxo creation if the slug chosen by the user is available (Not already in use and not in the WordPress reserved terms) ?

Thank you very much

[tw2113]

Hi Sébastien,

Definitely open to ideas and how we could make this even more robust, but I wanted to point out quick a few things we have in place for what we're already doing.

For example, here's where were already checking for existing post types. First reserved ones, followed by both public and private ones registered by other plugins/developers
https://github.com/WebDevStudios/custom-post-type-ui/blob/master/inc/post-types.php#L1876

We're also checking PAGES for conflicting slugs because these can cause conflicts at the archive URL level, from our experiences:
https://github.com/WebDevStudios/custom-post-type-ui/blob/master/inc/post-types.php#L1914

However, we're not checking for TOO much else, but we do have this filter in place for other developers to use if they wanted to, to get their own values put in place for whatever reason.
https://github.com/WebDevStudios/custom-post-type-ui/blob/master/inc/post-types.php#L1817-L1826

Perhaps this filter could be utilized in some way that we're not already handling on our own. That said, open to merging in solutions if they look solid, instead of just leaving on the shoulders of your specific use cases.