Slug et traduction pour les Custom Post Types WordPress

Ici $database_options_group renvoie au nom du groupe d’options en base de données et $page au slug de la page du formulaire. Nous récupérons ce slug avec la fonction PHP basename( __FILE__, ‘.php’ ), en amputant le nom de notre fichier de son extension :

	/**
	 * Generic CPT Option Page
	 */
	public function generic_cpt_options_page()
	{
?>
	<div class="wrap">
		<h1><?php _e( 'Generic CPT Options', 'jst' ) ?></h1>		
		<form action="options.php" method="post">
			<?php settings_fields( 'jst_generic_cpt' ); ?>
			<?php do_settings_sections( basename(__FILE__, '.php') ); ?>
			<input type="submit" class="button button-primary" value="<?php _e( "Save", "jst" ); ?>" />
		</form>
	</div>
<?php
	}

API Settings : enregistrement des paramètres

Cette API nous simplifie beaucoup la vie. Elle nous guide dans le processus d’assignation des options aux sections et champs de formulaire. Nous enregistrons le groupe d’options dans l’API avec la méthode register_settings()

Enregistrement des settings du formulaire

La signature proposée par le codex peut être un peu déroutante :

code>
	register_setting( $option_group, $option_name, $sanitize_callback )

Sachez qu’en général vous assignerez aux 2 premiers arguments le nom de l’option défini avant l’instanciation de la classe, en clair il devra correspondre à l’enregistrement de nos options en base de données.<br ?–> Pour appeler l’enregistrement des settings, on utilise le hook « admin_init » depuis le constructeur :

	/**
	 * Section et champs settings
	 */
	add_action( 'admin_init', array( $this, 'register_settings' ) );

Puis comme d’habitude nous créons la méthode de classe correspondante :

	/**
	 * Register Sections & Fields Settings
	 */
	public function register_settings()
	{
	 	register_setting(
			'jst_generic_cpt',
			'jst_generic_cpt',
			array( $this, 'sanitize_jst_generic_cpt' )
		);
	);

À ce stade, il nous faut impérativement construire notre fonction d’assainissement (sanitization dans le texte) des entrées utilisateur pour ces options. Cela consiste principalement à filtrer les données attendues correspondant à nos champs et à les renvoyer filtrées. On se contentera ici d’utiliser sanitize_text_field(), mais il faudrait quand même en profiter pour tout mettre en minuscule, remplacer les lettres accentuées et mettre des tirets à la place des éventuels espaces :

	/**
	 * Sanitize jST Generic CPT Options
	 */
	public function sanitize_jst_generic_cpt( $inputs )
	{
		$valid[ 'slug' ] = sanitize_text_field( $inputs[ 'slug' ] );
		return $inputs;
	}

Définition d’une section de formulaire et son champ associé

Revenons à notre méthode register_settings(). Nous y définissons maintenant une section pour notre page d’options ainsi qu’une fonction de rappel destinée à afficher un descriptif ou une aide contextuelle. Le premier argument est l’ID de la section et sera utilisé par la déclaration des champs qui lui seront associés. Les arguments suivant dans la signature sont le titre, le callback de description et le slug de la page :

		/**
		 * i18n Settings Section
		 */
		add_settings_section(
			'jst_generic_cpt_i18n',
			__( 'Genric CPT i18n', 'jst'),
			array( $this, 'jst_cpt_i18n_description'),
			basename( __FILE__, '.php' )
		);

Nous définirons plus tard une fonction simple affichant notre paragraphe d’aide pour la section. Ajoutons directement un champ « slug » pour « jst_generic_cpt_i18n ». La méthode add_settings_field() possède une signature assez proche de sa cousine servant à initialiser la section. Deux différences : le callback renvoie ici à la méthode de construction du champ (nous la voyons juste après), et le dernier argument se rapporte à l’ID de la section précédemment définie. Il existe en fait un cinquième argument exploitable servant à passer des données au callback mais nous ne l’utilisons pas ici :

		/**
		 * Slug Field
		 */
		add_settings_field(
			'jst_generic_cpt_slug',
			__( 'Slug', 'jst' ),
			array( $this, 'jst_cpt_slug' ),
			basename( __FILE__, '.php' ),
			'jst_generic_cpt_i18n'
		);
	}

Affichage d’une aide contextuelle pour la section du formulaire de gestion d’options

add_settings_section() définit un callback. La fonction associée sert à donner des conseils et avertissements à l’utilisateur :

	/**
	 * JST Generic CPT i18n Section
	 */
	public function jst_cpt_i18n_description()
	{
		echo '<p>'.__( 'More than just a translation, provide all menu items, names and slug for your CPT.' ).'</p>';
	}

Affichage du champ input associé à la section

L’idée est de récupérer les options stockées dans notre propriété de classe $opts et d’n extraire la valeur du champ à afficher. La définition des ces options à l’activation du plugin nous garantie que nous trouverons un tableau et notre fonction de sanitisation force la présence de l’index dans le tableau :

	/**
	 * Jst Generic CPT Slug Field
	 */
	public function jst_cpt_slug()
	{
		/**
		 * Récupération des options
		 */
		$opts = $this->opts;
		$slug = isset( $opts[ 'slug' ] ) ? esc_attr( $opts[ 'slug' ] ) : '';
		echo '<input name="jst_generic_cpt[slug]" type="text" value="'.$slug.'" />';
	}

Le détail à remarquer est l’utilisation de esc_attr() qui nous permet d’éviter les problèmes d’affichage des caractères « <« , « > » et « & ». Bon, nous voilà avec une belle page d’options, mais en l’état elle ne sert pas à grand-chose … Enregistrons un custom post type avec notre slug dynamique …

Enregistrement du custom post type avec traduction du slug

Je vous l’ai dit, l’avantage avec les classes, c’est que les propriétés sont accessibles partout. Nous nous servons du hook « init » dans le constructeur pour appeler la méthode d’enregistrement du type de contenu personnalisé. On va d’ailleurs élargir un peu la méthode pour la préparer à la réception d’éventuels types de contenus additionnels. Dans le constructeur :

	add_action( 'init', array( $this, 'register_post_types' ) );

Nous y sommes, notre méthode de classe register_post_types() définit un tableau associatif de custom post types. Les indices correspondent à l’identifiant du contenu, les valeurs à un tableau d’options définissant les noms singuliers et pluriels, les éléments supportés par les posts, une icône et le slug si important pour la définition de nos URL. L’important est ici l’option « slug » du tableau d’option associé au type de contenu (dont on récupère la valeur depuis notre propriété de classe $opts) et son utilisation lors de l’enregistrement de celui-ci. On utilisera à cette fin l’option (l’index) « rewrite » du tableau d’arguments passé en deuxième paramètre de register_post_type. Les éléments libellés correspondants au menu d’administration de WordPress,on peut se contenter d’utiliser la fonction de traduction classique __() avec sprintf() : Enfin, dès l’enregistrement des custom post types dans la boucle foreach, nous appelons flush_rewrite_rules() pour éviter à l’utilisateur d’avoir à resauvegarder manuellement ses permaliens via le menu du même nom de l’interface :

	/**
	  * Register Generic CPT & others
	  */
	 public function register_post_types()
	{
		$types = array(
			'generic-cpt' => array(
				'menu_title'		=> 'GCPT',
				'singular'		=> 'Generic Custom Post',
				'plural'		=> 'Generic Custom Posts',
				'supports'		=> array( 'thumbnails', 'title', 'editor', 'excerpt', 'post-format' ),
				'icon'			=> 'dashicons-groups',
				'slug'			=> $this->opts[ 'slug' ]
			)
			/**
			 * Les autres éventuels CPT à enregistrer
			 */
		);
		$counter  = 0;
		foreach( $types as $type=>$args )
		{
			$labels = array(
				'name'			=> $args[ 'menu_title' ],
				'singular_name'		=> $args[ 'singular' ],
				'add_new'		=> sprintf( __( 'Add new %s', 'jst' ), $args[ 'singular' ] ),
				'add_new_item'		=> sprintf( __( 'Add new %s', 'jst' ), $args[ 'singular' ] ),
				'edit_item'		=> sprintf( __( 'Edit %', 'jst' ), $args[ 'singular' ] ),
				'all_items'		=> sprintf( __( 'All %s', 'jst' ), $args[ 'plural' ] ),
				'view_item'		=> sprintf( __( 'View %', 'jst' ), $args[ 'singular' ] ),
				'search_items'		=> sprintf( __( 'Search %s', 'jst' ), $args[ 'plural' ] ),
				'no_items_found'	=> sprintf( __( 'No %s found', 'jst' ), $args[ 'plural' ] ),
				'no_items_found_in_trash' => sprintf( __( 'No %s found in trash', 'jst' ), $args[ 'plural' ] ),
				'menu_name'		=> $args[ 'menu_title' ]
			);
			register_post_type( $type, array(
				'labels'		=> $labels,
				'public'		=> true,
				'publicly_queryable'	=> true,
				'has_archive'		=> true,
				'supports'		=> $args[ 'supports' ],
				'capability_type'	=> 'post',
				'rewrite'		=> array( 'with_front' => false, 'slug' => $args[ 'slug' ] ),
				'menu_icon'		=> $args[ 'icon' ],
				'menu_position'		=> 20 + $counter
			) );
			$counter ++;
		}
		flush_rewrite_rules();
	}

Nombres d’options présentées ici ne sont que des piqûres de rappel. Notons toutefois que bien que le codex nous dise explicitement qu’il vaut mieux ne pas appeler flush_rewrite_rules() depuis le hook « init », réaliser ce flush en fin de boucle est le seul moyen d’accéder directement à la page du post type créé antérieurement à une modification de slug. Tentez de supprimer cette ligne et vous aurez droit à une erreur 404.

Flush des règles de réécriture à l’activation et la désactivation du plugin

Enfin nous garantissons une bonne intégration du mécanisme en appelant à nouveau le flush depuis les callbacks d’activation et de désactivation :

	/**
	 * Activation
	 */
	static public function activation()
	{
		// ...
		flush_rewrite_rules();
	}

	/**
	 * Deactivation
	 */
	static public function deactivation()
	{
		// ...
		flush_rewrite_rules();
	}

Traduction des slugs WordPress : des custom post types flexibles

Vous voilà donc en présence d’un plugin 100% fonctionnel vous autorisant une création de contenus à la fois personnalisés et génériques. Cool non ? Pensez donc à proposer une fonctionnalité de traduction des slugs aux utilisateurs de vos custom post types, vous leur donnerez une dose de flexibilité et la capacité d’offrir des URL pertinentes aux moteurs de recherche.

Vous souhaitez vous documenter ? lisez les pages du codex :

• L’API Settings de WordPress
• L’API Options de WordPress