Slugs für Archive benutzerdefinierter Beitragstypen übersetzen

Wenn Sie benutzerdefinierte Beitragstypen manuell registrieren, ermöglicht WordPress es Ihnen, einen eigenen Archiv-Slug festzulegen. Wie Sie dies konfigurieren, bestimmt, ob der Slug in Ihre Sekundärsprache übersetzt wird oder nicht.

Wenn Sie benutzerdefinierte Beitragstypen manuell registrieren, können Sie mithilfe der Funktion has_archive einen eigenen Archiv-Slug festlegen.

WPML ermöglicht es, has_archive auf einen String zu setzen. Wenn der String-Wert jedoch auf etwas anderes als rewrite['slug'], gesetzt wird oder der Namens-Slug des benutzerdefinierten Beitragstyps nicht festgelegt ist, ist der Archiv-Slug nicht übersetzbar.

Einen übersetzbaren Slug festlegen

In diesem Code-Beispiel setzen wir 'has_archive' => true. Unter der Annahme, dass der Slug book im Spanischen mit libro übersetzt wurde, lauten die Archiv-Links wie folgt:

• Englisch (Standardsprache): http://mydomain.tld/book/


• Spanisch (Sekundärsprache): http://mydomain.tld/es/libro/

	 	 
add_action( 'init', 'create_post_type' );	 	 
function create_post_type() {	 	 
   register_post_type( 'book',	 	 
      array(	 	 
         'labels' => array(	 	 
            'name' => __( 'Books', 'textdomain' ),	 	 
            'singular_name' => __( 'Book', 'textdomain' )	 	 
         ),	 	 
         'public' => true,	 	 
         'has_archive' => true,	 	 
         'publicly_queryable' => true,	 	 
         'exclude_from_search' => false,	 	 
         'show_ui' => true,	 	 
         'show_in_menu' => true,	 	 
         'query_var' => true,	 	 
         'rewrite' => array('slug' => 'book'),	 	 
         'supports' => array('title','editor', 'custom-fields','thumbnail')	 	 
      )	 	 
   );	 	 
}	 	 

Den gleichen Slug in der Standardsprache und der Sekundärsprache festlegen

In diesem Code-Beispiel legen wir einen spezifischen String für den Parameter 'has_archive' => 'my-books' fest. Nun lauten die Archiv-Links wie folgt:

• Englisch (Standardsprache): http://mydomain.tld/my-books/
• Spanisch (Sekundärsprache): http://mydomain.tld/es/my-books/

	 	 
add_action( 'init', 'create_post_type' );	 	 
function create_post_type() {	 	 
   register_post_type( 'book',	 	 
      array(	 	 
         'labels' => array(	 	 
            'name' => __( 'Books', 'textdomain' ),	 	 
            'singular_name' => __( 'Book', 'textdomain' )	 	 
         ),	 	 
         'public' => true,	 	 
         'has_archive' => 'my-books', // Do not use the gettext functions for this parameter	 	 
         'publicly_queryable' => true,	 	 
         'exclude_from_search' => false,	 	 
         'show_ui' => true,	 	 
         'show_in_menu' => true,	 	 
         'query_var' => true,	 	 
         'rewrite' => array('slug' => 'book'),	 	 
         'supports' => array('title','editor', 'custom-fields','thumbnail')	 	 
      )	 	 
   );	 	 
}	 	 

Fehlerbehebung bei anpassbaren Slugs

Einige Themes und Plugins ermöglichen es dem Website-Administrator, eigene Slugs für ihre benutzerdefinierten Beitragstypen und benutzerdefinierten Taxonomien festzulegen.

Wenn Ihre übersetzten benutzerdefinierten Slugs einen 404-Fehler zurückgeben, überprüfen Sie bitte Folgendes:

• Der benutzerdefinierte Typ sollte bei allen Anfragen immer mit demselben Slug registriert werden: pro Sprache, Frontend, Backend, AJAX, Heartbeat usw. Daher sollte sich in 'rewrite' => [ 'slug' => $my_custom_slug ], der Wert von $my_custom_slug nicht von einer Anfrage zur anderen ändern, selbst wenn er aus einer Option (oder einer anderen benutzerdefinierten Einstellung) stammt.


• WPML unterstützt nur die Übersetzung benutzerdefinierter Slugs (wenn der benutzerdefinierte Typ registriert wird), aber keine benutzerdefinierte Permalink-Struktur.


• Wenn der benutzerdefinierte Slug als Option gespeichert wird, sollte er nicht als admin-texts in der Datei wpml-config.xml registriert werden.


• Nach dem Aktualisieren des Werts eines benutzerdefinierten Slugs sollte das Theme/Plugin auch die Rewrite-Regeln leeren (durch Aufruf von flush_rewrite_rules();).