• J’ai un comportement bizarre (et j’ai l’impression que c’est très très récent) avec Inscriptions3. Il s’agit du champ « Date de naissance ».

    Au premier affichage du formulaire, au lieu d’avoir les 3 cases Day/Month/Year, j’ai un simple champ texte avec marqué « 0000-00-00 ». C’est ce comportement que je ne comprends pas. Et qui me semble être apparu très récemment (genre ces jours-ci).

    Si je renseigne avec ma date de naissance, c’est très marrant (je m’amuse de peu) : les 3 champs séparés reviennent, correctement remplis (sauf que Month a un zéro-cinq, alors que Day a cinq-tout-court…). Et cette question : « Avez-vous vraiment plus de 110 ans ? », alors que les champs sont correctement remplis.

    Je resoumets le formulaire (en naissance d’autres champs vides histoire de pas valider), et cette entrée « Birthday » semble désormais correcte (pas de message d’erreur à ce niveau, mais toujours le même affichage de 5-05-1970).

    • Message d’erreur Javascript : j’ai du code avec jQuery() qui s’insère dans la page, et même un appel à saisies.js, alors que mes squelettes concatènet tout les JS, et que je fais l’appel asynchrone par ma propre méthode. Alors ça plante.

      Pourquoi Saisies n’a pas le fonctionnement standard pour insérer du JS ? Et je fais quoi maintenant ?

    • Et effectivement, en virant mon propre code qui insère async dans l’appel des JS, et en ajoutant le fameux :

      define("_JS_ASYNC_LOAD", true);

      ça refonctionne.

      Mais je continue à penser que les plugins devraient avoir un fonctionnement compatible avec un chargement asynchrone des scripts avec la méthode la plus basique – <script async>

    • De ma courte expérience des plugins de SPIP, c’est le seul qui fait ça, et qui du coup provoque une erreur dans mes pages, où j’utilise un #FILTRE en fin de traitement pour, assez simplement, transformer <script href> en <script async href>.

      Et là, comme c’est balancé en affichage_final, je ne peux donc pas le modifier. Et donc je suis obligé de me plier à la méthode intégrée à SPIP 3.1, avec _JS_ASYNC_LOAD, qui transforme profondément la façon d’appeler le Javascript avec insertion de code façon usine à gaz.

      Je veux bien que ça marche, mais m’embête tout de même beaucoup de voir ajouté à mes pages un code que je ne contrôle pas du tout, qui est rigoureusement incompréhensible, et qui ressemble à ceci :

      var jQl={q:[],dq:[],gs:[],ready:function(a){"function"==typeof a&&jQl.q.push(a);return jQl},getScript:function(a,c){jQl.gs.push([a,c])},unq:function(){for(var a=0;a<jQl.q.length;a++)jQl.q[a]();jQl.q=[]},ungs:function(){for(var a=0;a<jQl.gs.length;a++)jQuery.getScript(jQl.gs[a][0],jQl.gs[a][1]);jQl.gs=[]},bId:null,boot:function(a){"undefined"==typeof window.jQuery.fn?jQl.bId||(jQl.bId=setInterval(function(){jQl.boot(a)},25)):(jQl.bId&&clearInterval(jQl.bId),jQl.bId=0,jQl.unqjQdep(),jQl.ungs(),jQuery(jQl.unq()), "function"==typeof a&&a())},booted:function(){return 0===jQl.bId},loadjQ:function(a,c){setTimeout(function(){var b=document.createElement("script");b.src=a;document.getElementsByTagName("head")[0].appendChild(b)},1);jQl.boot(c)},loadjQdep:function(a){jQl.loadxhr(a,jQl.qdep)},qdep:function(a){a&&("undefined"!==typeof window.jQuery.fn&&!jQl.dq.length?jQl.rs(a):jQl.dq.push(a))},unqjQdep:function(){if("undefined"==typeof window.jQuery.fn)setTimeout(jQl.unqjQdep,50);else{for(var a=0;a<jQl.dq.length;a++)jQl.rs(jQl.dq[a]); jQl.dq=[]}},rs:function(a){var c=document.createElement("script");document.getElementsByTagName("head")[0].appendChild(c);c.text=a},loadxhr:function(a,c){var b;b=jQl.getxo();b.onreadystatechange=function(){4!=b.readyState||200!=b.status||c(b.responseText,a)};try{b.open("GET",a,!0),b.send("")}catch(d){}},getxo:function(){var a=!1;try{a=new XMLHttpRequest}catch(c){for(var b=["MSXML2.XMLHTTP.5.0","MSXML2.XMLHTTP.4.0","MSXML2.XMLHTTP.3.0","MSXML2.XMLHTTP","Microsoft.XMLHTTP"],d=0;d<b.length;++d){try{a= new ActiveXObject(b[d])}catch(e){continue}break}}finally{return a}}};if("undefined"==typeof window.jQuery){var $=jQl.ready,jQuery=$;$.getScript=jQl.getScript};

      Une grosse grosse partie de mon temps de travail est consacré à chercher pourquoi tel script ne fonctionne pas selon mes besoins, et assez souvent pourquoi tel script a cessé de fonctionner alors qu’avant il fonctionnait. Des bouts de code pareil, avant même de charger quelque script que ce soit (dont, pour une large part, je serais l’auteur), c’est pas du tout rassurant. :-)

      (Et en plus, c’est typiquement une façon d’appeler les scripts qui fait que je ne peux plus aspirer simplement un site avec mon wget usuel.)

      Je pense que, tout en profitant des avantages de ce script, on devrait s’astreindre à coder nos plugins pour que leur Javascript fonctionne déjà avec la méthode usuelle désormais conseillée, c’est-à-dire le simple appel <script href async>.

    • Mais saisies.js je le répète est bien inséré avec une balise <script> tout ce qu’il y a de plus normale, le script n’a rien de bizarre et il est parfaitement compatible avec un appel avec async, pour peu que quelque chose le rajoute (ou bien faudrait le mettre par défaut ?).

      Le code que tu colles est volontairement minifié pour qu’il soit plus rapide à charger alors ça n’a aucun sens de dire qu’il est incompréhensible. La vraie version étant en plus juste à côté, longue et bien commentée :
      https://git.spip.net/SPIP/compresseur/src/branch/master/lib/jQl/jQl.js

    • Sauf erreur : comme saisies.js est inséré par affichage_final, je n’y ai pas accès avec mon #FILTRE ramasse-miettes qui, justement, transforme les <script en <script async.

      Par ailleurs, si j’y avais accès, je ne sais pas comment se comporteraient des appels async à deux fichiers différents, sachant que saisies.js a besoin que jQuery.js soit chargé avant.

      Enfin, il reste le fait que du code Javascript, faisant appel à la variable jQuery, est inséré « en dur » dans la page elle-même :

      jQuery(document).ready(function(){
              activer_dateur_b0a2d9();
      });

      Et du coup je me rend compte que BigUpload aussi insère du code fautif directement dans ma page :

      jQuery.bigup_config = {maxFileSize: 10, formatsLogos: ["gif","jpg","png"]}

      Donc dans tous les cas, si je n’active pas la méthode _JS_ASYNC_LOAD, ces deux plugins planteront forcément avec un appel simple de type <script href async>.

    • Bé oui, c’est le principe dans un CMS dynamique modulaire, avec des plugins, tu ne pourras jamais, absolument jamais, t’assurer que 100% des JS sont tous ensemble, dans le bon ordre et qu’ils peuvent être appelés en async sans que toi tu connaisses leur ordre. Il y en a forcément qui pour tel ou tel besoin (GIS aussi par exemple) vont devoir charger du JS inline ici ou là.

      C’est bien pour ça que même avec la nouvelle méthode HTML5, la librairie JQL est utile, puisqu’elle permet avec un minuscule JS qui se charge obligatoirement en tout premier, de prendre en charge TOUS les morceaux de JS, y compris ceux inline n’importe où dans la page, et s’assurer qu’ils seront lancés uniquement lorsque jQuery sera certain d’être chargé, c’est son boulot.

    • Je ne comprends pas que, tout d’un coup, je me retrouve dans la position de celui qui demande à ce qu’on code proprement. :-))

      Ce n’est pas difficile de ne pas insérer de code jQuery dans le corps de la page, quand on prévoit que jQuery sera chargé et déclenché après le chargement de la page. À partir du moment où tout est prévu, niveau Web, pour travailler avec <script async>, ça devient vraiment farfelu de décider de faire reposer notre écosystème sur une bibliothèque (vraiment compliquée, même dans sa version d’origine), alors que toute la planète fait autrement, au motif qu’il y a deux bouts de ligne de code dans un de nos plugins qu’on pourrait décider de coder autrement (et généralement pas compliqué).

      Faire dépendre la compatibilité future de nos sites Web avec les futures versions de jQuery sur un morceau de code dont je suis persuadé que seul Cédric est capable de le maintenir, ou au moins de le modifier rapidement, ce n’est pas sain.