Los 10 errores más comunes que cometen los desarrolladores de WordPress
Publicado: 2022-03-11Solo somos humanos, y una de las características de ser humano es que cometemos errores. Por otro lado, también nos autocorregimos, lo que significa que tendemos a aprender de nuestros errores y, con suerte, podemos evitar cometer los mismos dos veces. Muchos de los errores que he cometido en el ámbito de WordPress se originan al tratar de ahorrar tiempo al implementar soluciones. Sin embargo, estos generalmente asomarían la cabeza en el futuro cuando surgieran problemas como resultado de este enfoque. Cometer errores es inevitable. Sin embargo, aprender de los descuidos de otras personas (¡y de los suyos, por supuesto!) es un camino que debe tomar de manera proactiva.
Error común n.º 1: mantener la depuración desactivada
¿Por qué debo usar la depuración cuando mi código funciona bien? La depuración es una función integrada en WordPress que hará que se muestren todos los errores, advertencias y avisos de PHP (sobre funciones obsoletas, etc.). Cuando la depuración está desactivada, es posible que se generen advertencias o avisos importantes que nunca vemos, pero que pueden causar problemas más adelante si no los tratamos a tiempo. Queremos que nuestro código funcione bien con todos los demás elementos de nuestro sitio. Por lo tanto, al agregar un nuevo código personalizado a WordPress, siempre debe realizar su trabajo de desarrollo con la depuración activada (¡pero asegúrese de desactivarla antes de implementar el sitio en producción!).
Para habilitar esta función, deberá editar el archivo wp-config.php
en el directorio raíz de su instalación de WordPress. Aquí hay un fragmento de un archivo típico:
// Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);
Esta no es una lista exhaustiva de las opciones de configuración que se pueden usar, pero esta configuración sugerida debería ser suficiente para la mayoría de las necesidades de depuración.
Error común n.° 2: Agregar secuencias de comandos y estilos con el gancho wp_head
¿Qué tiene de malo agregar los scripts a mi plantilla de encabezado? WordPress ya incluye una gran cantidad de scripts populares. Aún así, muchos desarrolladores agregarán scripts adicionales utilizando el wp_head
. Esto puede resultar en que se cargue varias veces el mismo script, pero en una versión diferente.
Hacer cola aquí viene al rescate, que es la forma amigable de WordPress de agregar scripts y estilos a nuestro sitio web. Utilizamos la puesta en cola para evitar conflictos de complementos y manejar cualquier dependencia que pueda tener un script. Esto se logra mediante el uso de las funciones incorporadas wp_enqueue_script
o wp_enqueue_style
para poner en cola scripts y estilos respectivamente. La principal diferencia entre las dos funciones es que con wp_enqueue_script
tenemos un parámetro adicional que nos permite mover el script al pie de página.
wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )
Si no se requiere que la secuencia de comandos represente el contenido de la mitad superior de la página, podemos moverlo con seguridad al pie de página para asegurarnos de que el contenido de la parte superior de la página se cargue rápidamente. Es una buena práctica registrar primero la secuencia de comandos antes de ponerla en cola, ya que esto permite que otros desregistren su secuencia de comandos a través del identificador en sus propios complementos, sin modificar el código central de su complemento. Además de esto, si el identificador de una secuencia de comandos registrada aparece en la matriz de dependencias de otra secuencia de comandos que se ha puesto en cola, esa secuencia de comandos se cargará automáticamente antes de cargar la secuencia de comandos en cola resaltada.
Error común n.º 3: evitar los temas secundarios y modificar los archivos principales de WordPress
Siempre cree un tema secundario si planea modificar un tema. Algunos desarrolladores realizarán cambios en los archivos del tema principal solo para descubrir después de una actualización del tema que sus cambios se sobrescribieron y se perdieron para siempre.
Para crear un tema secundario, coloque un archivo style.css
en un subdirectorio de la carpeta del tema secundario, con el siguiente contenido:
/* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */
El ejemplo anterior crea un tema secundario basado en el tema predeterminado de WordPress, Twenty Sixteen . La línea más importante de este código es la que contiene la palabra "Plantilla", que debe coincidir con el nombre del directorio del tema principal del que está clonando al hijo.
Los mismos principios se aplican a los archivos principales de WordPress: no tome la ruta fácil modificando los archivos principales. Haga ese esfuerzo adicional empleando funciones y filtros conectables de WordPress para evitar que sus cambios se sobrescriban después de una actualización de WordPress. Las funciones conectables le permiten anular algunas funciones básicas, pero este método se está eliminando gradualmente y reemplazando con filtros. Los filtros logran el mismo resultado final y se insertan al final de las funciones de WordPress para permitir que se modifique su salida. Un truco siempre es envolver sus funciones con if ( !function_exists() )
cuando use funciones conectables, ya que varios complementos que intentan anular la misma función conectable sin este contenedor producirán un error fatal.
Error común n.º 4: Codificación de valores
A menudo, parece más rápido simplemente codificar un valor (como una URL) en algún lugar del código, pero el tiempo que se dedica a depurar y rectificar los problemas que surgen como resultado de esto es mucho mayor. Al usar la función correspondiente para generar dinámicamente la salida deseada, simplificamos enormemente el mantenimiento y la depuración posteriores de nuestro código. Por ejemplo, si migra su sitio de un entorno de prueba a producción con URL codificadas, de repente notará que su sitio no funciona. Esta es la razón por la que deberíamos emplear funciones, como la que se enumera a continuación, para generar rutas de archivos y enlaces:
// Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();
Otro mal ejemplo de codificación rígida es cuando se escriben consultas personalizadas. Por ejemplo, como medida de seguridad, cambiamos el prefijo predeterminado de la tabla de datos de WordPress de wp_
a algo un poco más exclusivo, como wp743_
. Nuestras consultas fallarán si alguna vez movemos la instalación de WordPress, ya que los prefijos de la tabla pueden cambiar entre entornos. Para evitar que esto suceda, podemos hacer referencia a las propiedades de la tabla de la clase wpdb
:
global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );
Observe cómo no estoy usando el valor wp_users
para el nombre de la tabla, sino que dejo que WordPress lo resuelva. El uso de estas propiedades para generar los nombres de las tablas ayudará a garantizar que devolvemos los resultados correctos.
Error común n.° 5: no impedir que su sitio sea indexado
¿Por qué no querría que los motores de búsqueda indexaran mi sitio? La indexación es buena, ¿verdad? Bueno, al construir un sitio web, no desea que los motores de búsqueda indexen su sitio hasta que haya terminado de construirlo y haya establecido una estructura de enlaces permanentes. Además, si tiene un servidor de prueba donde prueba las actualizaciones del sitio, no querrá que los motores de búsqueda como Google indexen estas páginas duplicadas. Cuando hay múltiples piezas de contenido indistinguible, es difícil para los motores de búsqueda decidir qué versión es más relevante para una consulta de búsqueda. En tales casos, los motores de búsqueda penalizarán los sitios con contenido duplicado, y su sitio sufrirá en las clasificaciones de búsqueda como resultado de esto.
Como se muestra a continuación, la Configuración de lectura de WordPress tiene una casilla de verificación que dice "Disuadir a los motores de búsqueda de indexar este sitio", aunque esto tiene una nota importante debajo que dice que "Depende de los motores de búsqueda cumplir con esta solicitud".

Tenga en cuenta que los motores de búsqueda a menudo no cumplen con esta solicitud. Por lo tanto, si desea evitar de manera confiable que los motores de búsqueda indexen su sitio, edite su archivo .htaccess
e inserte la siguiente línea:
Header set X-Robots-Tag "noindex, nofollow"
Error común n.º 6: no verificar si un complemento está activo
¿Por qué debo verificar si existe una función de complemento si mi complemento siempre está activado? Seguro, el 99% del tiempo su complemento estará activo. Sin embargo, ¿qué pasa con ese 1% de las veces cuando por alguna razón se ha desactivado? Si esto ocurre, y cuando esto ocurra, su sitio web probablemente mostrará algunos errores de PHP feos. Para evitar esto, podemos verificar si el complemento está activo antes de llamar a sus funciones. Si la función del complemento se llama a través del front-end, debemos incluir la biblioteca plugin.php
para llamar a la función is_plugin_active()
:
include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }
Esta técnica suele ser bastante fiable. Sin embargo, podría haber casos en los que el autor haya cambiado el nombre del directorio principal del complemento. Un método más sólido sería verificar la existencia de una clase en el complemento:
if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }
Es menos probable que los autores cambien el nombre de la clase de un complemento, por lo que generalmente recomendaría usar este método.
Error común n.º 7: cargar demasiados recursos
¿Por qué debemos ser selectivos al cargar recursos de complementos para páginas? No hay una razón válida para cargar estilos y scripts para un complemento si ese complemento no se usa en la página a la que ha navegado el usuario. Al cargar archivos de complementos solo cuando sea necesario, podemos reducir el tiempo de carga de nuestra página, lo que resultará en una mejor experiencia para el usuario final. Tomemos, por ejemplo, un sitio de WooCommerce, donde solo queremos que el complemento se cargue en nuestras páginas de compras. En tal caso, podemos eliminar selectivamente cualquier archivo para que no se cargue en todas las páginas de otros sitios para reducir la hinchazón. Podemos agregar el siguiente código al archivo functions.php
del tema o complemento:
function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');
Los scripts se pueden eliminar con la función wp_dequeue_script($handle)
a través del identificador con el que se registraron. Del mismo modo, wp_dequeue_style($handle)
evitará que se carguen las hojas de estilo. Sin embargo, si esto es demasiado difícil de implementar para usted, puede instalar el Organizador de complementos que brinda la capacidad de cargar complementos de forma selectiva en función de ciertos criterios, como el tipo de publicación o el nombre de la página. Es una buena idea deshabilitar los complementos de almacenamiento en caché, como W3Cache, que puede haber activado para evitar tener que actualizar el caché constantemente para reflejar los cambios que haya realizado.
Error común n.º 8: mantener la barra de administración
¿No puedo dejar la barra de administración de WordPress visible para todos? Bueno, sí, podría permitir que sus usuarios accedan a las páginas de administración. Sin embargo, estas páginas muy a menudo no se integran visualmente con el tema elegido y no brindan una integración perfecta. Si desea que su sitio se vea profesional, debe deshabilitar la barra de administración y proporcionar una página de administración de cuenta de front-end propia:
add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }
El código anterior, cuando se copia en el archivo functions.php
de su tema, solo mostrará la barra de administración para los administradores del sitio. Puede agregar cualquiera de los roles o capacidades de usuario de WordPress en la función current_user_can($capability)
para excluir a los usuarios de la barra de administración.
Error común n.º 9: no utilizar el filtro GetText
Puedo usar CSS o JavaScript para cambiar la etiqueta de un botón, ¿qué hay de malo en eso? Bueno, sí, puedes. Sin embargo, está agregando código superfluo y tiempo adicional para mostrar el botón, cuando en su lugar puede usar uno de los filtros más útiles en WordPress, llamado gettext
. Junto con el dominio de texto de un textdomain
, un identificador único que garantiza que WordPress pueda distinguir entre todas las traducciones cargadas, podemos emplear el filtro gettext
para modificar el texto antes de que se represente la página. Si busca en el código fuente la función load_plugin_textdomain($domain)
, obtendrá el nombre de dominio que necesitamos para anular el texto en cuestión. Cualquier complemento de buena reputación garantizará que el textdomain
de texto para un complemento se establezca en la inicialización del complemento. Si desea cambiar algún texto de un tema, busque la línea de código load_theme_textdomain($domain)
. Usando WooCommerce una vez más como ejemplo, podemos cambiar el texto que aparece para el encabezado "Productos relacionados". Inserta el siguiente código en el archivo functions.php
de tu tema:
function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );
Este enlace de filtro se aplica al texto traducido mediante las funciones de internacionalización __()
y _e()
, siempre que el textdomain
de texto se establezca a través de las funciones mencionadas anteriormente.
_e( 'Related Products', 'woocommerce' );
Busque en sus complementos estas funciones de internacionalización para ver qué otras cadenas puede personalizar.
Error común n.º 10: mantener los enlaces permanentes predeterminados
De forma predeterminada, WordPress utiliza una cadena de consulta con el ID de la publicación para devolver el contenido especificado. Sin embargo, esto no es fácil de usar y los usuarios pueden eliminar partes pertinentes de la URL al copiarla. Más importante aún, estos enlaces permanentes predeterminados no utilizan una estructura compatible con los motores de búsqueda. Habilitar lo que llamamos enlaces permanentes "bonitos" garantizará que nuestras URL contengan palabras clave relevantes del título de la publicación para mejorar el rendimiento en las clasificaciones de los motores de búsqueda. Puede ser una tarea bastante desalentadora tener que modificar retrospectivamente sus enlaces permanentes, especialmente si su sitio ha estado funcionando durante un período de tiempo significativo y tiene cientos de publicaciones ya indexadas por los motores de búsqueda. Entonces, después de instalar WordPress, asegúrese de cambiar rápidamente su estructura de enlaces permanentes a algo un poco más amigable con los motores de búsqueda que solo una ID de publicación. Generalmente uso el nombre de la publicación para la mayoría de los sitios que construyo, pero puede personalizar el enlace permanente al formato que desee utilizando las etiquetas de estructura de enlace permanente disponibles.
Conclusión
Este artículo no es de ninguna manera una lista exhaustiva de los errores cometidos por los desarrolladores de WordPress. Sin embargo, si hay algo que debe recordar de este artículo, es que nunca debe tomar atajos (¡y eso es cierto en cualquier plataforma de desarrollo, no solo en WordPress!). El tiempo ahorrado ahora por malas prácticas de programación volverá para atormentarte más tarde. Siéntete libre de compartir con nosotros algunos errores que hayas cometido en el pasado y, lo que es más importante, cualquier lección aprendida, dejando un comentario a continuación.