Italiano
Română
РусскийTipos de Posts Personalizados: Cómo eliminar el editor (meta box)
Me pregunto cómo puedo eliminar el editor de posts (visual + HTML). Intenté no registrar el soporte para el tipo de post, pero sigue apareciendo (desregistrar funciona bien con cualquier otra meta box por defecto en la pantalla de edición). También intenté desregistrarlo con remove_meta_box, lo cual tampoco funcionó (funciona para todo excepto para la meta box del título). Tal vez me esté perdiendo algo. Ya busqué en la web y no encontré nada. Espero que alguien pueda ayudarme. ¡Gracias!
PD: Me gustaría una solución para deshabilitar el campo de título también, pero eso es secundario (no registrarlo con el tipo de post funciona).
(La versión de WordPress es 3.0.4.)
Proporcionar un array vacío en 'supports' en la declaración del tipo de post debería eliminar el editor y el título, junto con todas las demás cajas predeterminadas en la página de edición del post.
$supports = array ('');
$args = array(
'label' => 'personas',
'supports' => $supports,
'hierarchical' => false,
'public' => true,
'rewrite' => true
);
register_post_type( 'personas', $args);
Resultado:
Rellena 'supports' con los elementos que quieras que aparezcan, como trackbacks, comentarios, etc. O simplemente déjalo vacío para dejar la página vacía, excepto por la caja que te permite guardar tus posts. Asegúrate de visitar aquí si también quieres deshacerte de las metaboxes de taxonomía jerárquicas.
Hasta ahora, gracias. Mi problema es que no puedo configurar todo como vacío. Escribí tres clases para acelerar la generación de tipos de posts personalizados, taxonomías personalizadas y etiquetas. Tienen valores predeterminados. En el caso de los tipos de posts personalizados, es simplemente todo. Pero necesito desregistrar algunas cajas para tipos de posts específicos. Y para uno necesito desregistrar también la caja del editor.
kaiser
Me interesa saber a qué te refieres con configurar todo como vacío. Si quieres eliminar el editor, simplemente no incluyas 'editor' en el array 'supports' cuando crees el tipo de post en tu clase.
Manny Fleurmond
@kaiser si son tus propias clases, ¿cuál es el problema? Haz que las clases lo manejen...
Rarst
@Rarst: Es solo una base que hace lo siguiente: registrar tipos de posts y taxonomías desde un array y ofrece un filtro para $labels y $args (por defecto y específicos). La clase de términos solo genera términos no eliminables que se actualizan y asignan desde un array. Los meta boxes pueden hacerse fácilmente sin la clase y no tendría sentido para mí integrarlos. Las clases solo están ahí para ahorrarme tiempo y evitar que los clientes eliminen términos que el sistema necesita. Pero gracias por mirarlo. Tu ayuda es muy apreciada (de nuevo) :)
kaiser
@Manny Fleurmond: Reutilizo las clases en diferentes configuraciones (parte de mi framework). No quiero cambiar el comportamiento por defecto de "soporta todo". Tengo filtros para cambiar eso para todos los tipos de posts o solo para algunos específicos (sobrescribir o añadir a $args). Funcionan para todo, pero no para el editor. También probé la función remove_meta_box sin éxito (para el meta box del título también).
kaiser
¡SOLUCIÓN! Siempre pensé que esto solo servía para eliminar, por ejemplo, miniaturas o nav_menu mediante un tema hijo. ¡Muchas gracias!
kaiser
Ay, se me pasó eso. Buen punto, pasar un array vacío se evaluará como vacío... Pasar valores vacíos siempre es un lío, es contraintuitivo porque se trata como predeterminado en lugar de como nada. :(
Rarst
@Rarst: Creo que también funcionaría si pasas un nombre de característica ficticio. Solo es una clave de array, así que no importa si se insertan datos ficticios. Yo una vez usé 0.1 en lugar de 0 para un parámetro para pasar la verificación empty().
Jan Fabry
@Jan Fabry sí, no es la primera vez que piso la mina de empty(). Como mencioné arriba - altamente contraintuitivo.
Rarst
Hmm. No está funcionando con claves y por eso creo que los "valores dummy" podrían convertirse en otra "mina" al actualizar más tarde (intenta encontrar el valor incorrecto). De todos modos: ¡muchas gracias a ambos! :)
Editar: sería útil si los valores no solo estuvieran allí, sino que fueran pares clave/valor. Ej. 'support' => array('thumbnail' => true, 'editor' => false);
kaiser
Como mencioné anteriormente, escribí tres clases y por lo tanto no puedo cambiar a un plugin. En realidad, ni siquiera consideraría usar un plugin de todos modos. Los plugins son (en mi opinión) para desarrollo o cosas fácilmente intercambiables como formularios de comentarios y no para elementos centrales como tipos de publicación o taxonomías. ¡Gracias de todos modos!
kaiser
En realidad, los plugins pueden personalizar casi cualquier cosa de WordPress, incluyendo tipos de publicación personalizados. Actualmente estoy creando un plugin que crea numerosos tipos de publicación, sus metaboxes y varios campos personalizados.
Manny Fleurmond
@Manny Fleurmond: Si vas a compartirlo, por favor envíame un enlace. Todavía estoy pensando en quizás-quizás escribir una rutina para meta-boxes avanzadas en mis clases también.
kaiser
Gracias por tu respuesta, pero esto (a) lo haría no removible ya que no está registrado con la API de Dependencias y (b) lo haría accesible para personas que saben cómo usar las herramientas de desarrollador del navegador.
kaiser