NPDS : Gestion de contenu et de communauté

yes

oui je dit comme toi a faire ou tu le dit ! dans la function themesidebo

je le ferai bien ici une condition dans le remplacement du métamot ... ?

   "'!B_class_title!'i"=>$B_class_title,

   "'!B_class_content!'i"=>$B_class_content,

"'!B_class_title!'i" => isset($B_class_title) && $B_class_title !== '' ? $B_class_title : 'noclass',

"'!B_class_content!'i" => isset($B_class_content) && $B_class_content !== '' ? $B_class_content : 'noclass',

L'utilisation d'une fonction unique themesibox() partagée entre tous les thèmes est une mauvaise pratique. Chaque thème devrait disposer de sa propre méthode themesidebox(), etc., afin d'être autonome et personnalisable. Le concept actuel de thème dynamique, tel qu'implémenté, ajoute de la complexité inutile sans réel bénéfice.

Cela concerne la fonction themesidebox. Cette fonction n'empêche pas de faire une vérification sur $B_class_title, par exemple avec une condition du type :

$B_class_title ? 'class="card-title ' . $B_class_title . '"' : 'class="card-title"';

ou quelque chose dans ce style."

Comme je suis encore sur le sujet bloc css spécifique (me reste 2 traductions de doc à faire et la finalisation de la modif des templates des différents thèmes) je reviens sur le sujet car notre implémentation n'est pas encore parfaite... ce qui ne me plait pas c'est que dans certain cas suivant la structure html du template on peut se retrouver avec class="" dans le html final ... même si html5 tolère un attribut class vide je ne trouve pas ça top !...

ce cas se présente évidement quand la balise html qui contenant le metamot n'a pas de classe et que le bloc n'a justement pas de css spécifique... aussi
exemple 1 == ok

                        <h5 class="card-title !B_class_title!">!B_title!</h5>

exemple 2 == nook

                        <h5 class="!B_class_title!">!B_title!</h5>

alors quoi faire ... soit on met une classe bidon noclass lors de la construction (dans le code fab_bloc()) soit on la met dans tout les templates qui en on besoin ? ...

tu comprends pas la problématique tant pis

que ce soit sur un thème de base ou sur un thème personnalisé tu peux utiliser les blocs personalisés.
La limite dont on parle reste la même car elle est non seulement du au framework mais aussi à ce que génère le core pour le contenu des blocs ...

je ne penses pas que faire un thème personnalisé soit une galère...

c'est ce que je dis in fine.
quand tu met un site en prod,
soit tu prends un thème par défaut et là tranquille tu peux laisser les autres thèmes, la possibilité de skinner, jour/ nuit et tu t'en fout. tu utilise pas les blocs personnalisé etc...

soit tu veux faire un thème personnalisé et là tu rentre dans la galère, prendre un bon thème de base (pour moi 1 seul est bon actuellement) tu supprimes tous les autres, tu design ton thème, tu peux utiliser les blocs personnalisé.

ok on garde donc
- j'affine la doc
- remet les metamot de classes dans les templates
- le div dans les contents (inutile en fait pas besoin de surcharger le html)

et oui c'est une implémentation qui a pour but de modifier individuellement le style du contenu d'un bloc ... [mais qui à ses limites et peux ne pas produire exactement les résultats attendus par les éléments de css invoqués]...