# DON'T BE A DICK PUBLIC LICENSE
> Version 1.1, December 2016
> Copyright (C) [year] [fullname]
Everyone is permitted to copy and distribute verbatim or modified
copies of this license document.
> DON'T BE A DICK PUBLIC LICENSE
> TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
1. Do whatever you like with the original work, just don't be a dick.
Being a dick includes - but is not limited to - the following instances:
1a. Outright copyright infringement - Don't just copy this and change the name.
1b. Selling the unmodified original with no work done what-so-ever, that's REALLY being a dick.
1c. Modifying the original work to contain hidden harmful content. That would make you a PROPER dick.
2. If you become rich through modifications, related works/services, or supporting the original work,
share the love. Only a dick would make loads off this work and not buy the original work's
creator(s) a pint.
3. Code is provided with no warranty. Using somebody else's code and bitching when it goes wrong makes
you a DONKEY dick. Fix the problem yourself. A non-dick would submit the fix back.
Merci à https://nicolas-delsaux.hd.free.fr/Shaarli/?X31NQQ
Donc, c'est une extension pour VSCode qui est censée générer la doc d'une fonction ou d'une méthode automatiquement, toute seule et en un seul clic.
Taquin, j'ai testé avec des méthodes tirées d'applis à moi et ben franchement, elle s'en sort vraiment pas mal !
Elle s'avère capable d'interpréter plutôt bien le code sélectionné:
elle a par exemple «compris» la méthode insertValue() de mon framework et a déduit qu'elle servait à insérer des valeurs dans un template
ou la méthode getVar() dont elle a saisi le but et la logique
voire la méthode ifLoggedRender() dont elle a même compris le paramètre $echo !
Plus fort ?!
Le test a été poussé avec des méthodes moins évidentes pour une machine mais plus pour un humain, comme une méthode destinée à renvoyer le pluriel d'un nom en espagnol, pour laquelle AIDoc déduit la règle grammaticale pratiquement au mot près !
ou la méthode consonne():
et même la méthode estarGerondif() pour retourner la forme progressive d'un verbe en espagnol qu'AIDoc a comprise (identifiant la forme grammaticale «present tense» !!!)
autres exemples
Conclusion
Ça marche tellement bien que je vois une autre utilisation au truc: t'expliquer à quoi servait ton code quand tu y reviens trois semaines plus tard et que t'y comprends plus rien ...
Et allez, encore une matinée de perdue pour un truc que j'avais pas prévu et qui devrait fonctionner parfaitement: la balise <video> et la balise <track> pour ajouter les sous-titres.
Pour afficher une video pour les élèves avec les sous-titres que j'ai traduit de youtube, en gros, je fais un truc comme ça:
En passant, je vous mets le lien vers un petit outil pour convertie en et de Base64.
Bon, yen a plein, hein, en particulier celui de Timo ... J'en ai quand même refait un from scratch pour pouvoir l'utiliser comme une appli online (le front end ci-dessous) ou bien comme une «API» utilisable via un bookmarklet par exemple: ainsi, en sélectionnant du texte puis en lançant le bookmarklet qui va bien, on peut encoder/décoder en un clic...
Dans Cpanel, il y a une option activée par défaut, c'est le module ModSecurity qui est là précisément pour kéblo les requêtes un peu... comment dire... originales ? exotiques ? Bref, exactement celles que semble faire Plinstagram.
Bon, je bosse dessus parce que je suis entêté et que j'aime bien comprendre mais là... j'ai du mal.
Ce que j'ai fait
Côté frontend
J'ai épuré mon code JS au max
j'ai simplifié le formulaire en laissant tomber les noms de fichier: je n'envoie que le contenu de l'image en base64 et je génère un nom backend.
j'ai changé l'ajout des hidden servant à transmettre les images au format base64: au lieu de les ajouter au fur et à mesure de la génération des images redimensionnées, je les crée dans l'événement onSubmit du formulaire.
j'ai essayé de virer l'enctype du formulaire vu que, avec l'URL_rewriting à off j'obtenais une erreur 406 en distant... J'ai même essayé en text/plain pour voir... C'est pas ça.
côté backend
j'ai simplifié au max
j'ai ajouté la création d'un nom de fichier local (l'extension est déduite des données base64 qui démarrent comme suit: base64:image/jpeg ...)
j'ai regardé, en local, la taille des données envoyées:
Je sais, on a l'impression que c'est toujours la même image mais en fait non... c'est sans doute dû au fait que base64 est très verbeux et que le début est toujours le même pour des images.
Le tout fait un post d'environ 4.5 Mo ce qui n'est pas choquant dans un formulaire multipart/form-data et reste très en dessous des limites de PHP_INI sur le serveur.
Aucun fichier .htaccess ne vient non plus foutre le bran...
HELP
Encore une fois, ça marche impeccable en local.
J'ai commenté au max mon code pour le cas où quelqu'un se sent de regarder, parce que pour ma part, je commence à voir flou et à avoir des hallucinations... je vous mets un zip: http://warriordudimanche.net/vrac/Plinstagram.zip
Je me suis aperçu que mon plugin Plinstagram faisait des trucs étranges et refusait parfois de poster. Pensant à une erreur d'identification, j'ai repris le code mais rien n'y faisait.
Une fois la ruse très moche appliquée, ça semblait revenu à la normale. Puis j'ai décidé d'aller marcher un peu et j'ai pris des photos dans l'idée de tester à nouveau Plinstagram.
Et là, c'est le drame
J'ai beau tout essayer, pas moyen d'envoyer le post avec les photos... mais curieusement, j'aboutis à une erreur 404 et pas à une erreur d'exécution.
Je me dis que ça doit être un problème de taille de formulaire et je me rappelle que, comme un con, j'ai omis de virer l'input files du formulaire avant envoi.
J'explique rapidement comment fonctionne Plinstagram:
Côté JS
1 - l'utilisateur sélectionne des photos sur son ordinateur
2 - pour chaque image, le script js se charge de:
récupérer les images sélectionnées,
créer une miniature avec un canvas
stocker l'image réduite sous forme de donnée base64 dans un input hidden (avec le nom de fichier dans un autre input hidden) créés à la volée
Ainsi on obtient un $_POST[data] et un $_POST[filename] qui contiennent chacun un tableau avec les données de chaque image pour l'un et le nom de chaque image pour l'autre.
Quand on poste, le script vire l'input file pour éviter l'upload de grosses photos.
Côté PHP
Vient ensuite le hook AdminArticlePrepend de la page core/admin/article.php vers laquelle pointe le formulaire de plinstagram: celui-ci se charge de :
1 - parcourir l'array des images redimensionnées postées en base64,
2 - récupérer le nom de chaque image
3 - sauvegarder localement chaque image dans un sous-dossier dédié à l'article
4 - générer une galerie qu'il ajoute au corps du post
5 - finaliser la création des données de l'article.
À ce moment-là pluXML reprend la main et s'occupe du stockage de ces données.
Quand je teste en distant (sur WDD)
Avec une photo, tout se passe normalement. Si j'en mets ne serait-ce que deux, pluXML me renvoie à la page 404, comme si l'URL était fausse: or, il n'en est rien ! L'URL de la barre d'adresse est la bonne, celle du formulaire aussi... pourtant, avec plus d'une photo, la requête n'arrive jamais à core/admin/article.php
Pire, une fois sur la page 404, si je clique dans la barre d'adresse puis que j'appuie sur entrée, j'arrive sans encombre à la page voulue (mais sans les données de formulaire bien entendu): l'URL est donc bonne.
J'ai pensé à une redirection foireuse mais la seule redirection qui reste est celle qui se fait AVANT le formulaire et seulement dans le cas où l'utilisateur n'est pas connecté.
Et puis ça ne semble pas être la faute de mon script PHP vu qu'on n'arrive même pas jusqu'à lui (j'ai collé des exit('moncul'); partout pour voir et rien !)
Quand je teste en local... ô surprise!
TOUT FONCTIONNE SANS PROBLEME ! (le fameux «ça marche sur mon ordi»)
J'ai pensé à un problème de version de PHP: j'ai essayé de changer et c'est pas ça
j'ai songé à une limite de la taille de fichiers ou la limite de taille de post... c'est pas ça (puis ça générerait une erreur, pas un pseudo 404)
Pour résumer
Conclusion
J'en suis à me dire qu'il doit y avoir un genre de restriction pour la taille des données contenues dans des inputs et que cette restriction ne doit pas être la même en local.
Une autre piste que je dois explorer est une éventuelle incompatibilité entre deux plugins... Mais je vois pas lesquels et pis là, faut que j'aille pleurer d'abord.
EDIT dix minutes plus tard:
Tiens, la différence entre le local et le distant, c'est la configuration du rewrite URL dans pluXML: activée en distant. Je mets sur OFF et là, j'obtiens une erreur 406:
Not Acceptable: An appropriate representation of the requested resource could not be found on this server.
Pour SnippetVamp, j'ai refait une version from scratch récemment en utilisant mon framework perso, un peu pour le tester.
Cette version utilise SQLite pour le stockage des snippets, possède un meilleur moteur de recherche et s'avère plus rapide.
Par contre, ce n'est pas la version sur github: tenir tous mes dépôts github à jour me prenait trop de temps et je trouve ça trop compliqué pour mon usage, j'ai lâché l'affaire.
Si certains sont intéressés, je peux mettre cette version à disposition de qui n'en veut ...
Merci copain ! J'ai beaucoup bossé sur Helium et ça m'a permis d'évoluer (beaucoup) dans ma façon de coder et d'envisager les applis que je fais:
avant, je partais du principe tout from scratch et en mode structure minimaliste et peu de fichiers (one script si possible)... le souci majeur étant que tu passes ton temps à réinventer la roue ou à essayer de faire coller tes briques de codes entre-elles...
Avec Helium, je pars d'un environnement cohérent et j'ajoute la logique de l'appli, les templates de l'appli, le style de l'appli le tout dans un dossier spécifique. Si j'ai besoin de nouveaux ajouts qui me semblent dignes d'être pérennisés, je les intègre au framework.
Le résultat est plus cohérent, plus simple à mettre à jour, plus cloisonné, plus rapide à mettre en oeuvre (en général )
Tu me diras, pourquoi pas un framework existant ? Ben parce que j'adore coder et qu'on n'apprend pas un langage en utilisant les frameworks mais en mettant les doigts dans le cambouis et en se grattant la tête pour savoir comment faire ou pourquoi ça ne marche pas
J'adore Mastodon : tu suis quelqu'un parce que tu l'as trouvé drôle et tu apprends qu'il a un blog sur le javascript qu'il partage parce que « il se dit qu'il ne doit pas être le seul javascripteur sur la planète.»
Si vous vous dites, mouais encore un blog sur JS, gardez à l'esprit que voilà un bloggueur qui intitule un billet «jQuery doit mourir», qui écrit qu'XMLHttpRequest est «inutilement compliqué» mais que dieu merci on a créé fetch, même si on ne comprend pas toujours bien ce qu'il renvoie...
Le souci avec les CMS en général - et pluXML en particulier - c'est l'usage sur mobile: poster un article, même rapide ou schématique, reste un parcours du combattant dès qu'on doit se passer du combo clavier-souris-grand écran.
Par conséquent, adieu le post vite fait façon microblogging, goodbye la petite photo partagée fissa sur insta, arrivederci le meme envoyé aux copains vite fait sur le gaz...
Tu proposes quoi, cousin ?
Je me suis penché sur la question avec le cahier des charges suivant:
facile à utiliser et clair sur mobile
possibilité de poster une ou plusieurs photos
possibilité de poster une photo capturée via la caméra (façon insta)
redimensionnement automatique des photos côté client: parce que poster des tofs de 10Mo en 8K avec des réseaux 3G, je vois pas l'intérêt
pourquoi pas des filtres comme sur «insta»
Le plug-in
Une fois activé le plugin ajoute:
une catégorie Plinstagram
un lien sur la page de profil, un peu comme le bookmarklet de Weblinks. Ce lien est celui de la page servant à poster dans la catégorie Plinstagram.
une page de configuration du plugin (très sommaire, je l'admets).
On peut y configurer notamment la taille maximale des photos (par défaut 1200px)
Le lien pointe vers une page générée par le plugin
On y retrouve un placeholder d'image sur lequel cliquer pour sélectionner des images à envoyer ou prendre une photo. La première photo devient automatiquement la photo de titre et les autres figureront à la fin du post sous forme de galerie minimaliste.
A noter :
si vous voulez placer en titre une autre des images sélectionnées, il suffit de cliquer dessus.
les photos sélectionnées sont automatiquement redimensionnées pour ne pas dépasser la limite fixée en config.
lors de la capture d'image via l'appareil photo sur android, l'orientation de la photo est parfois... fantaisiste.
vous pouvez choisir de créer le post mais sans le publier en cliquant sur la disquette
si vous allez sur la page de post sans être loggé, Plinstagram redirige vers la page de login puis revient sur la page de post automatiquement après identification.
quand vous êtes en train de taper le titre du post, un appui sur la touche entrée donne le focus au textarea dessous (une manip de moins sous android)
petit truc en plus, comme le redimensionnement passe par canvas, les données exif sont virées des photos
Vous pouvez sélectionner un filtre à appliquer sur [toutes] les photos
[*] qu'une seule personne a pu tester ce qui fait de cette BD une private joke.
Au final ça donne ça
Avec ma maquette, hein... je vais pas tout faire non plus !
Conclusion
Il reste sans doute plein de trucs à améliorer (gestion de la rotation des photos, maquette, test sur tous les supports etc) et des bugs à débusquer (j'en ai trouvé un pas méchant en écrivant ce billet) mais, selon le dicton favori des programmeurs:
Dans la rubrique «je bosse une grosse fois pis c'est bon» j'ai eu besoin de pouvoir faire rapidement une page de révision de vocabulaire pour mes élèves; mais quand je dis rapidement, je veux que ce soit fissa avec une friction proche de zéro et sans avoir recours à une appli à la con: copier coller un lien dans l'ENT doit suffire.
J'ai donc opté pour les flashcards, qui sont très efficaces dans ce domaine et j'ai codé un truc vite fait qui ne représente pas une prise de tête quand on veut donner du boulot aux gamins.
En gros, tu écris les mots à apprendre sous la forme
question1:réponse1, question2:réponse2,...
puis tu récupères la page avec le lien à utiliser.
Sur la page, tu cliques sur la carte et elle se retourne.
Je me suis aperçu récemment de l'existence de la balise details et je me suis dit que je pourrais me noter celles qui me feraient de l'usage dans un éventuel avenir.
<details>
L'élément HTML details sert à créer une ligne de résumé permettant de révéler plus d'informations sur un clic.
L'attribut [open] permet de styler l'ensemble lorsqu'il est ouvert.
<style>
details{font-style:italic;cursor:pointer}
details:after summary{content:"▶"}
details[open]:after summary{content:"▼"}
details p{margin-left: 25px}
</style>
<details>
<summary>Ligne de résumé.</summary>
<p>Tout plein de détails extrêmement intéressants pour ceux qui veulent mais inutiles pour les autres...</p>
</details>
Ligne de résumé.
Tout plein de détails extrêmement intéressants pour ceux qui veulent mais inutiles pour les autres...
La balise data permet d'ajouter une valeur interprétable par une machine à une valeur lisible par un humain: plus simplement, on peut relier le nom d'un produit à son ID dans la base de données par exemple.
Crée une jolie jauge dont on définit le remplissage afin de représenter visuellement une proportion. Elle utilise les mêmes attributs qu'input number (min, max, value) et y ajoute high, low et optimum qui définissent respectivement à partir de quel nombre la valeur est haute ou basse ainsi que la valeur considérée comme optimale.
Il faudra prévoir l'affichage de la valeur courante (et cette balise n'accepte pas les pseudo-éléments before et after)
<meter value="2" min="0" max="10" low="2">2 out of 10</meter>
meter value="0.6">60%