Nicolas a écrit 570 commentaires

J'ai commencé à écrire la News pour la sortie de la 2.6 finale mais sortir une news pour une RC ça me parait un peu démesuré. En fait mon journal bookmark n'a pour but que d'inciter certains à tester !

Salut,

une question : as-tu un hébergeur ? Si oui je te conseille dotclear même si je ne suis pas forcément objectif !

Je suis en train de regarder quel moteur choisir pour propulser mon futur blog (Wordpress, Dotclear ?) et cela m'intéresserait - et pas que moi je pense - de savoir un peu les nouveautés que l'on va retrouver dans la version 2.6 et les suivantes.

Ce billet qui date un peu donne des idées de que tu espérons mettre dans les prochaines versions, pas nécessairement la 2.6 mais la 2.7 ou la suivante :
http://fr.dotclear.org/blog/post/2013/03/16/Dotclear-2.5

J'ai parcouru un peu la mailing liste pour piocher des infos, mais je n'ai pas trouvé d'endroit qui donnerait une vision d'ensemble sur la roadmap.

Je suis d'accord. Peut-être faudrait-il essayer de donner plus de visibilité à cette roadmap.

La prochaine version majeur, la 2.6, sortira courant Octobre voire un peu plus tard d’après le site web, je pense que je vais tester

En effet elle promet ! Rien que pour l'interface d'administration !

ce que c’est devenu parce qu’à chaque fois j’avais un problème assez gênant avec, une page de l’administration qui était inaccessible (ça vient peut-être du serveur web que j’utilise, Nginx).

Si tu rencontres de nouveau des problèmes qui te semblent liés à Nginx, n'hésite pas à venir en faire part, on s'assiéra, on prendra un verre et on corrigera tranquillement.

Le passage de la semaine de 4,5 à 4 jours ne datent que de 2008. Il faut arrêter d'en parler comme s'il fallait demander aux grands-parents pour savoir comment c'était.
Avant 2008 les enfants étaient à l'école 4 jours et demi par semaine.

Les eval ne sont pas à tout va et sont là pour les plugins. Cela permet d'écrire du code et d'intervenir sur le core, sans vraiment le modifier.

Exemple trouvé :
php
eval($plxAdmin->plxPlugins->callHook('AdminArticlePrepend'));


La classe plxAdmin a une propriété qui contient tous les hooks sous forme de tableau. Plutôt que de faire cet eval sur du code par forcément maîtrisé, il suffit d'appeler une fonction de callback nommé. Regardez sur d'autres projets (drupal, dotclear, piwigo pour ceux que je connais) qui ont ces mécanisme de hook, ils ne font pas d'eval.

la fonction eval n'est pas le mal absolu mais ce n'est pas la peine de l'utiliser quand on n'en a pas réellement besoin.

Celui de dotclear gère apache2 / lighttpd et surtout gère l'installation des bases, mises à jour comprises.

Le package debian existe. Il est "malmené" par outils de vérification automatique debian et du coup le package n'est pas dans l'actuelle stable.
Il reste un bug "critique" (un fichier de conf d'apache écrasé par les mises à jour) qui l'empêche de rejoindre tranquillement testing.

Juste par curiosité, pourquoi voulais-tu absolument une mise à jour ? Il te manquait une fonctionnalité ?

Que pour une bonne raison on change la feuille de style par défaut, je peux le comprendre mais empêcher tout le monde de changer la feuille de style, au mieux c'est un bug …

Tu n'arriveras jamais à la version parfaite et encore moins du premier coup. Note les choses que tu vas vouloir ajouter et dès que tu as une version sans bug bloquant ou critique, fais en une version publique. Si cela intéresse quelqu'un tu auras vite des retours.
Bon courage

Euh si PHP a d'énormes problèmes de sécurité,

Je dois avouer que quand j'ai vu 2007 pour l'année je n'ai même pas fait l'effort de lire plus loin…

… et il n'aide pas d'ailleurs à éviter dans mettre dans son propre code tellement il est mal fichu et sans aucune convention

Admettons et donc le problème de sécurité est bien le programmeur lui-même et pas le langage qu'il utilise. On ne pas désigner directement l'outil comme mauvais du fait qu'on l'ai donné à un ouvrier qui ne le maîtrisait pas.

Après je veux bien reconnaître que le langage n'aide pas les débutants à avoir les bonnes pratiques.

Et comme d'habitude c'est du PHP (avec les conséquences de sécurité qui vont avec).

Les problèmes de sécurité ne sont pas liés au langage mais à l'interface chaise clavier !

Pareil, que du MySQL, impossible d'utiliser PostgreSQL qui affiche de meilleures performances.

En même temps, il a le bon goût d'utiliser pdo (abstraction de base de données) et du coup le portage vers d'autres sgbd(r) est est grandement facilité.

Ça reste un CMS parmi tant d'autres, rien d'innovant.

On attend plus que ta contribution.

Je partage globalement ton avis même si j'avoue que ce ne serait pas forcément facile de se remettre en cause et risquer de perdre sa place. Mais cela pousserait sûrement les gens à continuer d'évoluer, de se battre, de se former pour garder une place ou pour en trouver une autre, voire une meilleure.

Ma question : jusqu'à quel âge ? Je vois (peut-être à tort) le CDI comme une sorte de récompense de stabilité après être passé par les cases chômages, CDD, SSII, … En approchant de l'âge de la retraire (tant qu'elle existe), je ne pense pas qu'on est la même hargne pour chercher un nouveau boulot ou pour garder celui qu'on occupe.
En clair, que fait-on des vieux ?

Il y a quelque chose que je ne comprends pas : pourquoi ne pas formater les cardes SD en ext3 ? On peut lire et écrire depuis n'importe quel OS. Quel est le soucis ?

Et quand on est locataire on fait comment ? On repart avec son carton d'ampoules ?

Et j'ajouterais que le commentaire suivant :

Pas optimisé pour l'utilisation avec un reverse proxy : aucun header lié au cache positionné (Expires…). Au final, tout le monde utilise "WP-Supercache" qui ne résoud que partiellement le problème

Je ne suis pas sûr de savoir de quoi tu parles, mais ce dont je suis sûr, c'est que Django doit certainement le permettre de base.

J'ai encore plus de doute sur ses compétences.

Effectivement, la version 8 va utiliser de nombreux composants issus de Symfony. J'y vois plein d'intérêt pour tenter de mutualiser les compétences. Je pense que les deux projets (Symfony et drupal) ont a y gagner.

Pour avoir jouer avec la version de développement de drupal 8, ce ne sera quand même pas une révolution, en tout cas côté visiteur ! Sous le capot c'est en revanche bien autre chose, et on y retrouvera plein de bonnes pratiques : composer, composant http,…

Comme pour les précédentes versions, le risque est de ne pas avoir suffisamment de modules portés sur la dernière version.

Dans install/install.txt, j'ai trouvé :
Si vous êtes sous PHP 5.x, n'oubliez de passer la variable "registerlong_arrays" à "On" dans le php.ini_

C'est bien évidemment le contraire qu'il faut faire !

Quelques éléments :
- on n'évite de faire des select * pour des raisons de performances mais aussi de logique. On s'attend à récupérer N champs. On modifie la table en ajoutant 2 champs. Par chance cela peut être transparent pour le code qui suit mais c'est rarement le cas.
- tes requêtes ne semblent pas protégées contre les injections sql, entre autre. Il faut au minimum utiliser mysql_real_escape_string(). pdo ??
- l'arobase ne doit servir qu'à masquer des ouvertures de flux (fichier, socket,…) et à l'unique condition de tester le code de retour de la fonction.
- on ne fait pas de "or die" en dehors de la phase de tests !

Bon courage.

Par curiosité et un peu fainéantise, tu fais comment pour que ce soit à peu près transparent au niveau utilisation et configuration. Merci d'avance.
Tu n'as pas de soucis avec OVH ? Trop de bande passante utilisée ?

d'une demi-douzaine de lignes ?

Un problème en maths aussi ?

On apprend des choses en "testant" !

La question de la performance est vraiment mineure avec notre méthode actuelle d'abstraction à la base de données (c'est à dire de faire du SQL générique).

Cela ressemble à une abstraction mais c'est loin d'être optimal.

En revanche, si on avait choisi une méthode d'abstraction plus "complète" du type "mapping objet relationnel", ça oui c'est trop coûteux en performances. En tout cas avec les tests réalisés il y a quelques années.

Tu mélanges plusieurs choses. Ce n'est pas parce qu'on fait une abstraction de base de données qu'on est obligé de passer par la cas mapping relationnel objet. On peut très bien faire une abstraction de base de données et continuer à utiliser des tableaux contenant les données provenant de la base.

Sans la couche ORM, ce n'est pas tellement plus couteux et on gagne énormément en sécurité (injection sql,...) et en robustesse du code.

Piwigo assume ce choix : la totalité de l'équipe de développement a poussé dans ce sens.

La totalité, moins une personne ! :-)