[spip-dev] Évolutions SPIP 3.2 + Menu privé alpha

Dev
1

Je rebondis sur ce que disait b_b dans un autre sujet :

> Pour en revenir à la question de la version de la prochaine release. Il
> semblait se dégager un accord commun pour sortir une 3.2 afin d'être
> certain de la sortir dans l'année, voir même avant cet été. Et peut-être
> même lancer une dynamique de release plus fréquentes sur le Y en
> ajoutant des fonctionnalités au coup par coup (cf les tickets roadmap).
> Du coup, j'ai peur qu'on se lance dans un chantier sans fin si on part
> sur l'idée du 4.0 qui casse tout.

On pourrait déjà la proposer avec le contenu qu'il y a dedans, + éventuellement le plugin Menu alpha privé à intégrer.

Pour rappel ce qui a été fait à la grosse louche :
- jQuery en version 3.1
- jQuery UI en version 1.12
- Minidoc / Ordoc intégrés
- Notices PHP en moins avec PHP 7.1
- Homogénéisations sur le critère {par}
- L'aide déplacée en plugin-dist
- Gestion des archives zip/tar déplacée en plugin-dist (+ des apis qui ne semblent pas terminés)

Je serais fortement d'avis d'intégrer https://contrib.spip.net/Menu-prive-alphabetique donc aussi. Cf Ticket https://core.spip.net/issues/3886 . Si différentes personnes pouvaient tester le plugin en 3.1 avec la notion de "Menus favoris", des retours seraient bienvenus.

Je serais d'avis également d'en profiter pour monter la version minimale de PHP requise à PHP 5.4 (pour rappel seules les versions PHP 5.6 et supérieures sont maintenues).

Je pense que ce sont des changements suffisants pour offrir une 3.2 rapidement (d'ors & déjà), et ensuite pouvoir passer à d'autres choses.

Medoc & consœurs entre autres, les rangs, différentes choses. Ça peut repasser sur un prochaine 3.3 .

Pour les utilisateurs, il y a plusieurs difficultés à la migration 3.1 vers 3.2 déjà avec ces changements :

- Les vieux navigateurs ne sont plus supportés (IE < 9) par jQuery 3. Il n'en reste cependant plus beaucoup heureusement (http://caniuse.com/usage-table)

- Le Core utilise maintenant dans les listes de documents quelques flexbox (c'était plus facile!), ce qui amène à IE 11 minimum je suppose l'affichage optimal de l'espace privé.

- Migrer de jQuery 1.10 à jQuery 3 peut nécessiter de reprendre les scripts JS ou les librairies JS utilisées. L'intégration du jquery-migrate peut temporiser un peu (note: penser à désactiver ses logs d'erreurs avant la sortie) pour la plupart des problèmes. On pourra enlever ce JS par exemple dès SPIP 3.3 pourquoi pas.

- Migrer vers jQuery UI 1.12 également, particulièrement on ne gère plus les dépendances des morceaux de jQuery UI, on inclut dès que le pipeline jquery_ui est utilisé tout le JS de jquery UI, et tout son fichier CSS. Ça devenait ingérable avec leurs derniers changements qui découpait le core en plein de petits JS encore et encore. L'espace privé de SPIP intègre systématiquement tout jQuery UI du coup.
Les $.getScript("#CHEMIN{prive/javascript/ui/sortable.js}" deviennent erronés, probablement à remplacer par $.getScript("[(#CHEMIN{prive/javascript/ui/jquery-ui.js}|compacte)]" ou équivalent.

Est-ce que ces changements suffisent pour sortir une 3.2 ?
Des avis ? des remarques ?

MM.

2

Hello,

je réagis juste sur ce point qui m'avait un peu titillé :

Matthieu Marcillaud a écrit :

- Le Core utilise maintenant dans les listes de documents quelques
flexbox (c'était plus facile!), ce qui amène à IE 11 minimum je suppose
l'affichage optimal de l'espace privé.

Je ne pense pas qu'on ait le droit de ce genre de postulat et de se permettre cette facilité.

Qu'on laisse tomber tout IE<9 du fait de l'upgrade jQuery me parait tenable, mais il faut être cohérent et l'espace privé doit fonctionner aussi sur ces versions.

Surtout que dans le cas présent c'est a priori très ponctuel, donc même si c'est techniquement un peu plus difficile et moins fun, il faut revoir ce html et utiliser des techniques qui marcheront sur tous les navigateurs qu'on annonce supporter (donc IE>=9 notamment)

Je réponds au reste plus tard, mais vous avez super bien avancé, c'est génial !

Cédric

3

Hop,

4

J'avais passé un peu du temps à tenter de faire avec des float à la traditionnelle tout en permettant 3 affichages différents (grand, cases, liste) des documents, mais il y avait toujours des cas où les alignements n'étaient pas corrects ; j'ai fini par m'agacer et par utiliser flexbox, qui, bien qu'on ne puisse pas tout faire avec, a permis de réaliser ce que j'avais en tête.

Si quelqu'un veut tenter, pourquoi pas ; ceci dit également IE9 et IE10 semblent faire 0,52% des utilisateurs maintenant (à vérifier), ce qui commence à devenir assez maigre. Je n'ai en aucun IE sous la main pour tester par ailleurs (si quelqu'un veut faire des captures des listes de documents en 3.2 sous IE 9, 10 et 11…).

Je ne suis pas encore entièrement non plus satisfait du grand affichage, bien que cela me plaise déjà plus qu'avant (notamment le fait d'avoir le lien 'détail' qui cache un tas de choses souvent peu utiles d'êtres visibles en permanence). Mais je n'ai pas trouvé mieux pour l'instant.

MM.

5

Check. Dans la boîte.

MM.

6

En l'état actuel l'affichage n'est pas correct sur IE 10, j'ai fait quelques captures d'écran : https://framapic.org/gallery#q2G34gLMFriE/pN1H2MQvecDD.jpg,j2yGid8oV80b/vc5oHEWseBk6.jpg,kC6gJ5mK5IDs/YG3MgAoXYKM7.jpg

Je pense que c'est simplement dû au fait qu'il manque les préfixes navigateurs pour les propriétés flexbox. En principe à partie d'IE10, flexbox est partiellement supporté.

À mon avis, ça vaudrait le coup de tenter d'obtenir ces modes d'affichage avec des propriétés "à l'ancienne" avant d'utiliser flexbox, comme ça on aurait une compatibilité avec IE9 également (même si la bête est voie de disparition).
Avec des display: table et cie, c'est peut-être jouable. Je testerai dès que possible.

Quant au polyfill, si c'est juste pour régler ce problème, ça ne devrait être qu'un dernier recours amha.
Mais si on dit qu'à partir de maintenant, flexbox est "accepté" dans le privé, là oui ça peut être intéressant (c'est quand même très pratique flexbox !).

7

Donc pour faire suite, avec les préfixes c'est bon pour IE10+.

8

Merci d'avoir regardé et corrigé.

MM.

9

Coucou,

10

Hello,

je finis de répondre car je vois que je ne l'avais pas fait.

Pour moi le seul point à règler absolument avant de lancer un processus de release c'est le nom du plugin-dist archives (qui gère les zip et les tar) qu'il ne faut surtout pas garder comme ça il y à déjà un plugin archive (sans s, qui gère le statut archive des articles).

Si on release avec ce nom, on va s'en mordre les doigts longtemps à cause du nombre de quiproquo que cela va générer.

Pour le reste il faut en effet ne pas tomber dans le piège du "mais attends, je voulais mettre ça dedans". Ce qui n'est pas fait/prêt sera pour la prochaine itération. Donc go (une fois le nom du plugin corrigé :p)

11

Grenier avec un nouveau numéro de version?
Ou alors "musée" ?

12

Bonjour,

13

plutôt « compresseur » puisqu’on parle d’archives zip et tar ?

14

C'est ennuyant car les 2 termes les plus appropriés sont déjà utilisés
- 'Archive' : https://zone.spip.org/trac/spip-zone/browser/plugins/archive/trunk/
- 'Compresseur' : https://zone.spip.org/trac/spip-zone/browser/core/plugins/compresseur

Par ailleurs, c'est bien le terme "Archive" qui est utilisé en anglais et souvent en français pour parler des .zip, .tar, etc.

On peut lire sur Wikipedia :
- "7-Zip est un logiciel de compression de données et d’archivage de fichiers"
- "Le ZIP est un format de fichier permettant l'archivage et la compression de données "

D'autres termes possibles ?
- Archives de fichiers *
- Entrepôt
- Zippeur

* Est-ce que ça ne serait pas une solution suffisante que de compléter le nom d'origine, et de modifier le préfixe également ? (archives => archifich) (ou tout autre machin différent de 'archive').

MM.

15

:

plutôt "compresseur" puisqu'on parle d'archives zip et tar ?

C'est ennuyant car les 2 termes les plus appropriés sont déjà utilisés
- 'Archive' : Connexion · GitLab
ve/trunk/
- 'Compresseur' : Connexion · GitLab
p-zone/browser/_core_/plugins/compresseur

Par ailleurs, c'est bien le terme "Archive" qui est utilisé en anglais et
souvent en français pour parler des .zip, .tar, etc.

On peut lire sur Wikipedia :
- "7-Zip est un logiciel de compression de données et d’archivage de
fichiers"
- "Le ZIP est un format de fichier permettant l'archivage et la
compression de données "

D'autres termes possibles ?
- Archives de fichiers *
- Entrepôt
- Zippeur

Là aussi, c'est déjà pris :

16

Juste mon petit grain de sel, pour soumettre une idée:
7-Spip
Pardon pour le dérangement et merci pour le travail accompli!

17

Matthieu Marcillaud a écrit le 23/02/2017 à 14:48 :

18

Arf, je pensais que c'était les vieilles fonction de SPIP… non c'est un API de compression/ decompression si j'ai bien compris.

Alors compresseur oui, serait bien (on peut pas dire zippeur, parceque cela ne fait pas que zipper, et qu'il y a un plugin qui le fait déjà (même s'il serait à reprendre de A à Z))

19

Je propose "Casserole" !

Sinon, est-ce que ce ne serait pas une bonne idée de revoir un peu la manière dont on nomme les plugins ?

C'est un peu agaçant de devoir sans cesse trouver des synonymes pour trouver un préfixe disponible... D'autant que tout les bons préfixes semblent déjà utilisés.

Est-ce qu'il ne serait pas possible d'avoir un système d'espace de nom ?

https://fr.wikipedia.org/wiki/Espace_de_noms_(programmation)

Je vois quelque façon de faire :

core:zipper : Plugin dans le core
zone:zipper : plugin de zipper de la zone

Concernant l'espace de nom "zone" je pense qu'il faudrait encore pouvoir subdiviser :

zone:be.henix:zipper

Et on pourrai aller encore plus loin ?

github:username:zipper (on peut rêver ? non ?)

Concernant la mise en œuvre, un argument "espace" en plus dans paquet.xml ?

Didier

20

Allez, j'y vais de ma proposition : "compacteur" pour éviter a confusion avec le plugin compresseur.