Carga y Descarga de Scripts en WordPress -- wp_deregister_script('jquery')

3 jul 2014, 10:20:22
Vistas: 15.4K
Votos: 2

Tengo algunas preguntas relacionadas con la carga/descarga de herramientas JavaScript en WordPress. Después de leer una respuesta bien escrita de Pieter Goosen a una pregunta, me puse a estudiar y limpiar el código que uso para cargar mis bibliotecas. Este código es del archivo function.php de mi tema hijo. Tengo algunas funciones en mi sitio que usan las herramientas de calendario datepicker. Además, hay algunos plugins que seguramente usan jQuery.

function jquery_loadup() {
        //wp_deregister_script('jquery');    <--- ?H
        wp_enqueue_script('jquery');
        //wp_enqueue_script('jquery-migrate');
        wp_enqueue_script('jquery-ui-core');
        wp_enqueue_script('jquery-ui-datepicker');
        wp_enqueue_style('jquery-style', 'http://ajax.googleapis.com/ajax/libs/jqueryui/1.10.4/themes/smoothness/jquery-ui.css');
}
add_action('wp_enqueue_scripts','jquery_loadup');

Tenía la impresión de que la línea wp_deregister_script('jquery') esencialmente reinicia/limpia todas las "solicitudes" previas de los scripts jQuery para que no interfieran entre sí. Esa línea seguida de wp_enqueue_script('jquery'); debería resultar en una carga mínima y limpia de jQuery a través del sistema de manejadores/rutas de scripts comúnmente usado en WordPress, ¿no? Pensaba que la llamada deregister verifica la presencia de una "instalación" previa de jQuery, y si encuentra una o más, detiene su carga, si no hay ninguna registrada, no hace nada.

Lo que estoy viendo es que cuando uso wp_deregister_script('jquery') obtengo un error en el sitio web "ReferenceError: jQuery no está definido". Cuando esto ocurre, todas mis funciones JavaScript fallan. ¿Qué está pasando? Cuando la comento, el sitio funciona bien.

Preguntas: ¿Me estoy perdiendo algo? ¿Qué no estoy entendiendo sobre la llamada deregister? ¿Por qué estaría recibiendo un mensaje de error?

Nota: la línea para jquery-migrate supuestamente es para software que usa versiones antiguas de jQuery. La probé, pero no veo que haga nada en mi sitio, así que la quité para mejorar los tiempos de descarga y respuesta. Pregunta: ¿Es esto una mala idea?

referencias:

2
Comentarios

wp_deregister significa que anulas el registro de 'jquery'. Entonces, cuando llamas a 'jquery' con wp_enqueue_script('jquery'), WordPress no puede encontrar jquery, porque ya lo has anulado. Por lo tanto, tu aplicación que necesita jQuery también fallará.

ucon89 ucon89
3 jul 2014 10:41:34

¿Eh? Oh... ahora lo entiendo... eso tiene mucho sentido. Eso elimina el alcance de jquery ahora definido por el sistema de Wordpress. Nadie quiere meterse con eso. Pero espera... ¿cómo sabe WordPress cómo detener el desorden dejado por 8 plugins diferentes que intentan agregar diferentes versiones de jquery? Además, adelante y responde a la pregunta para que pueda votarte positivamente?

zipzit zipzit
3 jul 2014 10:53:12
Todas las respuestas a la pregunta 2
2

WordPress tiene esencialmente dos grupos de métodos para manejar scripts, ambos deberían ser utilizados:

  • wp_register_script Registra un script en WordPress. No se llama, simplemente está disponible para WordPress, si es necesario.
  • wp_deregister_script es exactamente lo opuesto. Elimina las definiciones hechas en wp_register_script, el script ya no está disponible como dependencia o para encolamiento.

Los scripts registrados no generan ninguna salida en el código. Solo definen el script programáticamente para que WP pueda reaccionar a dependencias y encolamientos.

  • wp_enqueue_script realmente define y encola un script para su salida en el encabezado/pie de página del HTML.
  • wp_dequeue_script hace exactamente lo opuesto y desencola un script para su salida.

La impresión real ocurre en la acción 'wp_head' o 'wp_footer', dependiendo de los detalles de registro.

Un ejemplo:

wp_deregister_script('jquery');
wp_register_script('jquery', ("https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"), false, '1.9.1', true);

wp_enqueue_script( 'script-1', get_template_directory_uri() . '/js/example1.js', array('jquery'), '1.0.0', false );
wp_enqueue_script( 'script-2', get_template_directory_uri() . '/js/example2.js', array('jquery'), '1.0.0', true );
wp_enqueue_script( 'script-3', get_template_directory_uri() . '/js/example3.js', array('jquery'), '1.0.0', true );
wp_enqueue_script( 'script-4', get_template_directory_uri() . '/js/example4.js', array('jquery'), '1.0.0', true );
wp_enqueue_script( 'script-5', get_template_directory_uri() . '/js/example5.js', array('jquery'), '1.0.0', true );

En este ejemplo desregistro jQuery. Ya no está disponible y obtendría el mismo error que tú, si no lo registrara nuevamente. (Esta vez desde el CDN de Google con la esperanza de que acelere mi página).

Pero en la línea tres jQuery no se imprimirá. No aparecerá en ningún lugar. Pero desde la línea cuatro llamo a varios scripts, que todos tienen jQuery como dependencia. El primero reside en el encabezado, todos los demás en el pie de página. Debido a las dependencias, jQuery se encola automáticamente en el encabezado, porque primero se necesita allí.

Por lo tanto, con el sistema de scripts de WordPress, que es bastante sólido, no hay necesidad de manejar interferencias o solicitudes previas. Los scripts registrados se llaman cuando se necesitan una vez, y solo cuando se necesitan.

En tu ejemplo desregistras el script en la línea 1 de la función y lo llamas nuevamente en la línea 2. Pero debido al desregistro WordPress ha olvidado todos los detalles como URL, versión, dependencias, etc. La función correcta en tu lógica habría sido wp_dequeue_script, pero incluso eso no es necesario. WordPress evalúa la necesidad mirando los scripts encolados o las dependencias.

Edición:

¿cómo sabe WordPress cómo detener el desorden dejado por 8 plugins diferentes que intentan agregar diferentes versiones de jQuery?

La última instancia de registro de jQuery antes de la acción wp_print_scripts es la que se imprime. Eso es esencialmente para lo que sirve el sistema de prioridad en acciones/filtros.

3 jul 2014 11:01:13
Comentarios

Ahora tiene más sentido para mí... Dos notas 1) Al investigar más veo que en el núcleo de WordPress jquery = jquery.js & jquery-migrate.js (¡ups... respondí mi otra pregunta justo ahí!) según http://codex.wordpress.org/Function_Reference/wp_register_script#Handles_and_Their_Script_Paths_Registered_by_WordPress. 2) Todavía estoy confundido sobre qué sucede cuando 8 plugins diferentes intentan REGISTRAR y luego encolar su propia versión de jquery. ¿Cuál prevalece? ¿Es esto como la especificidad de CSS?

zipzit zipzit
3 jul 2014 11:12:04

La última llamada de registro que se ejecuta es la que prevalece. Ten en cuenta: Nada se ejecuta simultáneamente, todo se ejecuta uno después del otro, solo debes entender el orden en que se ejecutan las cosas.

Hendrik Luehrsen Hendrik Luehrsen
3 jul 2014 11:16:30
0

Solo para aportar, primero que nada, gracias por el cumplido, se agradece.

Estás usando un tema hijo, cuyo tema padre debería haber encolado la biblioteca jQuery integrada en WordPress. Como dije en la publicación a la que te refieres, es mala práctica, hago énfasis, que cualquier tema padre no encole jQuery por defecto.

Tienes un par de problemas con tu código. Primero que nada, nunca desregistres la biblioteca jQuery predeterminada, romperás algunas cosas más adelante. La forma correcta es desencolar el script usando wp_dequeue_scripts.

Solo una pregunta aquí, ¿por qué necesitas desencolar jQuery y volver a encolarlo? Esto suele ser utilizado por los autores de plugins solo para asegurarse de que jQuery no se cargue dos veces, la razón aquí es que los plugins funcionan en todos los temas, por lo que es imposible saber si el tema que un usuario está usando con el plugin tiene jQuery cargado. Estás ejecutando un tema hijo que solo funcionará en ese tema padre específico, por lo que sabrás si el tema padre tiene jQuery cargado. Así que no hay necesidad de desencolar y volver a encolar.

En segundo lugar, tendrás que mirar la prioridad. add_action tiene 4 parámetros, el tercero siendo prioridad ($priority). Generalmente los plugins y temas hijos cargan sus scripts después de un tema padre para asegurarse de que no se sobrescriban más adelante. Así que es sabio y una buena práctica ejecutar tu acción al final. Para hacer esto, necesitarás una prioridad muy baja, es decir, un número muy alto.

  add_action( 'wp_enqueue_scripts', 'jquery_loadup', 999 );
3 jul 2014 11:25:14