[WIP] Feuille de route à jour

BoboTiG commented 7 years ago

Pour rester à jour, voici ce qu'il reste à faire (voir #126 pour plus de détails) :

[ ] refactoring (distinction admin/public)
[ ] séparation des fichiers de données
[ ] repenser et sécuriser l'installation (#135)
[ ] processus de MàJ automatique (#136)
[ ] étoffer le système de template

BoboTiG commented 7 years ago

Refactoring

Je ferai une liste des modifications à faire, on freeze les patches et commence le refactoring ? Le refactoring permettra de modifier les noms des fichiers en anglais par la même occasion. De plus, chaque fichier : 1) ne devra contenir soit que des fonctions, soit des appels à d'autres fonctions, mais pas les deux ; 2) la limite de longueur d'une ligne est fixée à 120 ; 3) pas d'HTML partout, les fonctions retournent des tableaux ou string.

À terme, ces tests seront utilisés :

php phpcs.phar --standard=PSR2 -p --tab-width=4 --encoding=utf-8 .

Tu peux essayer et pleurer toutes les larmes de ton corps tellement il y a de warnings :D

Dans la même trempe, j'ajouterai d'autres tests qui, entre autre, empêchera l'accès direct aux super globales comme $_POST ; il suffira d'utiliser filter_input() :

// Avant
$var = $_POST['var_name'];

// Après
$var = filter_input(INPUT_POST, 'var_name');

Voilà une proposition pour l'oganisation des fichiers, partie admin :

admin/
  - cache/
  - inc/
      - _tools.php (toutes les fonctions partagées)
      - _ajax_*.php (les requêtes AJAX)
      - posts.php
      - links.php
      - comments.php
      - ...
  - styles/
  - index.php

Le fichier index.php s'occupera des inclusions, vérifiera si la page demandée est affichable (index.php?page=posts par exemple), fera un include_once de la bonne page, et appelera les fonctions pour afficher la page :

header();
render();
footer();

Où render() est à définir dans chaque page incluse et qui ne fera qu'afficher du HTML.

Concernant la partie publique :

- addons/
- admin-uuid/
- inc/
    - _voir comment organiser les fichiers ici_
- var/
    - site1/
        - bt_backup/
        - cache/
        - databases/
        - files/
        - img/
        - themes/
- themes/
    - default/
- translations/
    - en_en.php
    - fr_fr.php
- atom.php (voir pour le merger avec rss.php ?)
- index.php
- install.php (temporaire)
- rss.php

On devra garder themes à la racine et il sera copié lors de l'installation dans var/site1.

Enfin, afin d'éviter au maximum les doublons, comment faire pour les fonctions appelées depuis les deux espaces ? Dans un fichier à la racine inc/shared.php ?

remrem commented 7 years ago

En vrac (désolé)...

1) à chaud et fatigué : ce n'est plus du refactoring, c'est (quasiment) tout ré-écrire, non ? :D (header(),render(),footer()...)

ne devra contenir soit que des fonctions, soit des appels à d'autres fonctions, mais pas les deux ;

2) hum ... à voir ... performances include (HDD/IO VPS) (estimation du nombre d'include pour afficher un article ?), ça serait bien de ne pas perdre la légèreté de BT (qui est déjà limite pt de vue IO HDD).

la limite de longueur d'une ligne est fixée à 120 ;

Ok

pas d'HTML partout, les fonctions retournent des tableaux ou string.

:+1:

Dans la même trempe, j'ajouterai d'autres tests qui, entre autre, empêchera l'accès direct aux super globales comme $_POST ; il suffira d'utiliser filter_input()

3) filter-input-array est pas mal pour ça. Empêcher ? les addons pourront quand même y accéder/avoir les leurs ? J'aimerai bien que tu développes un peu ce point.

admin/
  - cache/
  - inc/

4) Pour la partie admin, il y a un cache ? l'admin ne devrait pas en avoir ? si ? oO Si oui, plus à mettre dans "/var/site/cache-admin" ou autre, la problématique des vhost...

5) Le répertoire translations devrait être dans inc/ histoire de limiter les dossiers à la racine (moins de .htaccess / nginx rules à gérer), non ?

6) pour le fichier atom.php, je pense qu'on peux le merger avec rss, mais peux être sous forme flux.php?format=atom|rss et je pense que l'on devrait conserver atom.php et rss.php qui ne fairait quun require flux.php, histoire que les utilisateurs aient le temps de changer l'url dans leurs services (voir mon commentaire sur la v4 en fin de réponse).

7) à ajouter : "addons" dans "/var/site/" pour le params.ini et autres joyeusetés...

8) pour inc, qu'est ce que tu en penses ?

inc/
 - translation/
 - functions/
 - process/
 - lib/

functions/ toutes les fonctions process/ tout le code qui n'est pas dans inclus dans une fonction, 1 fichier = 1 tache (show-article, article-list...) lib/ toutes les libs que l'on peux/pourrais utiliser que nous ne développons pas nous même

ou alors

inc/
 - translation/
 - lib/
 - functions-form.php
 - functions-auth.php
 - process-lang.php

9) Je ne sais pas trop ... Le truc, c'est que je pense que l'on ne devrait pas éclater le code dans trop de fichiers pour limiter l’accès les requêtes HDD. Si on doit faire 50 includes pour traiter un article+commentaires, je sais par expérience que certains hébergeurs/petit serveur vont vite tirer la gueule... et pour l'organisation public/privée, je pense que l'on devrait garder la même architecture ('inc/','themes/'...), la même logique partout.

10) pour les fonctions communes (admin/public), on claque tout avec les fonctions de bases dans un /inc/common.php ? à voir si le final n'est pas trop lourd.

Où render() est à définir dans chaque page incluse et qui ne fera qu'afficher du HTML.

11) je comprends pas trop là ... En gros, on aura plusieurs function render.php(){} à travers les différents fichiers ?

12) Juste une réflexion, avant de partir sur un dossier aussi lourd :

on ne finirait pas les gros changements que l'on a pas encore fini ? (addons, debug, wiki...) histoire de se roder un peu plus, de s'accorder un poil plus de temps de réflexion (j'ai l'impression qu'on rush là...) pour la v4 on en est à peine à l'ébauche de la roadmap et on est pas d'accord sur tout (je KISS PSR2, je vais en faire un running gag ) ...
histoire de voir comment se passe une maj de blogotext point de vue communauté ? Histoire de préparer un truc vraiment bien pour la sortie de la v4.
histoire de sortir une mise à jour avant noël/fin d'année, ça serait cool ça ;)
De plus, avec une mise à jour intermédiaire qui apporte déjà pas mal, on fait parler de BT et (avec de la chance) quelques contributeurs de plus ... non ?
Laisser ceux qui veulent jouer avec le nouveau système de plugins le temps de nous en faire quelques uns qui dépote pour avoir une V4 qui à plus d'arguments "qu'un moteur améliorer/réorganisé" et qu'un nouveau système de modules "mais qui n'a que 4 ou 5 modules à proposer"... :D
même base argumentaire que le point précédent (jouer avec le système d'addons), mais pour un aspect plus pragmatique : le debug + retour d'expériences des utilisateurs, histoire de sortir une v4 qui risquerai moins d'être entaché de bugs.

BoboTiG commented 7 years ago

(je me suis permis d'éditer ton commentaire pour ajouter des numéros, sinon on ne va pas s'y retrouver)

1) Pas vraiment une réécriture, si tu regardes tous les fichiers dans admin appellent header() et footer() ; et chacun fait ses opérations avant et entre ces deux fonctions. Nous ajouterons la logique dans une fonction et la vue dans une autre. En gros, chaque fichier qui s'occupe d'une page (articles, liens, modules, etc.) n'aura qu'a définir ses propres fonctions render() et traitment(). Les noms ne sont pas encore définis. Étant donné qu'une page n'incluera qu'un seul fichier PHP relatif à la page en question, ces fonctions ne pourront pas être dupliquées. Et pour les MàJ et éventuelles nouvelles pages, ça sera facile comme tout.

2) Je dirai qu'on sera même en dessous du nombre d'inclusions actuelles. Il y aura un include pour les requêtes SQL, un autre pour la conf, les pref, les langues, les fonctions communes et l'affichage. En gros hein, rien n'est creusé pour le moment. Actuellement, il y a 15 includes pour un article.

3) Les deux fonctions pourront être utilisées. Ou on utilisera seulement filter_input_array() au sein même de BT, comme tu préfères. Les addons devront faire appel à une des deux fonctions, rien ne sera bloqué. En allant plus loin, on pourrit (devrait ?) définir deux fonctions utilisables par tout le monde, dont au sein du core, pour wrapper ces fonctions (un genre de get(mixed $var) et post(mixed $var) ; si $var est un tableau, on l'envoie à filter_input_array() sinon à filter_input()). Ton avis là-dessus ?

4) Le nom du dossier est presque traitre, mais c'est là où sont stockés les avatars. À réfléchir où les stocker. On peut déplacer le dossier cache à la racine, les thèmes auraient ainsi accès aux avatars et cela éviterait d'avoir du code dupliqué dans chaque thème. Si un thème souhaite utiliser autre chose, libre à lui de copier la logique. Ça règlerait aussi le soucis des vhosts, tous les avatards au même endroit, car une même adresse courriel aura toujours le même avatar (léger gain en performance).

5) Tout à fait d'accord.

6) Pour la transition OK, on sort la 3.7 avec ce schéma et pour la 4.0 les fichiers atom.php et rss.php seront supprimés. On ira même plus loin en utilisant index.php?do=rss|atom comme l'a fait Seb avec Shaarli, on économise un fichier. (?)

7) Yep, un oubli de ma part.

8) De quelles lib parles-tu ? Le second schéma est préférable, un niveau de sous-dossier c'est bien. On peut garder les noms courts ?

inc/
 - translations/
 - common.php
 - form.php
 - auth.php
 - lang.php

9) Pas de soucis, le but n'est pas de tout éclater ni trop rassembler. On va rééquilibrer le contenu des fichiers actuels, c'est joliment dit ça :)

10) Yep.

11) Exactement. Chaque page incluse (on parle de la partie admin là) définiera sa fonction render, elle servira simplement à afficher le HTML/JS.

12) Une version de transition, comme tu l'as suggérée, est une bonne idée. Le gtos morceaux reste les addons du coup. Je modifie les milestones.

remrem commented 7 years ago

Pas de problème pour l'édit de mon commentaire ;)

1) Ok. 2) Ok. Moins d'include serait pas mal ;) 3) Ok. Je comprends mieux là. 4) Ok. +1 pour le déplacement 6) :D 8) 'lib/' était juste pour illustrer ;) La convention de nommage de fichier m'importe peu 11) Ok 12) Cool !

remrem commented 7 years ago

Petite question, pour les

/var/domain.tld/addon/addon_name/cache/
/var/domain.tld/addon/addon_name/config|settings.ini

On peux déjà mettre ça en place non ? Pour la v4, ça sera déjà fait, et ça permettra de valider /var/domain.tld/ Et pour aller plus loin, le problème vhost, les .enabled devrait être dans /var/domain.tld/addon/addon_name/

BoboTiG commented 7 years ago

Pour faire cette modif, il faudrait que le système /var/domain.tld soit déjà en place.

BoboTiG commented 7 years ago

settings.ini me semble plus approprié aussi pour le nom du fichier des paramètres. Je m'en charge ?

remrem commented 7 years ago

J'ai commencé le refactor ^^

/var/domain.tld, je suis dessus, on garde var ? Je ne le fais que pour les addons, mais je prépare le terrain (DEFINE) pour basculer le reste plus tard

setting.ini, Ok, Je le fais en même temps

BoboTiG commented 7 years ago

Ouais, var parlera à presque tout le monde.

BoboTiG commented 7 years ago

Pense à prendre en compte les deux p'tites modifs que j'ai apporté aux paramètres.

remrem commented 7 years ago

Ok, je ne devrais pas en avoir pour long

Pense à prendre en compte les deux p'tites modifs que j'ai apporté aux paramètres.

J'ai pris en compte "[PHP] Addons params: fix value when integers used" https://github.com/BoboTiG/blogotext/commit/8e9b92b247c3eb3bb413e6f3581fb6c20e2b2057

BoboTiG commented 7 years ago

Nickel !

remrem commented 7 years ago

ça prend un peu plus de temps que prévu, mais ça vaut le coup... Pour info :

BT devrait supporter les Nom de domaine internationalisé, @BoboTiG tu voulais de l'international il me semble ;)
pas le choix, j'ai du rajouter une couche de sécurité (pour prévenir les hack de $_SERVER['HTTP_HOST'])
certaines modifications que j'apporte sont prévues (un peu) pour la v4, tant que je suis dedans...

BoboTiG commented 7 years ago

Ça semble pas mal déjà ! Hâte de voir du code :)

remrem commented 7 years ago

Petite question, parce que ça me prend la tête, on ne passerai pas des paths absolus plutôt que des paths relatifs ? Pas mal de choses embêtantes à gérer avec la séparation admin/inc/ et /inc/. En attendant, J'ai mis une fonction dont je me sers sur d'autres projets pendant qu'ils sont en cours de dev/debug.

BoboTiG commented 7 years ago

Tout à fait, et le inclusions seraient plus rapides.

BlogoText / blogotext

[WIP] Feuille de route à jour #133