Bien que la fonctionnalité de paramètres persistants dans le noyau soit agréable, cela peut prendre un certain temps avant d'être réellement accepté. WordPress 3.5 est encore assez loin.
Augmentons donc le $_REQUEST
tableau global à la place.
add_action( 'load-edit.php', 'wpse34956_force_excerpt' );
function wpse34956_force_excerpt() {
$_REQUEST['mode'] = 'excerpt';
}
Cela verrouillera les modes, forçant le excerpt
mode tout le temps, nous allons donc laisser l'utilisateur décider mais le garder persistant en utilisant les métadonnées de l'utilisateur:
add_action( 'load-edit.php', 'wpse34956_persistent_posts_list_mode' );
function wpse34956_persistent_posts_list_mode() {
if ( isset( $_REQUEST['mode'] ) ) {
// save the list mode
update_user_meta( get_current_user_id(), 'posts_list_mode', $_REQUEST['mode'] );
return;
}
// retrieve the list mode
if ( $mode = get_user_meta( get_current_user_id(), 'posts_list_mode', true ) )
$_REQUEST['mode'] = $mode;
}
Vous pouvez encore interpoler post_type
en tout en tenant compte de la $_GET['post_type']
variable lorsqu'elle est disponible.
add_action( 'load-edit.php', 'wpse34956_persistent_posts_list_mode' );
function wpse34956_persistent_posts_list_mode() {
// take into account post types that support excerpts
$post_type = isset( $_GET['post_type'] ) ? $_GET['post_type'] : '';
if ( $post_type && !post_type_supports( $post_type, 'excerpt' ) )
return; // don't care
if ( isset( $_REQUEST['mode'] ) ) {
// save the list mode
update_user_meta( get_current_user_id(), 'posts_list_mode' . $post_type, $_REQUEST['mode'] );
return;
}
// retrieve the list mode
if ( $mode = get_user_meta( get_current_user_id(), 'posts_list_mode' . $post_type, true ) )
$_REQUEST['mode'] = $mode;
}
Alto! Mode liste persistante par type de publication par utilisateur, pas de piratage.
L'écran de post-visualisation bascule de la vue de liste à la vue d'extraits en fonction de la valeur du paramètre "mode" dans la chaîne de requête. Si le paramètre "mode" n'est pas défini, WordPress utilise par défaut la vue liste.
Malheureusement, ce paramètre n'est pas filtrable, il n'y a donc pas de moyen facile de le contrôler par programme.
Je vais donc faire quelque chose que je ne fais jamais ... Je vais vous dire comment pirater Core pour que cela fonctionne ...
Ajout d'un filtre
Ouvrez
/wp-admin/includes/class-wp-posts-list-table.php
et trouvez laprepare_items()
méthode (autour de la ligne 81).Sur la ligne 99, WordPress vérifie si le paramètre "mode" a été défini ou non dans la demande et l'utilise pour définir la
$mode
variable globale :Nous allons modifier cette ligne pour filtrer le paramètre par défaut. Changez cette ligne en:
Maintenant, allez dans le
functions.php
fichier de votre thème et ajoutez le code suivant:Cela se connectera au filtre et renverra le mode extrait par défaut.
Étant donné que ma règle personnelle sur le piratage de Core nécessite que tous les hacks soient redirigés vers le projet (de cette façon, ils peuvent être intégrés dans Core et ne plus être considérés comme un hack), j'ai ouvert un ticket Trac pour cette amélioration et soumis le code ci-dessus comme un patch. Veuillez peser sur le ticket afin qu'il puisse entrer dans le noyau pour la 3.5 (nous sommes trop tard dans le cycle pour la 3.4, mais nous pouvons essayer de le faire passer pour la prochaine version).
la source
$_REQUEST
globaladd_action( 'edit.php', ... )
et ainsi de suite, en attendant que le noyau adopte le patch / la proposition?$_REQUEST
objet moi-même. N'hésitez pas à poster une autre réponse décrivant comment cela pourrait être fait.D'accord, donc peu de temps après avoir mis une prime, j'ai trouvé la solution suivante. C'est le comportement par défaut dans tous les sens, sauf qu'il sélectionne la vue d'extrait pour le type de publication que vous voulez (au lieu de la vue de liste par défaut).
REMARQUE: je recommande l'approche de Soulseekah, si vous ne voulez pas qu'il se souvienne du choix de l'utilisateur, vous pouvez incorporer un peu mon code avec son code. NOTE 2: Si / quand le patch d'EAMann fait partie du noyau, sa méthode serait évidemment la meilleure car elle ne vous obligerait pas à parcourir le long chemin. Je n'aime pas ça pour le moment car vous devez éditer les fichiers principaux.
la source
paged
n'est pas pris en compte (pagination) + l'utilisationwp_redirect
au lieu d'en-têtes bruts pourrait être un peu plus "propre", et je ne suis pas sûr de l'efficacité de la redirection. A part ça, ça a l'air intéressant. Il se$_GET['post_type']
peut également que ce paramètre ne soit pas défini, ce qui entraîne un avertissement si les erreurs sont activées. +1 pour l'effort et la patience. Je ne savais pas que la question était si ancienne.$_GET
variables. En ce qui concerne$_GET['post_type']
, honnêtement, cela ne m'a pas trop dérangé car j'ai seulement exigé que ce soit pour un type de message personnalisé, qui serait toujours là. Évidemment, cela peut être omis. @EAMann, vous avez raison, cependant, c'était la meilleure solution que j'ai pu trouver. J'ai essayé de régler manuellement les$_GET
paramètres, en espérant qu'il serait réglé AVANT qu'il ne soit lu, mais cela ne semblait pas être le cas.