7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
Advertisement
  1. Code
  2. General

Cómo Incluir JavaScript y CSS en Tus Temas y Plugins WordPress

Read Time: 13 mins

Spanish (Español) translation by Eva Collados Pascual (you can also view the original English article)

Conocer la forma adecuada de incluir archivos JavaScript y CS en tus temas y plugins WordPress  es muy importante para los diseñadores y los desarrolladores. Si no sigues las mejores prácticas, corres el riesgo de crear conflictos con otros temas y plugins, y crear potencialmente problemas que podrían haber sido evitados fácilmente. Este artículo pretende ser una referencia sobre como jugar limpio con los demás.

Antes de que empecemos, puedes visitar nuestra sección de Temas para WordPress y Plugins para WordPress, por si necesitas lanzar a toda velocidad tu próximo proyecto profesionalmente.

Y si, tras leer este tutorial, todavía no estás seguro sobre cómo incluir tus archivos JavaScript y CSS de forma correcta, puede que valga la pena que solicites algunos de los servicios WordPress disponibles en Envato Studio.

Desde la instalación a la personalización, e incluso el SEO y la optimización de la velocidad, puedes contactar con un experto en WordPress para que establezca las cosas de la forma correcta desde el principio.


Las Mejores Prácticas Hacen a Todo el Mundo Feliz

Si has desarrollado alguna vez un tema o un plugin para WordPress, o has trabajado con uno que ha creado otra persona, probablemente te hayas encontrado con distintos métodos para incluir JavaScript y CSS. Mientras que existen distintos métodos que podrían parecer funcionar en una conjunto de circunstancias específicas, hay un método principal recomendado en el Codex WordPress. Este método preferente asegurará que tu tema y tu plugin funcione en todos los casos, asumiendo que los demás también estén codificando correctamente.

También hay algunos malos entendidos sobre qué dice exactamente el Codex sobre esto, lo cual ayudaré a clarificar


¿Qué Viene en la Caja?

Cuando descargas WordPress, éste ya viene con una selección de habituales librerías JavaScript incluidas que puedes usar para tu desarrollo JavaScript. Puedes encontrar una lista de las librerías incluidas en el artículo sobre wp_enqueue_script del Codex de WordPress.

Todas estas librerías están incluídas, pero por defecto WordPress solo carga las que necesita, y en el admin sólo cuando las necesita. Si escribes JavaScript que utiliza una de estas librerías, necesitarás indicarle a WordPress que cargue primero la librería para que tu script funcione.


Indicarle a WordPress Sobre Tu Script y Sobre Qué Necesita

Algunas de las cosas sobre las que debes pensar cuando estás creando código JavaScript para WordPress son las siguientes:

  • ¿Existe ya alguna librería incluída que pueda usar?
  • ¿Puedo usar la versión incluída?
  • ¿Necesito cargar mi script en el front-end y en el área de admin?
  • ¿En qué páginas del front-end y de admin necesito cargar mi script?

Responder a estas preguntas te ayudará a conocer qué necesitas hacer para registrar y cargar tu script. Esto se hace usando una función de WordPress llamada wp_register_script, y aquí tienes cómo se debe usar según el Codex de WordPress:

Entonces, ¿qué son estas variables?, ¿las necesitamos cada vez? (Esto se explica en la página del Codex, de manera que seré breve y usaré un lenguaje sencillo)

  • $handle – lo que necesitarás para referenciar este script concreto siempre que necesites encolarlo, y debes incluir esta variable como mínimo.
  • $src – la ruta del archivo de origen dentro de tu plugin o tema
  • $deps – es una cadena que contiene la variable $handle para cualquier otro u otros scripts que necesite tu propio script para ejecutarse (es decir, sus dependencias).
  • $ver – el número de versión de tu script, que puede usarse para cache-busting. Por defecto, WordPress usará su propio número de versión como número de versión para tu script.
  • $in_footer – ¿quieres que tu script se cargue en el footer? Establece esta variable a true o false. El valor predeterminado es false, por tanto se carga en el header, donde aparezca wp_head(), y si especificas true se cargará cuando wp_footer aparezca en el tema.

¿Qué es “Caché-Busting”?

Los navegadores recuerdan qué scripts y hojas de estilo han descargado para un determinado sitio basándose en la URL del script y de la hoja de estilo. Si cambias la URL, aunque tan solo añadas una cadena de consulta, los navegadores asumirán que es un nuevo archivo y lo descargarán de nuevo.


Ok, Probemos Algunos Ejemplos

Aquí tienes el ejemplo más sencillo para cargar un script:

Primero registramos el script, de forma que WordPress sepa de qué estamos hablando. La forma de encontrar la ruta para nuestro archivo JavaScript es distinta dependiendo de si estamos creando código para un plugin o para un tema, por eso he incluido ejemplos de ambos aquí arriba. Después los encolamos para añadirlos al HTML de la página cuando esta es generada, por defecto en el <head>, exactamente donde esté situado wp_head() en el tema.

Lo que nos devuelve este básico ejemplo es lo siguiente:

Ahora, si tu script es dependiente de una de las librerías incluidas en WordPress, como jQuery, puedes hacer un cambio muy sencillo en el código:

Nota: Por defecto, jQuery se carga con noConflict para prevenir conflictos con otras librerías (como por ejemplo con Prototype). Consulta la sección noConflict del Codex si no sabes cómo gestionar este asunto.

¿Has visto lo que hice aquí? Añade simplemente una cadena con el handle ‘jquery’ como dependencia. Éste usa en este caso una cadena, ya que tu script podría tener múltiples dependencias. Si tu script usa jQuery y jQuery UI, debes añadir jQuery UI a la cadena de tus dependencias, como array( ‘jquey’, ‘jquery-ui-core’ ).

Por tanto lo que nos devuelve esto ha cambiado, y podemos ver que jQuery también ha sido añadido al <head> de la página:

Probemos con un ejemplo que contiene todos los elementos:

Ok, ahora hemos añadido una versión y hemos especificado que este script necesita ser cargado en el footer. Para el número de versión he elegido la fecha del día de hoy ya que es una pista fácil de seguir, pero puedes usar cualquier número de versión, el que prefieras. La línea que nos devuelve esto es también un poco distinta, jQuery es llamado en el <head> y nuestro script junto con jQuery UI es invocado justo antes de la etiqueta de cierre <body>, de la siguiente manera:


Declarar Tus Prioridades de Forma Clara

Algunas personas podrían preferir no usar los métodos adecuados para encolar sus scripts porque piensan que tienen menos control sobre el orden en el que estos son cargados. Por ejemplo, en un tema que usa modernizr, el autor del tema podría querer asegurarse de que modernizr sea cargado al principio.

Algo que no he mencionado antes son los detalles sobre cómo funciona la función add_action, ya que aquí es donde podemos ejercitar un poco la influencia sobre el orden de las cosas. Aquí tienes la forma de usar esta función según la página del Codex de WordPress:

Advierte que con frecuencia, hasta ahora en este artículo, sólo hemos usado los parámetros $tag y $function_to_add. Por defecto el parámetro $priority está establecido a 10, y el valor predeterminado para $accepted_args es 1. Si queremos que nuestros scripts o estilos sean encolados antes, únicamente tenemos que indicar un valor inferior a al predeterminado para $priority. Por ejemplo:

El resultado de esto será el mismo que hemos visto antes, pero ocurrirá antes en el documento HTML.


Anular las Librerías Predeterminadas y Usar una Red de Distribución de Contenidos (CDN)

Es posible que en ocasiones quieras usar versiones de una librería distintas a las incluídas en WordPress. Quizá quieras usar una versión recién lanzada o no quieras esperar a la publicación de la próxima versión de WordPress antes de poder usar la última versión estable de jQuery. Otro motivo podría ser que quieras aprovechar la versión de una librería disponible en el CDN de Google.

Es importante advertir que esto sólo debería hacerse en plugins o temas usados en sitios web que vayas a mantener personalmente. Cualquier plugin o tema que comercialices para uso público debe usar las librerías incluídas en WordPress.

Te oigo exclamar “¿Por qué?!”. Por el simple motivo de que no tienes control sobre esos sitios web. Desconoces qué otros plugins y temas se pueden estar usando conjuntamente, y no sabes la frecuencia con la que actualizarán tu plugin o tema. Usando las librerías que vienen con el paquete de WordPress es la opción más segura.

Dicho esto, si deseas hacerlo en un sitio web que tu mantienes y gestionas, aquí tienes cómo se hace:

Así que antes de nada, he desregistrado la versión incluida de la librería, de no hacerlo se podrían producir conflictos entre las distintas versiones. Después registra la versión alternativa, usando el mismo handle, además, yo he decidido no especificar la versión (¡ya viene definida a través de la URL!) y no lo he especificado en el footer. El resto de nuestro código es igual, ya que dependiamos de cualquier script que estuviese siendo usado en el handle ‘jquery’. El resultado que obtenemos ahora es el siguiente:

Nota: uno de los motivos por los que es una mala idea hacer esto en un tema o plugin que vas a lanzar públicamente, es que todos los otros plugins o temas usados en ese sitio, ahora tendrán que usar esa versión de jQuery. Además, en la nueva versión de jQuery registrada no se indica noConflict, de manera que si otros scripts de plugins o del tema usan Prototype, por ejemplo, hará que las cosas se rompan.


No Seas Codicioso

Hasta ahora no hemos mencionado nada sobre cómo hacer todo esto en admin, sólo en el front-end. La diferencia principal es la acción a usar. En lugar de add_action( ‘wp_enqueue_scripts’, ‘wptuts_scrpts_basic’ ); que usamos para el front-end, la acción para el área de admin es add_action( ‘admin_enqueue_scripts’, ‘wptuts_scrpts_basic’ );

Algo que es importante hacer tanto para el front-end como para admin es ser selectivo con las páginas en las que vas a cargar tus scripts. Si tu plugin o tema tiene un script que solo hace algo en una página del front-end o de admin, como pudiera ser la página de opciones del tema, o quizá una página con un widget específico, sólo necesitas y deberías cargar los scripts en dicha página. ¡No tiene ningún sentido crear atascos y cargar scripts en páginas en las que no se van a usar!

Hay un gran ejemplo sobre cómo cargar scripts sólo en las páginas de los plugins en el Codex de WordPress. Como los plugins y los temas pueden variar mucho en lo que respecta a como están escritos, aquí no entraré en detalles sobre cómo ser selectivo al determinar en qué páginas cargar los scripts, pero era importante mencionarlo de manera que seas consciente de ello cuando escribas tu código.


Esos Scripts, Ahora Estilos

El proceso para los estilos es casi exactamente igual que el proceso para los scripts. Se hace usando una función llamada wp_register_style, y aquí tienes cómo se usa según el Codex de WordPress:

Observa que la única diferencia entre wp_register_script y wp_register_style es que en lugar de un parámetro $in_footer, tenemos un parámetro $media. Este parámetro puede establecerse a cualquiera de los siguientes valores: 'all''screen''handheld', y 'print', o cualquier tipo de media reconocido por W3C.

Aquí tienes un ejemplo de cómo se encolaría un script:

Es un ejemplo bastante claro, que utiliza la mayoría de los parámetros, y el resultado que devuelve es el siguiente:


Entonces, ¿Por Qué No Lo Hace Todo El Mundo de Esta Forma?

Buena pregunta, y la siguiente pregunta que imagino que me vas a hacer es, “¿Qué te hace pensar que esta es la forma “correcta” y no sólo tu preferencia?”. En esencia la respuesta es que este es el enfoque recomendado por WordPress. Éste método asegura que cualquier combinación de plugins y temas deberían poder funcionar perfectamente sin duplicarse.

He visto algunos temas y frameworks por ahí que usan las etiquetas <script></script> y <link /> en sus archivos header.php, e incluso en footer.php para cargar los scripts y estilos para el propio tema. Realmente no hay motivo para hacerlo así. Como hemos demostrado más arriba, es perfectamente posible priorizar los scripts y estilos y determinar si se deben cargar en el header o en el footer desde la comodidad de tu archivo functions.php. El beneficio es que tu tema o framework funcionará con un rango más amplio de plugins y/o temas hijo.

Un ejemplo de esto consiste en cargar jQuery usando las etiquetas <script></script>, que podrían parecer funcionar perfectamente, pero esto puede provocar que finalmente jQuery se cargue dos veces! Cargar jQuery de esta forma no evitará que WordPress cargue su versión de jQuery para otros plugins, ya que la versión que usa WordPress está en modo noConflict por defecto, y un plugin podría especificarlo como dependencia. Por tanto, tendrás jQuery funcionando tanto para el modo noConflict y para $, y además probablemente romperá cualquier plugin que use la librería Prototype.


Conclusión

WordPress es un sistema fantástico, y ha sido desarrollado concienzudamente y tras mucha reflexión. Si existe un mecanismo disponible en la plataforma para lograr algo concreto, normalmente la mejor idea es usarlo. Cuando desarrolles tus plugins y temas, recuerda crear código de forma responsable y de tal manera que funcione adecuadamente con otros componentes.

¿Qué piensas sobre el uso de wp_enqueue_script y sus funciones y acciones asociadas? ¿Conoces algún caso como ejemplo de mal uso? ¿Sabes de algún motivo por el cual no seguir las recomendaciones anteriores?

Si necesitas una solución preconfigurada, consulta nuestras secciones con Temas para WordPress y Plugins para WordPress en Envato Market.

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Scroll to top
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.