Closed remrem closed 7 years ago
Pas facile, mais en gros :
Mais rien n'est définitif. Qu'en penses-tu ? Tu vois d'autres chosds
Ok, ça me semble déjà pas mal. En gros, on part pour étendre blogotext à l'international (core + public) ;)
Juste quelques question/suggestions :
Si je puis me permettre une petite idée au sujet des templates. Il serait intéressant de disposer d'une interface pour modifier l'apparence du blog par glisser/déposer des divers éléments (articles, sidebar, addons...). Rien de bien compliqué, mais qui serait plus simple que l'édition à la main du fichier list.html.
Le code CSS est aussi relativement compliqué, mais j'ignore si on peut le simplifier tout en gardant un thème par défaut aussi classe. Au pire, une modification simplifiée des couleurs pourrait passer par un addon, ça devrait pouvoir se faire si je ne me trompe pas.
Très encourageant en tout cas ces idées !
Vous avez plein de bonnes idées. Je répondrai demain correctement, je n'ai pas le temps aujourd'hui. Mais tout ça augure de bonnes choses :)
Alors, @remrem :
inc
pour l'admin, et le inc
actuel pour le public.data
qui contiendrait tout ce qui est relatif à l'installation actuelle. Ensuite, ajouter une constante DATA_FOLDER
et adapter les autres en fonction. Ça irait ?@B4rb3rouss, c'est pratique mais ça serait tout un chantier à créer. Peut-être que ça pourrait être une application tierce qui générerait les fichiers JS/CSS/HTML mais ça ne serait pas intégré à BlogoText. Ou du moins, pas dans les prochaines versions, il y a beaucoup de travail à terminer avant de pouvoir l'envisager.
pour le template, méh ... idéalement il faudrait que plus de monde donne son avis, c'est un peu subjectif comme sujet. Personnellement, je dois avouer que le côté kiss de blogotext me plait bien ... c'est rapide, ça fait le boulot et il ne manque pas grand chose pour l'étendre, donc je ne suis pas trop chaud pour du smarty, dwoo, twig ... Une idée, sans doute à la c*n, le core sort les données d'un article (tableau ou object...) et les balances directement au template via une fonction ou une classe, et, à charge du template, de charger son moteur et de formater les données pour les faire correspondre à son moteur. Point de vue core, ça allège (si on laisse tomber le système de template actuel), plus facile (théoriquement) à maintenir et chaque développeur de template fait en fonction de ses goûts/envie/besoins. A creuser ?
pour la config / temp / cache, peux importe le /[data|datas|vars]/, moi ce qui m'intéresse aussi c'est le sous répertoire par blogotext (nom de domaine ou id), c'est juste jouer sur une variable, ça n'as pas de grandes conséquences sur la complexité/poids du core. Pour reprendre ton exemple :
define( 'DATA_FOLDER' , BT_ROOT.'var/' );
deviens (en gros) :
define( 'DATA_FOLDER' , BT_ROOT.'var/'. strtolower(htmlspecialchar( $_SERVER['HTTP_HOST'] )) );
( je risque d'être insistant là dessus :D d'autant plus qu'il m'a semblé voir un ticket à ce propos #24 )
Wiki, cool :D
Si chaque développeur doit maintenair son système de template, c'est pas gagné. Que proposes-tu pour étendre le système actuel ?
Si je comprends bien, pour les fichiers de config, il y aurait :
BT_ROOT/var/www.example.org
BT_ROOT/var/blog.ceci.cela
Et tu as des vhosts
qui pointent vers la même installation de BT ?
pour le template, dans l'immédiat, il n'y a juste que quelques tags à ajouter (pour les besoins que j'ai identifié, à voir avec la communauté).
Pour les fichiers de config, oui, c'est bien ça, pour étayer :
BT_ROOT/var/www.example.org/config/
BT_ROOT/var/www.example.org/cache/
BT_ROOT/var/www.example.org/databases/
BT_ROOT/var/blog.ceci.cela/config/
BT_ROOT/var/blog.ceci.cela/cache/
BT_ROOT/var/blog.ceci.cela/databases/
et idéalement
BT_ROOT/var/www.example.org/files/
BT_ROOT/var/www.example.org/img/
BT_ROOT/var/www.example.org/addons/
Et tu as des vhosts qui pointent vers la même installation de BT ?
Actuellement non, mais j'ai plusieurs blogotext en prod ou en préprod, et rien qu'à l'idée de devoir faire le tour pour les maj, sauvegarde, réplications (sur 4 serveurs) et la maintenance, ça me gonfle déjà...
Tout semble faisable, ça me plait bien. Seul bémol : les addons.
Étant donné qu'on ne peut pas les installer comme on le souhaite, c'est un dossier synchronisé avec le dépôt des addons. Ce qui est envisageable, c'est de stocker les paramètres (params.ini
) et l'état (.enabled
) dans BT_ROOT/var/www.example.org/addons/
seulement.
Pas faux ;) et plus léger pour les sauvegardes/réplications ;)
Question qui me travaille depuis deux jours, serait possible d'avoir une feuille de route pour sortir une version stable ? Histoire d'avoir un peu de visibilité ...