yAronet passe open-source - Page 2

Aucune urgence, surtout que chezmoiçamarche ©

En attendant j'ai retiré le lien vers IRC et les références à la section bug, il ne devrait plus rester beaucoup de choses liées à www.yaronet.com dans le code.

[edit] en fait si, il reste des références dans certains textes comme le message d'accueil qui s'affiche sur la page principale quand on est pas connecté, je changerai ça également.

Alors oui ça le fait toujours, je vais essayer de tracer ce qui se passse ( il faut que je réactive les logs et warning sur les pages)

Edit: voila trouve:

/home/godzil/public_html/yn/entity/account/user.php:231
hash_hmac(): Non-cryptographic hashing algorithm: crc32b

Ca pourrait etre configure dans config.php ca non?
pourquoi il ne connais pas crc32b, je ne sais pas.
3s de google plus tard:
7.2.0 L'utilisation de fonctions de hachage non cryptographiques (adler32, crc32, crc32b, fnv132, fnv1a32, fnv164, fnv1a64, joaat) a été désactivée.

C est sympa quand meme de desactiver comme ca des outils qui peuvent avoir des utilisations plus que legitimes...



Au passage, bug cosmétique mais si le captcha n’est pas activé, la page pour réinitialiser le mot de passe depuis son addresse email affiche le texte à gauche, mais bien sûr il est correctement ignoré

Et voila un pull request

C'est un peu brut, mais j'ai testé en local et semble marcher.
Je n'ai pas vérifié en base si un des changement ne pose pas de problemes, mais vu que la procedure a marché je pense que non.

Arf joli exemple de combo "API stringly-typed" + "rien à foutre de la rétrocompatibilité"

Merci pour l'analyse et la PR, je réponds sur GitHub du coup

[edit] Pour le captcha, en effet il devient invisible quand on utilise yN depuis une adresse privée (par exemple 127.0.0.1) mais pas quand on a simplement désactivé la feature, ce qui n'est pas très logique. Je vais corriger ça c'est fait

Petite question, pourquoi ne pas utiliser un framework et des librairies au lieu de tout refaire from scratch ?

Sinon bonne initiative

J'imagine que ça permettait de refaire par petits bouts, page après page

hmmm.. Qu'est-ce qui empêche de refaire une page avec une lib, puis une autre avec la même lib, etc... ?

[cross]

Oui, et puis j'ai chaque fois cherché des bibliothèques qui me plaisaient et rarement trouvé mon bonheur. Je voulais des choses unitaires mais la plupart des frameworks PHP essaient de tout faire sans être trop modulables, et je voulais quelque chose de très performant pour que le (vieux) serveur de yN tienne le coup mais beaucoup de bibliothèques viennent avec du code hyper générique au lieu d'aller droit au but. Je me dis qu'avec la solution actuelle je peux facilement remplacer une bibliothèque par une autre si j'en trouve une équivalente, ce qui sera d'autant plus probable si d'autres personnes jettent un coup d'oeil au code et connaissent des meilleures solutions de remplacement

Puis il faut bien admettre que yN a des temps de génération+chargement assez imbattables et que les frameworks généralistes ralentissent bien souvent la génération (et même le chargement, avec le tout asynchrone).

Et encore sans toutes les optimisations les temps sont impressionnant (cf la version qui tourne sur mon serveur qui a plein de truc d’optim désactivé et j’ai des temps meilleurs que yN ici 😅)

Pas trop eu le temps pour regarder sur GH ça sera probablement pas avant la semaine prochaine

Nil (./39):
Puis il faut bien admettre que yN a des temps de génération+chargement assez imbattables et que les frameworks généralistes ralentissent bien souvent la génération (et même le chargement, avec le tout asynchrone).

Un symfony 4 même en mode dev tourne très très bien ^^

Je pensais par exemple dans ma remarque à utiliser doctrine pour les entités de la DB, Guzzle pour faire des appels externes, monolog pour le loger, c'est utilisé partout et ça fonctionne très bien

Et même sans utiliser de framework complet, on peut utiliser des composants, comme le routeur symfony, twig pour les templates etc.

Twig est affreusement lent et utiliser une lib pour les 10 lignes que coûtent le logger je trouve ça dommage, mais pour le reste je n'ai pas essayé, si tu as le temps de faire un comparatif ça sera intéressant

Zeph (./42):
Twig est affreusement lent et utiliser une lib pour les 10 lignes que coûtent le logger je trouve ça dommage, mais pour le reste je n'ai pas essayé, si tu as le temps de faire un comparatif ça sera intéressant

Twig avec la version 2 a quand même bien amélioré les perfs, mais surtout une fois que c'est en cache, ça n'a pus besoin de parser donc ça va vite.

Pour monolog, c'est plutôt pour ce que ça propose, c'est très facile de s'en servir pour balancer les logs dans un redis ou autre (il y a une énorme liste de handlers).
Guzzle peut aussi paraître overkill, mais très pratique, et c'est aussi une lib énormément utilisée (avec monolog ça fait parti des libs les plus populaires sur packagist), ce qui peut favoriser d'autres développeurs à participer s'ils se sentent déjà à la maison

Je vais voir si j'ai le temps de faire des tests sur des petits truc pour commencer ^^

Ah aussi, pour l'installation, pourquoi ne pas utiliser composer ? Ca permet de télécharger les modules à la bonne version, vérifier que les extensions php sont bien là.

Oui pour composer j'ai failli y passer quand j'ai préparé le code pour la publication mais j'ai abandonné par pur excès de flemme

[edit] J'ai regardé rapidement les bibliothèques que tu proposais Arvi, voilà ce que j'ai noté pour chaque :

Doctrine : le coût de migration a l'air énorme, il me faudrait un bon argument pour l'envisager. A première vue je ne suis pas fan d'un certain nombre de choix de design, par exemple la syntaxe hybride entre PHP et "pseudo-SQL via des strings" pour leur SQL query builder (des trucs genre ->select('DATE(last_login) as date'), j'aurais préféré quelque chose d'un peu plus typé en passant explicitement tous les paramètres avec une syntaxe PHP plutôt que de devoir utiliser un parseur custom pour convertir le pseudo-SQL) ou bien leur ORM qui parse des commentaires pour essayer de trouver les méta-données des modèles. Comme la mise en place n'a pas l'air triviale et que la documentation est incomplète à des endroits qui me semblent importants pour démarrer, je n'ai pas vraiment la motivation pour creuser plus loin.

Symfony router : un peu pareil que pour Doctrine, ça utilise une solution qui parse les commentaires de classes "controller" pour en déduire les routes éligibles. Comme je n'ai rien vu au sujet de caches dans la documentation, j'ai un peu peur que le machin s'amuse à parser le contenu de N classes à chaque requête pour trouver toutes les routes, mais j'imagine qu'il doit y avoir une astuce parce que ça serait un peu délirant. Si tu en connais plus sur le fonctionnement, je suis preneur de quelques éclaircissements

Guzzle : l'argument de performance n'aurait pas beaucoup de sens ici puisqu'il s'agit de déclencher des requêtes HTTP, en revanche Guzzle fait 3466 lignes de code (d'après cloc). Comparées aux 150 lignes du code que j'utilise actuellement, sachant que dans les deux cas c'est cURL qui fait réellement le boulot derrière, ça ne me semble pas très intéressant. Par ailleurs Guzzle ne semble pas proposer d'option pour définir une limite maximum à la taille de la réponse, ce qui veut dire qu'on peut faire exploser PHP à distance avec une allocation mémoire trop grosse si on lui demande de télécharger un gros fichier. Cet argument seul élimine cette bibliothèque des choix possibles pour moi.

Monolog : la bibliothèque fait 6517 lignes de code, je suppose que c'est en grande partie liée aux différentes cibles qu'elle permet d'utiliser. C'est clairement une fonctionnalité que je n'ai pas, donc il faudrait que je fasse un bench pour vérifier que son intégration ne coûte pas trop cher.

Doctrine c'est effectivement un très gros projet, on peut pas remplacer comme ça ^^ Je n'utilise quasi jamais le pseudo SQL, mais plutôt le query builder.
Pour le routeur, comme pour Doctrine, les annotations dans les commentaires pour la config, perso je trouve ça très pratique, et ça peut se mettre en cache pour pas avoir à parser tout le temps aussi
(et pour le routeur on peut aussi utiliser des fichiers de conf plus classique)

Guzzle et monolog, l'argument n'était effectivement pas la taille
Mais plutôt utiliser des libs connues des devs php, et qui offrent donc un paquet de choses, mais dont tu n'as effectivement pas l'utilité (Guzzle permet par exemple de mocker des réponses, pratique pour les tests, monolog a une liste énorme de handlers, pratique si jamais un admin décide de changer où il enregistre ses logs...)

Oui pour Monolog je vois bien l'intérêt, mais que Guzzle ne supporte pas l'option qui permet de limiter la taille des réponses ça me fait surtout craindre de la qualité générale de la bibliothèque :/

Pour les autres si tu as le temps de faire des PR, n'hésite pas

Après, est-ce vraiment une bonne idée de transformer yN en usine à gaz ? Des moteurs de forums, il y en a déjà pas mal d'autres ; le fait d'être léger et d'avoir peu de dépendances est un avantage, je trouve

()

Je peux me tromper, mais je crois que la tache "flush" ne marche pas entierement si la config n'est pas explicitement donnée pour les dossier de cache

cf dans page/system/task.php:

foreach ($caches as $cache) { $directory = config($cache, null);
Comme l'info par defaut n'est pas conservé lors d'appel suivant, si on utilise les valeur par defaut le flush ne sera pas fait


index.php va en prendre les valeur avec une valeur par defaut:

$router_cache = config('engine.network.route.cache', './storage/cache/route');
Mais comme dit config ne garde aucune trace de './storage/cache/route':

function config($key, $value) { static $config; if (!(isset($config) || @include './config.php')) { die('No configuration file was found, please read <a href="https://github.com/r3c/yaronet/blob/master/INSTALL.md">INSTALL.md</a> to setup your yAronet instance.'); } if (array_key_exists($key, $config)) { return $config[$key]; } return $value; }
Je pense que changer la fonction comme suit résoudrais en partie le probleme:

function config($key, $value) { static $config; if (!(isset($config) || @include './config.php')) { die('No configuration file was found, please read <a href="https://github.com/r3c/yaronet/blob/master/INSTALL.md">INSTALL.md</a> to setup your yAronet instance.'); } if (array_key_exists($key, $config)) { return $config[$key]; } if ($value != null) { $config[$key] = $value; } return $value; }
reste que la config du cache pour i18n et display ne sont pas lue avant que le flush soit lancé, j'ai deux potentiel fix, mais c'est probablement moche:



Bon j'arrete la pour ce soir xD

Je ne suis pas sûr d'avoir compris, la fonction config est là pour lire une valeur dans la configuration avec éventuellement une valeur par défaut, mais dans ton changement tu changes la configuration au runtime ? La tâche "flush" sert à vider les éventuels dossiers de cache s'ils sont configurés. S'il n'y a pas de configuration (soit parce que la configuration contient explicitement "null" pour ces éléments soit parce qu'il n'y sont pas présents) alors il n'y a rien à vider et donc l'action est ignorée. C'est pour ça que les deux valeurs qui sont attendues juste derrière (ligne 67) sont soit "null" qui ne déclenche aucun nettoyage soit un dossier dont on vérifie l'existence avant d'effacer son contenu.

[edit] Ah ça y est j'ai compris, le problème est que la valeur par défaut est différente aux deux endroits où cette configuration est lue. En général je m'en sors en factorisant la lecture de chaque option de configuration (avec sa valeur par défaut) à un unique endroit dans le code pour éviter tout risque d'incohérence. J'ai du oublier de le faire ici

Je corrige ce soir !

Ha oui pardon mon explication n'est probablement pas tres claire.

Mon changement dans config permet juste de définir une valeur par défaut si on rapelle config() a un autre moment durant la même exécution et que la clé n'existe pas dans le fichier de config. C'est pour justement éviter des variables globale


Donc oui en l'occurence dans flush, aucun des trois dossier ne devrait etre "null" car ils sont tous les trois utilisé et se remplissent de fichiers.
Je me suis rendu compte que flush ne faisait rien avec ma config apres avoir fait les changement pour le flashchat et devoir effacer le cache a la main en me disant "c'est pas possible qu'il ai a faire ca a chaque MaJ d'un fichier less ou de langue!

Puis j'ai vu la tache flush, testé "hmmm ca ne fait pas le boulot" passé 15min a debug a coup d'echo pour me rendre compte que config(X, null) me donnais... null donc forcement pas de dossier a nettoyer

C'est juste que y a pas de valeur par defaut pour les dossiers de cache, donc.... notabug? ou tu rend un certain nombre de valeurs de conf obligatoires

Il y a des valeurs par défaut dans le code qui utilise les dit dossier, flush lui ne met pas de valeur par défaut et donc “ne sert à rien” au lieu de faire son boulot.

Voilà ça devrait être corrigé :

Merci pour le bug report Au passage c'est d'autant plus utile de créer un nouveau sujet pour chaque nouveau bug plutôt que de poster dans un existant, parce que ça me permet de le référencer plus simplement dans le commit qui apporte un correctif.

J'ai fait un test aujourd'hui voir si je pouvais passer sur symfony (en séparant le code métier comme ça ça peut être implémenté comme on veut), c'était plus long que prévu ^^

D'abord j'ai migré les classes vers Doctrine (en gros, sans vrai re-travail) :
Un exemple plus complet avec des clés étrangères est : (et donc les classes associées aussi)

Après j'ai juste refais le code pour ban des IPs d'un forum :
La partie "métier" où est la logique pour ajouter ou supprimer des adresses :
Le controller :
Avec donc la route au dessus (mais qui peut être déplacée dans un fichier de conf)
Et le repository :
Pour stocker les différents appels à la DB.

J'ai surtout galéré avec la db, mais je vais voir si je peux aller plus loin du coup ^^
(j'avais ça pour voir ce que ça donnait pour passer sous doctrine, c'est un peu galère quand même, mais ça se fait ^^)

Wow sacré boulot ! Est-ce que tu sais ce que ça donne au niveau de l'efficacité des requêtes ? J'ai par exemple du changer pas mal de choses pour que le système d'abonnements aux sections fonctionne de façon efficace : il a besoin de faire des requêtes de type "INSERT INTO x SELECT y", et "y" contient des jointures qui dépendent à la fois de clés étrangères et de variables extérieures spécifiées au runtime. Je ne sais pas ce que permet Symfony à ce niveau là ?

Apparemment faut passer par du SQL, mais j'ai jamais essayé un truc comme ça, je vais voir quand j'y arrive
(sinon je n'ai pas fait à la main toutes les entités, il y a un outils pour lire depuis la DB pour avoir une bonne base Mais yavait des trucs qui passaient pas c'est ça qui prenait du temps ^^)

Je viens de brancher les tests automatisés de yAronet sur Travis CI (et de découvrir au passage que la compatibilité PHP 5.6 avait sauté par mégarde récemment), vous n'avez donc plus aucune excuse pour ne pas envoyer vos contributions sur GitHub

> Create a new location in HTTP server e.g. /yaronet/ and have it point to /src/ directory.

J'ai pas vu de sample config pour apache, il y en a une quelque part (ai pas utilise apache depuis des annees)?

Non effectivement je pourrais en ajouter une, comme j'utilise nginx je n'ai pas ça sous la main, désolé.