WordPress por defecto asigna dos taxonomías a nuestras entradas: las clásicas categorías y etiquetas. El tema es que no siempre las necesitamos y mi filosofía de trabajo es que si algo no es necesario para el cliente mejor quitarlo para evitar posibles dolores de cabeza.
Remover estas taxonomías de las entradas es muy sencillo, basta con agregar el siguiente código al functions.php de nuestro tema o bien a un fichero de configuración de un plugin.
/**
* Esta función quita las etiquetas de las entradas.
*/
function mgwp_unregister_tags() {
unregister_taxonomy_for_object_type( 'post_tag', 'post' );
}
add_action( 'init', 'mgwp_unregister_tags' );
/**
* Esta función quita las categorías de las entradas.
*/
function mgwp_unregister_categories() {
unregister_taxonomy_for_object_type( 'category', 'post' );
}
add_action( 'init', 'mgwp_unregister_categories' );
Como puedes ver la función unregister_taxonomy_for_object_type nos permite quitar cualquier taxonomía de cualquier tipo de post.
En caso de que necesites quitar las dos taxonomías a la vez, une las dos líneas en el mismo action ⬇️ :
/**
* Esta función quita las categorías y las etiquetas de las entradas.
*/
function mgwp_unregister_categories() {
unregister_taxonomy_for_object_type( 'post_tag', 'post' );
unregister_taxonomy_for_object_type( 'category', 'post' );
}
add_action( 'init', 'mgwp_unregister_categories' );
La última versión 5.5 de WordPress introdujo la creación de un Sitemap XML por defecto en el Core aunque la gran mayoría de los sitios Webs utilizan plugins como Yoast que ya lo están generado siguiendo sus configuraciones.
Si vas a utilizar este tipo de plugins, lo ideal sería que desactives esta nueva funcionalidad con el siguiente y simple código con el fin de optimizar los recursos del servidor:
El nuevo editor de WordPress, Gutenberg, viene con un gran conjunto de bloques que no siempre necesitaremos para todos nuestros tipos de entradas (Custom Post Types).
Para estos casos lo mejor será desactivarlo por completo y reutilizar el ya conocido editor clásico (el WYSIWYG).
¿Cómo puedes hacerlo? Muy simple, a través de plugins o bien implementando un código muy sencillo que te muestro a continuación.
Con el plugin NO Gutenberg
Plugin No Gutenberg de Fernando Tellado
El gran Fernando Tellado tiene su propio plugin para desactivar Gutenberg de raíz. Es un plugin muy simple que no agrega ningún menú pero que cumple con su propósito, desactivar Gutenberg por completo.
Podremos desactivar Gutenberg por completo con tan solo una línea de código.
// Este filtro desactiva Gutenberg por completo, al igual que el plugin de Fernando Tellado.
add_filter( 'use_block_editor_for_post', '__return_false' );
O bien desactivarlo condicionalmente reutilizando los parámetros que envía el filtro.
// Desactiva Gutenberg solo para un CPT determinado.
function gutenberg_segun_cpt( $usa_gutenberg, $post ){
if( $post->post_type === 'el-nombre-de-tu-custom-post-type' ) {
$usa_gutenberg = false;
}
return $usa_gutenberg;
}
add_filter( 'use_block_editor_for_post', 'gutenberg_segun_cpt', 10, 2 );
Hay ciertas tareas informáticas que deben ser ejecutadas cada cierto período de tiempo (backups automáticos, borrado de SPAM, cobro de membresías, etc). Para ello solemos utilizar un comando de Unix llamado CRON el cual ejecuta actividades y procesos en segundo plano (servicio daemon) mediante una sintaxis bastante rara de asteriscos y números.
WordPress también necesita ejecutar tareas con una cierta cronología aunque no puede usar el comando CRON de Unix. Como tecnología abierta debe ser independiente de sistema operativos o de configuraciones específicas de servidor. Para dar una respuesta a esta situación se creó el bendito wp-cron.php, un fichero PHP que se activa con cada visita a la web y que dispara un administrador de tareas con su correspondiente control de tiempos.
Si bien es una solución muy inteligente hay que tener cierto cuidado porque:
Puede que no tengamos ninguna visita y acciones que debían ser ejecutadas no se ejecutan.
O bien puede que tengamos muchas visitas y el procesador del servidor se vea sobrecargado con demasiadas peticiones al fichero wp-cron.php
Cuando sucede el segundo caso, es muy probable que recibamos un bonito email de nuestro proveedor de hosting con un mensaje que dice más o menos así:
«Hola, <fulanito de tal>.
Su cuenta <nombre de su cuenta> ha alcanzado el 80% del uso diario permitido de 20000 de CPU segundos por cuenta. Tenga en cuenta que una vez le dé el 100% de los segundos de CPU diario permitido, su servicio web estará limitado por el día natural. El límite de servicio web significa que puede estar teniendo problemas para acceder a su sitio web.«
Gracias a estos problemas, hemos escuchado por ahí que «el CRON de WordPress es más falso que los Milli Vanilli«.
¿Qué podemos hacer entonces? Pues muy simple, en primer lugar vamos a desactivar el «CRON» de WordPress definiendo la siguiente constante en el fichero wp-config.php.
define ('DISABLE_WP_CRON', true);
Acto seguido solicitamos o configuramos por nuestra cuenta un CRON (del verdadero, de los de sin comillas) en nuestro proveedor de hosting para que ejecute este fichero en un intervalo de 30 minutos o bien una hora (a menos que tengamos una necesidad específica con esta configuración tendríamos que ir de lujo).
Cada proveedor de hosting tiene su propia aplicación para configurar tareas de CRON y variará según el caso. En la siguiente imagen podemos ver cómo lo implementa SiteGround y Host Europe respectivamente.
Configuradores de tareas de CRON de SiteGround y Host Europe
Vemos que en el primer campo tenemos un selector donde podemos elegir valores habituales y que autocompletan los demás campos:
Una vez por minuto ( * * * * * )
Una vez cada 5 minutos ( */5 * * * * )
Una vez cada 30 minutos ( 0,30 * * * * )
Una vez por hora ( 0 * * * * )
Dos veces al día ( 0 0,12 * * * )
Una vez al día ( 0 0 * * * )
Una vez por semana ( 0 0 * * 0 )
El 1 y el 15 del mes ( 0 0 1,15 * * )
Una vez al mes ( 0 0 1 * * )
Una vez por año ( 0 0 1 1 * )
En el campo comando debemos pegar la siguiente línea:
/usr/local/bin/php /home/public_html/wp-cron.php
Esta línea de código ejecuta, utilizando el comando PHP, el fichero wp-cron.php de WordPress que ejecutará a su vez las tareas que tenga asociada siempre y cuando se respete la cronología de las mismas.
Este comando puede variar ya que algunos servidores de hosting pueden tener el comando php en el PATH o bien la ruta hacia el fichero wp-cron.php puede ser otra. Pero más o menos se hacen a la idea, si tienen duda lo mejor es ponerse en contacto directamente con vuestro proveedor. Gracias José Conti por esta aclaración 😉.
Conclusión
Con estos simples pasos vamos a asegurarnos que nuestras tareas CRON se ejecutan y también vamos a mantener una larga relación de amistad con nuestros proveedores de hosting. Verdadera, no como la mentira de los Milli Vanilli.
A la hora de moldear el administrador de WordPress para mis clientes sigo la premisa de «cuanto menos mejor«. Y uno de esos ejemplos es el «Escritorio de WordPress», que viene con noticias, enlaces a las entradas, páginas, próximas Meetups, actividad etc. El usuario fácilmente puede distraerse y empezar a pinchar enlaces, inclusive accediendo a zonas del administrador a las que no tendría que acceder.
Solución
Implementa este código en tu tema/plugin, e indica el rol que quieres filtrar y a qué página quieres redireccionar. En el ejemplo indico que todos los usuarios con el rol de «Editor» cuando quieran acceder al escritorio, que sean redireccionados al listado de Páginas.
<?php
/**
* Función para que un determinado rol de usuario
* no pueda acceder al administrador de WordPress.
*
* @author Mauricio Gelves <mg@maugelves.com>
*
*/
function mg_dashboard_redirect(){
// Obtengo el usuario actual
$user = wp_get_current_user();
// Pregunto por un rol específico
if( in_array( 'editor', $user->roles ) ):
// En caso que se encuentre en el array de roles lo redirecciono.
// En este caso lo estoy enviado al listado de páginas.
wp_redirect(admin_url('edit.php?post_type=page'));
exit;
endif;
}
add_action('load-index.php', 'mg_dashboard_redirect');
Actualización
Nuestro queridísimo amigo Fernan Díez ha hecho un upgrade del post con una gran idea: crear una página de inicio con documentación para el uso del administrador de WordPress.
<?php
/**
* Como primer medida creamos un menú bajo "Herramientas"
*/
function docs_admin_menu() {
add_management_page( 'Docs', 'Docs', 'manage_categories', 'docs', 'content_docs_admin_menu' );
}
add_action( 'admin_menu', 'docs_admin_menu' );
/**
* Aquí podemos crear nuestro HTML con la
* documentación para los usuarios responsables de
* cargar el contenido en el administrador.
*/
function content_docs_admin_menu() {
echo '<div class="wrap">';
echo '<h1>Docs Section</h1>';
echo '<h2>Lorem ipsum dolor sit amet</h2>';
echo '<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Proin nec cursus magna.</p>';
echo '<h2>Ut laoreet hendrerit dui</h2>';
echo '<p>Sed nec ipsum scelerisque, pellentesque urna at, fermentum nisi.</p>';
echo '<h3>Morbi vehicula quam quis lorem ultrices viverra</h3>';
echo '<p>Integer massa ipsum, consectetur eu luctus non, venenatis et est.</p>';
echo '<p><iframe width="560" height="315" src="https://www.youtube.com/embed/iJzUL79GaTo" frameborder="0" allowfullscreen></iframe></p>';
echo '</div>';
}
/**
* El código base para la redirección, pero apuntando
* a la nueva página creada.
*/
function mg_dashboard_redirect(){
// Get the current user
$user = wp_get_current_user();
// Asking for Editor role
if( in_array( 'editor', $user->roles ) ):
// If Editor role exists then redirect
wp_redirect(admin_url('tools.php?page=docs'));
exit;
endif;
}
add_action('load-index.php', 'mg_dashboard_redirect');
