Revisions : SPIP
Les articles publiés sur le site
-
Anomalie #4717 : Erreurs nombre d’argument des filtres
17 avril 2021, par jluc -Voici la PR : https://git.spip.net/spip/spip/pulls/160 qui du coup teste aussi $reflection->isInternal()
et qui utilise la chaine de langue erreur existante.
Ça permet donc un message d'erreur i18n et qui fait référence au source SPIP au lieu du source PHP compilé que personne n'est sensé connaître. -
Anomalie #4737 (Nouveau) : Erreur recherche dans les forums dans le privé
17 avril 2021, par jluc -Dans la partie privée, lorsqu'on utilise la recherche dans les forums publics (menu Activité / Gérer les forums), c'est le forum en tête du fil (id_thread) d'une bonne réponse qui est renvoyé, pas le forum qui contient le mot cherché. Du coup on ne voit pas le mot recherché.
Exemple :
- Pour l'article "Formidable, le générateur de formulaires" sur contrib https://contrib.spip.net/3284
- la recherche du mot "hashage" https://contrib.spip.net/ecrire/?exec=controler_forum&objet=article&id_objet=3284&recherche=hashage
- renvoie le forum 508211, qui est la question (=id_thred) « Est-ce qu’il serait envisageable que l’option « Effacer régulièrement les résultats les plus anciens » affecte tous les résultats ? »
- alors que le mot apparaît dans une des réponses, le forum 508219. https://contrib.spip.net/ecrire/?exec=controler_forum&objet=article&id_objet=3284&debut_forum=%40508219#forum508219 (son url actuelle dans le public : https://contrib.spip.net/3284#comment508219-508211)Seul le forum de tête de fil apparaît.
Constaté avec les liens ci dessus sur contrib, et également sur un autre site en SPIP 3.3 de l'automne 2020.
-
Anomalie #4736 : nouveau date picker et la modalbox ou les crayons dans le public
17 avril 2021, par RastaPopoulos ♥Je suis d'accord pour dire qu'il faut le moins de hack etc ok.
Pour autant je ne suis pas d'accord effectivement avec l'argumentation "ça a été fait que pour l'admin de SPIP".
De mon point de vue, à peu près tout ce qui est fonctionnel ne fait pas du tout partie de "l'admin de SPIP". D'ailleurs un jour (quand on redécoupera pour Composer par ex) il faudrait déplacer ces éléments dans un autre dossier afin de mieux comprendre (et ça nous forcera à bien faire attention à ce que ces éléments marchent ailleurs)
D'un côté le core fournit des briques fonctionnelles (API, formulaires insérables partout, etc), et de l'autre on a une interface d'admin par défaut, qui est une manière (couvrant 95% des besoins) de présenter l'administration du site. Mais toutes les briques fonctionnelles doivent être utilisables ailleurs que dans l'admin. Notamment tous les formulaires CVT sont insérables ailleurs et doivent fonctionner. Et donc si un form d'un objet à un champ pour choisir une date, que ce soit de la dist ou editer_evenement d'Agenda ou autre, ça doit marcher qu'on soit dans l'admin ou qu'on l'utilise ailleurs.
Que quelques rares fonctionnalités ne soient prévues que pour l'admin ok, par ex les forms de SVP, la gestion des plugins, c'est logique. Mais "avoir un champ date" c'est tellement courant, que ça ne devrait pas être cloisonné à l'admin.
-
Anomalie #4623 : Styles des fieldset dans l’espace privé
17 avril 2021, par RastaPopoulos ♥Alors c'est justement ce que je ne voulais pas générer au moins pour les groupes racines : là on se retrouve pour les fieldsets racines avec 2 bordures collées, ce qui fait super lourd visuellement il me semble : bordure du form et direct collé bordure du groupe.
Je détaille l'argument du foncé qui était volontaire : quand il y a des décorations claires, certaines personnes (et suivant la qualité des écrans) ne les voient pas ou peu, mais ce n'est pas grave si ce n'est que de la déco. Alors qu'un élément foncé va être vu par un pourcentage bien plus grand de personnes. Comme là il s'agit d'une indication visuelle utile, et non pas juste de décoration, je trouvais donc important que ce soit foncé pour que le max de gens les voit.
Pour les barres horizontales, là aussi c'était voulu de les enlever, afin d'alléger visuellement : là on se retrouve de nouveau avec des "cadres enfermants" de partout et donc visuellement (quand on a des yeux qui voient toutes les lignes) on a dès le premier coup d'œil cette impression de "cadres dans des cadres dans des cadres". Alors que le but des simplifications de Tcharlss était justement de minimiser le plus possible cette impression, et du coup mon but était de trouver une solution pour les fieldsets qui n'en rajoute pas dans ce domaine.
Pour la bordure sur la droite b_b, je vais faire un essai, mais le premier truc qui me vient c'est que justement on lit à gauche, et que seulement une indentation sans bordure à gauche c'est beauuuucoup plus faible pour voir du premier coup quels champs sont regroupés avec quels autres. Ça va faire qu'on va voir le regroupement que dans un deuxième temps au lieu de le voir au début de chaque ligne.
-
Anomalie #4717 : Erreurs nombre d’argument des filtres
17 avril 2021, par jluc -Pour mémo :
function phraser_arite_incorrecte(string $filtre, int $nb_args) : string { if (!function_exists($filtre)) { // détection des fonctions non existantes ailleurs ? return ''; } $reflection = new ReflectionFunction($filtre); $min = $reflection->getNumberOfRequiredParameters(); $max = $reflection->getNumberOfParameters(); if (($nb_args < $min) or ($nb_args > $max and !$reflection->isVariadic())) { return " appelé avec $nb_args arguments alors qu'il en faut au moins $min et au plus $max"; } return ''; }