New feature : Ajouter des services #19

Closed
paidge wants to merge 32 commits from dev/ajouter_services_auto into master
paidge commented 2 months ago
Collaborator

Ajoute la possibilité d'ajouter des services dans le backoffice.

Ajoute la possibilité d'ajouter des services dans le backoffice.
paidge added 1 commit 2 months ago
paidge closed this pull request 2 months ago
Collaborator

Salut !

Alors je viens de tester, et ça me semble super intéressant :)
Par contre, lorsque j'essaie avec Matomo (mon dada du moment ^^), je peux bien activer le service mais le fichier services/matomo.html n'est pas généré.

Salut ! Alors je viens de tester, et ça me semble super intéressant :) Par contre, lorsque j'essaie avec Matomo (mon dada du moment ^^), je peux bien activer le service mais le fichier services/matomo.html n'est pas généré.
peetdu reopened this pull request 2 months ago
Collaborator

Intéressant. Impressionnant !

On garde le ticket ouvert tant les problèmes identifiés non pas été résolus

Intéressant. Impressionnant ! On garde le ticket ouvert tant les problèmes identifiés non pas été résolus
Poster
Collaborator

Merci pour les retours. C'est très encourageant :) Pour Matomo, je viens de faire un test en local et ça a fonctionné. Attends peut-être mon prochain push pour ré-essayer. Je pense qu'il a écrit le fichier ailleurs. Regarde dans ton path. Cela va êttre corrigé en écrivant dans le dossier squelettes à la racine du site. Au vu de la doc sur https://tarteaucitron.io/fr/install/, Matomo nécessitera une intervention manuelle pour être fonctionnelle. En effet, dans services/matomo.html, il va falloir rajouter :
tarteaucitron.user.matomoId = SITE_ID;

Et aussi cet appel à mettre 'je ne sais où' :
<script>tarteaucitron.user.matomoHost = 'YOUR_MATOMO_URL';</script>

Un service qu'il faudrait sûrement intégrer nativement dans le plugin.

Merci pour les retours. C'est très encourageant :) Pour Matomo, je viens de faire un test en local et ça a fonctionné. Attends peut-être mon prochain push pour ré-essayer. Je pense qu'il a écrit le fichier ailleurs. Regarde dans ton path. Cela va êttre corrigé en écrivant dans le dossier squelettes à la racine du site. Au vu de la doc sur https://tarteaucitron.io/fr/install/, Matomo nécessitera une intervention manuelle pour être fonctionnelle. En effet, dans services/matomo.html, il va falloir rajouter : `tarteaucitron.user.matomoId = SITE_ID;` Et aussi cet appel à mettre 'je ne sais où' : `<script>tarteaucitron.user.matomoHost = 'YOUR_MATOMO_URL';</script>` Un service qu'il faudrait sûrement intégrer nativement dans le plugin.
Owner

Hello,

Je suis cela de très loin, mais puisqu'on parlait de _DIR_PLUGIN_XXX sur IRC, je note un problème dans le code.

Dans action/tac_installer_service.php tu écris des fichiers directement dans le répertoire du plugin :

file_put_contents(_DIR_PLUGIN_TARTEAUCITRON . "services/" . $service . ".html", ...);

Ceci est à éviter : tout sera supprimé à chaque mise à jour du plugin. Et je ne suis pas sûr que les droits d'écriture soient tout le temps suffisants.

Il faut placer ces fichiers dans un dossier prévu à cet effet, à priori ça serait dans config/tarteaucitron/services ou un truc comme ça.
Le dossier config est donné par la constante _NOM_PERMANENTS_INACCESSIBLES

Voilà, c'est juste rapidement en passant :)

Hello, Je suis cela de très loin, mais puisqu'on parlait de \_DIR_PLUGIN_XXX sur IRC, je note un problème dans le code. Dans [action/tac_installer_service.php](https://git.spip.net/spip-contrib-extensions/tarteaucitron/src/branch/dev/ajouter_services_auto/action/tac_installer_service.php#L36) tu écris des fichiers directement dans le répertoire du plugin : ```php file_put_contents(_DIR_PLUGIN_TARTEAUCITRON . "services/" . $service . ".html", ...); ``` Ceci est à éviter : tout sera supprimé à chaque mise à jour du plugin. Et je ne suis pas sûr que les droits d'écriture soient tout le temps suffisants. Il faut placer ces fichiers dans un dossier prévu à cet effet, à priori ça serait dans config/tarteaucitron/services ou un truc comme ça. Le dossier config est donné par la constante [_NOM_PERMANENTS_INACCESSIBLES](https://www.spip.net/fr_article4638.html#_NOM_PERMANENTS_INACCESSIBLES) Voilà, c'est juste rapidement en passant :)
paidge added 4 commits 2 months ago
Poster
Collaborator

Du coup @tcharlss, le plugin écrit dans le dossier squelettes à la racine du site (il crée le dossier si il n'existe pas), en prenant en compte la mutualisation (éventuellement). Voir code.
C'est mieux comme ça ?

Du coup @tcharlss, le plugin écrit dans le dossier squelettes à la racine du site (il crée le dossier si il n'existe pas), en prenant en compte la mutualisation (éventuellement). [Voir code](https://git.spip.net/spip-contrib-extensions/tarteaucitron/src/branch/dev/ajouter_services_auto/action/tarteaucitron_installer_service.php#L36). C'est mieux comme ça ?
Owner

Je remets ma réponse d'IRC :

En gros si j'ai bien compris, tu as 4 possibilités selon que les fichiers que tu veux écrire doivent être permanents ou non / accessibles ou non (dans le navigateur ou autre)
Et les 4 possibilités correspondent à 4 constantes qui donnent le bon dossier

Donc comme disait @rastapopoulos, surtout pas dans le dossier squelettes :)

En résumant :

  1. _NOM_PERMANENTS_INACCESSIBLES : dossier config/ pour les fichiers permanents et non accessibles
  2. _NOM_PERMANENTS_ACCESSIBLES : dossier IMG/ pour les fichiers permanents et accessibles (des images, mais pas que)
  3. _NOM_TEMPORAIRES_INACCESSIBLES : dossier tmp/ pour les fichiers temporaires et non accessibles (logs, cache, etc.)
  4. _NOM_TEMPORAIRES_ACCESSIBLES : dossier local/ pour les fichiers temporaires et accessibles (copies des images transformées automatiquement, etc.)

Ton cas de figure semble correspondre au 1)

Je remets ma réponse d'IRC : > En gros si j'ai bien compris, tu as 4 possibilités selon que les fichiers que tu veux écrire doivent être permanents ou non / accessibles ou non (dans le navigateur ou autre) > Et les 4 possibilités correspondent à 4 constantes qui donnent le bon dossier Donc comme disait @rastapopoulos, surtout pas dans le dossier squelettes :) En résumant : 1. [_NOM_PERMANENTS_INACCESSIBLES](https://www.spip.net/fr_article4638.html) : dossier **config/** pour les fichiers permanents et non accessibles 2. [_NOM_PERMANENTS_ACCESSIBLES](https://www.spip.net/fr_article4639.html) : dossier **IMG/** pour les fichiers permanents et accessibles (des images, mais pas que) 3. [_NOM_TEMPORAIRES_INACCESSIBLES](https://www.spip.net/fr_article4636.html) : dossier **tmp/** pour les fichiers temporaires et non accessibles (logs, cache, etc.) 4. [_NOM_TEMPORAIRES_ACCESSIBLES](https://www.spip.net/fr_article4638.html#_NOM_PERMANENTS_ACCESSIBLES) : dossier **local/** pour les fichiers temporaires et accessibles (copies des images transformées automatiquement, etc.) Ton cas de figure semble correspondre au 1)
Poster
Collaborator

OK. Dans ce cas, faut rajouter le dossier config dans le path avec :
$GLOBALS['dossier_squelettes'] .= ":" . _NOM_PERMANENTS_INACCESSIBLES . "tarteaucitron"; ?

OK. Dans ce cas, faut rajouter le dossier config dans le path avec : `$GLOBALS['dossier_squelettes'] .= ":" . _NOM_PERMANENTS_INACCESSIBLES . "tarteaucitron";` ?

En fait je ne comprends pas ce que cet ajout cherche à faire (je n'ai pas lu ligne par ligne le détail du code), il faudrait décrire un peu plus. En effet, si c'est pour ajouter dynamiquement du code JS suivant ce qu'on décide d'activer comme service, pourquoi diable est-ce qu'il faudrait ajouter des squelettes pour ça ? Il vaut bien mieux injecter du JS dynamiquement pas du tout en squelette, directement dans les pipelines dédiés au javascript, du genre "insert_head", il me semble. Faire compiler des JS juste pour ajouter une pauvre ligne de JS…

De plus, si c'est ajouté et supprimé par le plugin, je ne vois pas trop pourquoi les fichiers seraient "possiblement éditables" par les webmestres sur le serveur. Normalement soit ya des fichiers "appartenant" aux proprios du site (squelettes, mes_options, etc), mais que donc le logiciel (core ou plugin) n'a jamais le droit de supprimer lui-même, soit c'est des fichiers ajoutés par le plugin mais dans ce cas qui ne sont pas à éditer par les gens directement. Je n'ai pas souvenir d'exemples mélangeant les deux comme ça dans la communauté.

Mais pour recommander au mieux une bonne pratique ou pour discuter ensemble de la conception, il faudrait que je comprenne mieux ce que tu cherches à faire.

En fait je ne comprends pas ce que cet ajout cherche à faire (je n'ai pas lu ligne par ligne le détail du code), il faudrait décrire un peu plus. En effet, si c'est pour ajouter dynamiquement du code JS suivant ce qu'on décide d'activer comme service, pourquoi diable est-ce qu'il faudrait ajouter *des squelettes* pour ça ? Il vaut bien mieux injecter du JS dynamiquement pas du tout en squelette, directement dans les pipelines dédiés au javascript, du genre "insert_head", il me semble. Faire compiler des JS juste pour ajouter une pauvre ligne de JS… De plus, si c'est ajouté et supprimé par le plugin, je ne vois pas trop pourquoi les fichiers seraient "possiblement éditables" par les webmestres sur le serveur. Normalement soit ya des fichiers "appartenant" aux proprios du site (squelettes, mes_options, etc), mais que donc le logiciel (core ou plugin) n'a *jamais* le droit de supprimer lui-même, soit c'est des fichiers ajoutés par le plugin mais dans ce cas qui ne sont pas à éditer par les gens directement. Je n'ai pas souvenir d'exemples mélangeant les deux comme ça dans la communauté. Mais pour recommander au mieux une bonne pratique ou pour discuter ensemble de la conception, il faudrait que je comprenne mieux ce que tu cherches à faire.
Poster
Collaborator

De base, le plugin intègre effectivement les services en JS, ligne par ligne, grace à des squelettes situés dans ./services. J'ai gardé ce comportement jusqu'alors. Donc quand on installe un service, mon code crée le fichier ./services/monservice.html. Or, pour les services nécessitant une APIkey, il faut parfois adapter ce fichier.

De plus, pour faciliter l'intégration des services par les rédacteurs d'articles, j'ai ajouté des modèles utilisables par le porte-plume. Lors de l'installattion d'un service ce fichier est généré (mais vide) car ce modèle varie suivant le service. Je n'ai pas trouvé de moyen de récupérer automatiquement ce modèle car il varie d'un service à l'autre (peu-être en scrappant la page (https://tarteaucitron.io/fr/install/).

De base, le plugin intègre effectivement les services en JS, ligne par ligne, grace à des squelettes situés dans ./services. J'ai gardé ce comportement jusqu'alors. Donc quand on installe un service, mon code crée le fichier ./services/monservice.html. Or, pour les services nécessitant une APIkey, il faut parfois adapter ce fichier. De plus, pour faciliter l'intégration des services par les rédacteurs d'articles, j'ai ajouté des modèles utilisables par le porte-plume. Lors de l'installattion d'un service ce fichier est généré (mais vide) car ce modèle varie suivant le service. Je n'ai pas trouvé de moyen de récupérer automatiquement ce modèle car il varie d'un service à l'autre (peu-être en scrappant la page (https://tarteaucitron.io/fr/install/).
paidge added 2 commits 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
Poster
Collaborator

Or, pour les services nécessitant une APIkey, il faut parfois adapter ce fichier.

Ce n'est plus nécessaire désormais. Le plugin permet maintenant de renseigner les paramètres nécessaires qui seront pris en compte pour l'activaion des services (APIkey, IDuser, etc.) de manière automatique.

Pour les modèles à insérer via le porte-plume, il faut toujours les éditer à la main suivant les services. En effet, l'intégration diffère d'un service à l'autre et il n'est pas toujours nécessaire d'avoir un modèle (ex : les services de pub ou d'analytics).

Pour ce qui est de l'endroit où écrire ces fichiers, le plugin écrit pour le moment dans son propre répertoire, en attendant une meilleure suggestion.

> Or, pour les services nécessitant une APIkey, il faut parfois adapter ce fichier. Ce n'est plus nécessaire désormais. Le plugin permet maintenant de renseigner les paramètres nécessaires qui seront pris en compte pour l'activaion des services (APIkey, IDuser, etc.) de manière automatique. Pour les modèles à insérer via le porte-plume, il faut toujours les éditer à la main suivant les services. En effet, l'intégration diffère d'un service à l'autre et il n'est pas toujours nécessaire d'avoir un modèle (ex : les services de pub ou d'analytics). Pour ce qui est de l'endroit où écrire ces fichiers, le plugin écrit pour le moment dans son propre répertoire, en attendant une meilleure suggestion.

Je ne saisis toujours pas trop pourquoi il faudrait écrire des fichiers. Si ya des modèles prévus connus, bah faut les mettre dans modeles du plugin directement, et pour ce qui est de l'aide par interface il peut y avoir une config permettant de choisir lesquels on veut lister dans l'interface (ou tous par défaut et inversement lesquels on veut masquer).

Je ne saisis toujours pas trop pourquoi il faudrait écrire des fichiers. Si ya des modèles prévus connus, bah faut les mettre dans modeles du plugin directement, et pour ce qui est de l'aide par interface il peut y avoir une config permettant de choisir lesquels on veut lister dans l'interface (ou tous par défaut et inversement lesquels on veut masquer).
paidge added 1 commit 2 months ago
Poster
Collaborator

Le plugin n'écrit plus de fichier.

Lors d'une MAJ de la librairie tarteaucitron.js dans le plugin, le développeur exécute ?action=tarteaucitron_referencer_services ce qui met à jour le fichier json/services.json.
Ce fichier recense les services et, pour chaque service, son type, ses paramètres et le code JS associé (récupéré en scrappant la page https://tarteaucitron.io/fr/install/).

Lorsque le webmestre active un service, cela crée une entrée dans #CONFIG{tarteaucitron/services} pour le service en question et son/ses paramètre(s) éventuel(s), ce qui permet au webmestre de saisir le(s) paramètre(s) éventuel(s) du service.

Le code JS de chaque service activé est inséré via le pipeline tarteaucitron_affichage_final($html). => Adieu les squelettes services/monservice.html !

Pour les services nécessitant des iframes (youtube, soundcloud, vimeo, dailymotion, etc.) le rédacteur peut les insérer directement via le porte-plume. Si un service manque, il faudra créer une issue ou une pull-request afin qu'un contributeur puisse les rajouter (il suffira alors de créer un fichier modeles/tac_monservice.html et une icône carrée dans icones_barre/monservice.png en 17px de côté).

Pour les articles antérieurs contenant des iframes, il y a toujours le script récupéré dans le plugin Oembed.

Toutes les infos sont dans le README.

Le plugin n'écrit plus de fichier. Lors d'une MAJ de la librairie **tarteaucitron.js** dans le plugin, le développeur exécute **?action=tarteaucitron_referencer_services** ce qui met à jour le fichier **json/services.json**. Ce fichier recense les services et, pour chaque service, son type, ses paramètres et le code JS associé (récupéré en scrappant la page https://tarteaucitron.io/fr/install/). Lorsque le webmestre active un service, cela crée une entrée dans #CONFIG{tarteaucitron/services} pour le service en question et son/ses paramètre(s) éventuel(s), ce qui permet au webmestre de saisir le(s) paramètre(s) éventuel(s) du service. Le code JS de chaque service activé est inséré via le pipeline **tarteaucitron_affichage_final($html)**. => Adieu les squelettes **services/monservice.html** ! Pour les services nécessitant des iframes (youtube, soundcloud, vimeo, dailymotion, etc.) le rédacteur peut les insérer directement via le porte-plume. Si un service manque, il faudra créer une issue ou une pull-request afin qu'un contributeur puisse les rajouter (il suffira alors de créer un fichier **modeles/tac_monservice.html** et une icône carrée dans **icones_barre/monservice.png** en 17px de côté). Pour les articles antérieurs contenant des iframes, il y a toujours [le script récupéré dans le plugin Oembed](/spip-contrib-extensions/tarteaucitron/src/branch/dev/ajouter_services_auto/action/tarteaucitron_nettoyer_iframes.php). Toutes les infos sont dans le [README](/spip-contrib-extensions/tarteaucitron/src/branch/dev/ajouter_services_auto/README.md).
Collaborator

Salut @paidge ! Sacré boulot a priori que tu mènes là :)

Par contre, j'ai un message d'avertissement:

Warning
: Invalid argument supplied for foreach() in
/home/bbrice/webdev/spipmomh/plugins/tarteaucitron/tarteaucitron_pipelines.php
on line
59

Et je reviens encore à Matomo : on a besoin d'ajouter l'URL de l'instance de Matomo ; avec le seul identifiant, ça ne suffit pas...

Salut @paidge ! Sacré boulot a priori que tu mènes là :) Par contre, j'ai un message d'avertissement: > Warning : Invalid argument supplied for foreach() in /home/bbrice/webdev/spipmomh/plugins/tarteaucitron/tarteaucitron_pipelines.php on line 59 Et je reviens encore à Matomo : on a besoin d'ajouter l'URL de l'instance de Matomo ; avec le seul identifiant, ça ne suffit pas...
Poster
Collaborator

Je regarderai pour Matomo. Tu as cette erreur sur les pages publiques du site ? Tu as les warnings activés ? Je n'ai rien eu sur mon environnement de dev.

Je regarderai pour Matomo. Tu as cette erreur sur les pages publiques du site ? Tu as les warnings activés ? Je n'ai rien eu sur mon environnement de dev.

Bravo ! Ça me parait carrément mieux qu'avant, avec enfin un fonctionnement générique qui autorise l'ensemble des services connus de Tarteaucitron sans rien coder soi-même !

Bravo ! Ça me parait carrément mieux qu'avant, avec enfin un fonctionnement générique qui autorise l'ensemble des services connus de Tarteaucitron sans rien coder soi-même !
Collaborator

@paidge oui, sur les pages publiques du site avec un PHP 7.4.21.

@paidge oui, sur les pages publiques du site avec un PHP 7.4.21.
Poster
Collaborator

Merci pour les retours.

Je n'ai pas testé mais a priori c'est parce que je fais un foreach sur un tableau vide. Ce sera juste un if(is_array($params)) à rajouter.

Pour Matomo, c'est normal. C'est à toi de remplacer (Etape 4 du README que je vais compléter. Je savais qu'il manquait qqe chose :p ) :

<script type="text/javascript">
  var _paq = _paq || [];
  _paq.push(['trackPageView']);
  _paq.push(['enableLinkTracking']);
  (function() {
    var u="YOUR_MATOMO_URL";
    _paq.push(['setTrackerUrl', u+'piwik.php']);
    _paq.push(['setSiteId', SITE_ID]);
    var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
    g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
  })();
</script>

Par :
<script>tarteaucitron.user.matomoHost = 'YOUR_MATOMO_URL';</script>

A voir où tu l'as placé si c'est dans un squelette ou dans un insert_head ou autre.

Merci pour les retours. Je n'ai pas testé mais a priori c'est parce que je fais un foreach sur un tableau vide. Ce sera juste un `if(is_array($params))` à rajouter. Pour Matomo, c'est normal. C'est à toi de remplacer (Etape 4 du README que je vais compléter. Je savais qu'il manquait qqe chose :p ) : ``` <script type="text/javascript"> var _paq = _paq || []; _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="YOUR_MATOMO_URL"; _paq.push(['setTrackerUrl', u+'piwik.php']); _paq.push(['setSiteId', SITE_ID]); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s); })(); </script> ``` Par : `<script>tarteaucitron.user.matomoHost = 'YOUR_MATOMO_URL';</script>` A voir où tu l'as placé si c'est dans un squelette ou dans un insert_head ou autre.
Collaborator

@paidge je sais bien ce que dit la documentation de tarteaucitron.js... Cependant, il me semble que ce serait plus intéressant/pertinent de pouvoir insérer cette ligne de JS via le plugin, afin d'avoir une gestion centralisée et unifiée de Matomo.

@paidge je sais bien ce que dit la documentation de tarteaucitron.js... Cependant, il me semble que ce serait plus intéressant/pertinent de pouvoir insérer cette ligne de JS via le plugin, afin d'avoir une gestion centralisée et unifiée de Matomo.
paidge added 2 commits 2 months ago
paidge added 1 commit 2 months ago
Poster
Collaborator

Désormais, le script ?action=tarteaucitron_referencer_services (à lancer par le développeur), met à jour non seulement le .json référençant l'ensemble des services mais aussi la liste des modèles du plugin pour les services qui en ont besoin. C'est pourquoi le plugin est livré directement avec 75 modèles. Il est possible de les surcharger dans /squelettes/modeles/tac_service.html

Pour les ajouter dans le porte-plume, il suffira de créer une icône /squelettes/icones_barre/service.png de 17px de côté. Il est possible que certains services nécessitent une adapation (qui seront traitées au fur et à mesure des issues) mais ça fonctionne très bien dans l'état pour la majorité des services.

@bricebou, essaie avec Matomo. Ca devrait fonctionner suivant tes attentes.

Désormais, le script **?action=tarteaucitron_referencer_services** (à lancer par le développeur), met à jour non seulement le .json référençant l'ensemble des services mais aussi la liste des modèles du plugin pour les services qui en ont besoin. C'est pourquoi le plugin est livré directement avec 75 modèles. Il est possible de les surcharger dans ***/squelettes/modeles/tac_service.html*** Pour les ajouter dans le porte-plume, il suffira de créer une icône ***/squelettes/icones_barre/service.png*** de 17px de côté. Il est possible que certains services nécessitent une adapation (qui seront traitées au fur et à mesure des issues) mais ça fonctionne très bien dans l'état pour la majorité des services. @bricebou, essaie avec Matomo. Ca devrait fonctionner suivant tes attentes.
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
Poster
Collaborator

Je pense avoir fini les développements, même s'il est sûrement possible d'améliorer un peu le code. A la demande de @peetdu, voici un début de documentation.

Je pense avoir fini les développements, même s'il est sûrement possible d'améliorer un peu le code. A la demande de @peetdu, voici [un début de documentation](/spip-contrib-extensions/tarteaucitron/wiki/Nouvelle-feature-%3A-ajouter-des-services).
paidge added 2 commits 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
Poster
Collaborator

Après plusieurs jours de fouilles dans les doc et compléments de docs pour pouvoir remplacer le sélecteur de documents par un input[type='file'], j'ai enfin réussi à faire ce que je voulais. Je n'ai plus rien dans ma roadmap pour ce plugin, a priori, si ce n'est corriger des bugs.

Après plusieurs jours de fouilles dans les doc et compléments de docs pour pouvoir remplacer le sélecteur de documents par un input[type='file'], j'ai enfin réussi à faire ce que je voulais. Je n'ai plus rien dans ma roadmap pour ce plugin, a priori, si ce n'est corriger des bugs.

Je ne vois toujours pas pourquoi tu fais un champ à part et tu recodes toi-même des vérifications etc, alors que la saisie "fichier" permet aussi une vérification "fichiers" avec plein de vérifs possibles avec la syntaxe simple en 2 ou 3 lignes de déclaration comme les autres saisies :
https://git.spip.net/spip-contrib-extensions/verifier/src/branch/master/verifier/fichiers.php

En plus là du coup ça fait un mélange avec une partie en saisies PHP et une autre avec un champ "tout à la main".

Par ailleurs, je n'ai pas compris pourquoi une icône serait forcément du PNG. Ça peut être n'importe quelle image normalement, JPG, SVG…

Aussi, spécifiquement pour le cas "form de config", j'avais fait un ticket noyau ya 6 mois : spip/spip#4740

Et en attendant bah faut gérer le stockage soi-même, et pour Webmanifest moi j'avais fait ça sans même un champ "fichier" de cvt-upload mais juste un simple champ input file EN SAISIE quand même :
https://git.spip.net/spip-contrib-extensions/webmanifest/src/branch/master/formulaires/configurer_webmanifest.php#L20

Et le traiter :
https://git.spip.net/spip-contrib-extensions/webmanifest/src/branch/master/formulaires/configurer_webmanifest.php#L97

Beaucoup moins à gérer soi-même malgré tout…

Je ne vois toujours pas pourquoi tu fais un champ à part et tu recodes toi-même des vérifications etc, alors que la saisie "fichier" permet aussi une vérification "fichiers" avec plein de vérifs possibles avec la syntaxe simple en 2 ou 3 lignes de déclaration comme les autres saisies : https://git.spip.net/spip-contrib-extensions/verifier/src/branch/master/verifier/fichiers.php En plus là du coup ça fait un mélange avec une partie en saisies PHP et une autre avec un champ "tout à la main". Par ailleurs, je n'ai pas compris pourquoi une icône serait forcément du PNG. Ça peut être n'importe quelle image normalement, JPG, SVG… Aussi, spécifiquement pour le cas "form de config", j'avais fait un ticket noyau ya 6 mois : https://git.spip.net/spip/spip/issues/4740 Et en attendant bah faut gérer le stockage soi-même, et pour Webmanifest moi j'avais fait ça sans même un champ "fichier" de cvt-upload mais juste un simple champ input file EN SAISIE quand même : https://git.spip.net/spip-contrib-extensions/webmanifest/src/branch/master/formulaires/configurer_webmanifest.php#L20 Et le traiter : https://git.spip.net/spip-contrib-extensions/webmanifest/src/branch/master/formulaires/configurer_webmanifest.php#L97 Beaucoup moins à gérer soi-même malgré tout…
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
Poster
Collaborator

J'avais fait un champ à part pour obtenir le même résultat que sur le formulaire configurer_ecran_connexion. Mais c'est clair que le code faisait un peu crade.

Du coup, j'ai créé un fichier saisies/tac_upload.html pour obtenir le résultat souhaité.

J'avais fait un champ à part pour obtenir le même résultat que sur le formulaire `configurer_ecran_connexion`. Mais c'est clair que le code faisait un peu crade. Du coup, j'ai créé un fichier **saisies/tac_upload.html** pour obtenir le résultat souhaité.
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
paidge added 1 commit 2 months ago
Poster
Collaborator

Suite aux échanges sur IRC, j'ai mergé la branche avec master après un rebase pour prendre en compte les modifications de @Pierretux. Je ferme donc cette demande de fusion.

Suite aux échanges sur IRC, j'ai mergé la branche avec master après un rebase pour prendre en compte les modifications de @Pierretux. Je ferme donc cette demande de fusion.
paidge closed this pull request 2 months ago
paidge deleted branch dev/ajouter_services_auto 2 months ago
This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.