Opened 8 years ago
Closed 2 years ago
#40298 closed defect (bug) (duplicate)
Translated custom post type archive slug is in user language, not site language
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | 4.7.3 |
| Component: | I18N | Keywords: | |
| Focuses: | template | Cc: |
Description
Tried to do a search, got "OperationalError: (1040, 'Too many connections')" so: sorry if this is a dupe.
I have a custom post type "event". In my register_post_type call I have
'slug' => _x( 'events', 'events slug', 'domain' ),
In my Dutch translation file I translate 'events' as 'agenda'.
My user has the interface language set to English.
When I change the site language from English to Dutch and flush the permalinks my single events all have the correct slug ("/agenda/single-post-slug").
However the custom post type archive remains available under the old slug "/events/". The new slug "/agenda/" results in a 404.
The "solution" is to change the user account's interface language to Dutch and flush the permalinks. Now the custom post type archive is available under the slug "/agenda/".
This seems wrong and could lead to inadvertent changes of the URL for a cpt-archive. I would expect the cpt-archive to follow the site language, just like the single posts do.
IMHO, you must not internationalize CPT slugs bases. WordPress has no slug base for CPT but it has for taxonomies (categories, tags and post formats), and you'll see that they are not internationalized. See https://github.com/WordPress/WordPress/blob/4.7.3/wp-includes/taxonomy.php#L38-L53
The reason is exactly the kind of issue you are running in. A CPT slug base must never change on your site. If you are writing a plugin, the translations may not be available first. So the slug base will be 'events'? Then at some point, the translations will become available and the slug base will become 'translated_events' changing all the corresponding urls.
If you want to allow the customization of your custom post type slug base, the best is to do as done by WordPress for categories and tags and provide an option. If this is for a unique project, you can just hardcode it in your language.