Para usar cualquier shortcode en los widgets de WordPress, y de esa manera evitar el uso de algunos plugins, basta añadir la siguiente línea al archivo functions.php del theme que se esté usando.
add_filter('widget_text', 'do_shortcode');
Una vez añadida la línea podemos usar shortcodes en el contenido de cualquier widget de texto.
Para añadir la caja de excerpt en las pantallas de edición de las páginas en WordPress basta añadir las siguientes líneas al archivo functions.php:
add_action( 'init', 'prefix_add_excerpt_to_page' );
function prefix_add_excerpt_to_page() {
add_post_type_support( 'page', 'excerpt' );
}
Mientras se lleva a cabo una actualización en WordPress se activa el modo mantenimiento. Si hay algún problema durante el proceso nuestra web puede quedar atrapada en modo mantenimiento. Lo sabremos porque al visitarla nos aparecerá el siguiente mensaje en lugar de la web: «No disponible por mantenimiento programado. Vuelve a comprobar el sitio en unos minutos.», o en inglés: «Briefly unavailable for scheduled maintenance. Check back in a minute.»
WordPress activa el modo mantenimiento generando un archivo llamado .maintenance en la raíz del árbol de carpetas. Para salir del modo mantenimiento lo único que hay que hacer es eliminarlo, vía FTP por ejemplo.
En cambio, para entrar en modo mantenimiento manualmente no basta con crear el archivo .maintenance.
Por seguridad WordPress Multisite desactiva la capacidad de incluir determinado código HTML para usuarios que no sean superadministradores (administradores de la red de sitios). Es una medida lógica para evitar que un usuario incluya código malicioso a través de la caja de contenido de un post. Sin embargo en redes de sitios controladas, con una comunidad de usuarios de confianza, puede tener sentido activar esta capacidad.
Lo que hace WordPress Multisite añadir los filtros KSES, que normalmente solo se aplican a colaboradores y autores, a los usuarios editores y administradores. También desactiva la capacidad unfiltered_html para editores y administradores.
El plugin Unfiltered MU elimina esta limitación. Para quien prefiera prescindir de plugin se puede incluir la activación en el theme que se esté usando.
WorPress Multisite añade el slug «blog» a los permalinks del sitio principal bajo la configuración de subdirectorios, no de subdominios, y lo hace por una razón: para evitar conflictos al coincidir la URL de un contenido del sitio principal (el que está alojado en el dominio) y la URL de otro de los sitios del Multisite (los que están alojados en un subdirectorio).
Eliminar «blog» de los permalinks puede traer problemas: tenemos que estar atentos para que ningún slug de un post, etiqueta o categoría del sitio principal sea igual al slug de uno de los sitios.
Si aún así se necesita eliminar la palabra blog, se puede hacer de la siguiente manera:
Eso sí, si se actualiza en el sitio principal la estructura de permalinks, «blog» volverá a aparecer en ellos. Si se quiere actualizar por alguna razón (por ejemplo cuando añadimos un nuevo post type hay que actualizar los permalinks para que el nuevo post type funcione), habrá que repetir el procedimiento.
En WordPress las hojas de estilo de un theme o un plugin se deben cargar usando las funciones wp_register_style y wp_enqueue_style. En el caso de un theme estas funciones se llaman desde el archivo functions.php. La hoja de estilo principal del theme, style.css, no hace falta cargarla ya que WordPress la carga automáticamente.
Cuando llamamos otra hoja de estilo, además de style.css, ésta se carga por omisión después que style.css. Para invertir este orden hay que indicar que style.css tiene como dependencia la otra hoja de estilo.
Por ejemplo, si estamos desarrollando un theme con el framework Bootstrap de Twitter y queremos cargar su CSS antes que el style.css del theme:
add_action( 'wp_enqueue_scripts', 'prefix_load_css_files' );
function prefix_load_css_files() {
wp_register_style( 'bootstrap-css', get_template_directory_uri() . '/bootstrap/css/bootstrap.min.css' );
wp_register_style( 'theme-css', get_stylesheet_uri(), array('bootstrap-css') );
wp_enqueue_style('theme-css');
}
El tercer parámetro que pasamos a la función wp_register_script son las dependencias. En la línea 4 estamos indicando que la hoja de estilos del theme tiene como dependencia la hoja de estilos de bootstrap, así que debe cargarse después.
Actualización septiembre 2022. Esta solución da error en las últimas versiones de WordPress y PHP. No funciona con WordPress 6 o superior y con PHP8. Puedes encontrar una solución actualizada en este otro post.
Parece ser que para evitar potenciales ataques de fuerza bruta a sitios con WordPress a través del protocolo XML-RPC, basta deshabilitar los pingbacks y no todo el sistema XML-RPC, como cuentan en WP-Tavern.
Si en tu sitio utilizas servicios que utilizan XML-RPC, como algunos plugins como Jetpack o la aplicación móvil de WordPress quizás te interese deshabilitar únicamente los pingbacks, que son en realidad la puerta de entrada de los ataques de fuerza bruta a WordPress.
Añade la siguiente función al functions.php de tu theme:
add_filter( 'xmlrpc_methods', 'remove_xmlrpc_pingback_ping' );
function remove_xmlrpc_pingback_ping( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} ;
Hace unos seis meses se descubrió que el archivo xmlrpc.php de WordPress, responsable de las comunicaciones remotas vía XML-RPC, convertía a los servidores donde estuviese instalado este gestor de contenidos en potenciales participantes de ataques DoSS. Hace un par de meses esta vulnerabilidad se empezó a usar también como puerta de entrada de ataques de fuerza bruta a los propios servidores.
Desde la versión 3.5, el protocolo XML-RPC viene activado por omisión en WordPress lo que hace que cualquier instalación de WordPress sea vulnerable. Para eliminar esta vulnerabilidad no queda otra que desactivar completamente el soporte XML-RPC de WordPress.