Adapter un squelette pour être compatible avec le noiZetier - commentaires

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,
(je viens de trouver la notification de réponse dans mes mails en retard....)
il s agit bien d un cas d utilisation avec Zpip v1...
Il faudrait que je regarde Zcore de plus près...
merci pour la reponse
amicalement
triton

Adapter un squelette pour être compatible avec le noiZetier

Il conviendrait de préciser si le ,noiZetier est ici utilisé en conjonction avec le moteur Z (i.e. Zpip v1) ou bien avec un autre type de squelettes qui appelle de lui-même le générateur de blocs.

Je suppose que tu fais référence au premier cas de figure. La limite que tu évoques est une limite historique du fonctionnement du moteur Z version 1.

De mémoire, les choses sont différentes avec la version 2 du moteur Z (Zcore) mais le noizetier n'a pas été mis à jour vers cette version de Zcore.

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,
J ajoute 2 blocs (header et footer) administrables grace au pipeline _noizetier_blocs_defaut, ca marche très bien.
Par contre, suis je vraiment obligé de créer un dossier « header » et « footer » contenant chacun article.html rubrique.html (toutes les pages squelettes de spip) vides pour éviter un message d erreur lors de l inclusion avec la directive
par mon body.html
Cela me parait un peu bizarre comme méthode, et que se passe t il si un nouveau plugin vient ajouter un nouveau type de page ?
Une nouvelle fois, un grand merci pour ce plugin magnifique
Amicalement
triton

Adapter un squelette pour être compatible avec le noiZetier

ok autant pour Zspip-dist dans le trunk (en V2) est compatible Zcore ....

Adapter un squelette pour être compatible avec le noiZetier

Bonjour Joseph,

Je reviens sur le sujet ;-)
Le passage de zspip a Zcore a t'il un intérêt quelquonque d'après toi, dans l'utilisation d'un squelette noizettable ?
Es-ce des améliorations de perf, de gestion Ajax ? J'utilise un zcore-vide et un zcore-dist (la dist de spip en Z juste ...), mais j'avoue ne pas trop saisir pourquoi rien n'a évolué dans ce sens sur la zone hormis le projet spipr-vide ?

Adapter un squelette pour être compatible avec le noiZetier

Merci Josph,
ok, mais dans le cas de « Maparaan », les balises h2 ont été ajoutées dans le squelette et non dans le .css . J'ai donc publié une modif à prendre en compte sur le plugin du même nom et ai du modifier directement dans le fichier contenu « article.html » du plugin ....

Adapter un squelette pour être compatible avec le noiZetier

Il y a deux éléments : le HTML et les CSS.

Pour changer la structure HTML, il faut surcharger les noisettes de Aveline. Ceci dit, par défaut, les pages articles ont bien un titre de niveau H1 (cf. par exemple http://joseph.larmarange.net/?Depis...).

Concernant les CSS, Zpip v1 (et toutes ses déclinaisons) acceptent un fichier squelettes/perso.css qui est chargé après tous les autres CSS et permet donc de surcharger toute autre déclaration CSS. Voir Personnaliser facilement les CSS du thème.

Adapter un squelette pour être compatible avec le noiZetier

Modifications (CSS) pour être compatible SEO

Bonjour Joseph,
Les sites en Spip établis avec Zpip-dist 1 + Noizetier + des Thèmes et squelettes comme Maparaan, ont des styles qui ne respectent pas les consignes actuelles SEO de Google (fort nombreuses et évolutives effectivement depuis la sortie de ces squelettes) et plus particulièrement par ex les pages articles n'ont pas de Headings H1 (normalement = le titre) ;

Ma question est : dans tous ces fichiers styles qui se superposent avec les plugins indiqués, quel est celui qui a « le dernier mot » ? et un fois celui-ci sélectionné et modifié, le mettre où afin qu'une mise à jour n'efface pas le travail ?

je ne sais pas si c'est la bonne rubrique pour en parler...
En vous remerciant ;

Adapter un squelette pour être compatible avec le noiZetier

Merci. Je viens de mettre la doc à jour.

Adapter un squelette pour être compatible avec le noiZetier

Excellent ;-) oui ça fonctionne ! et effectivement j'avais bien l'édition privé auparavant.

Sans les autorisations et sans inclure le squelette d'édition effectivement ça ne peut pas marcher ;-)

Merci pour ta réactivité habituelle, le suivi et tes conseils.

Adapter un squelette pour être compatible avec le noiZetier

Je suppose que tu utilises dans ton squelette l'insertion suivante :

Mais effectivement, cela ne permet pas la modification des noisettes depuis l'espace public. (mais la gestion depuis l'espace privé devrait fonctionner sans problème).

Il devrait être possible d'activer la gestion des noisettes depuis l'espace public en remplacant l'insertion précédente par :

[(#ENV{voir}|=={noisettes}|et{#AUTORISER{configurer,noizetier}}|oui) 
][(#ENV{voir}|=={noisettes}|et{#AUTORISER{configurer,noizetier}}|non) 
]

Peux-tu tester et me dire si ça fonctionne ?

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,

J'ai testé l'ajout de blocs et noisettes dans un squelette non-z. En fait juste certains blocs, le reste de la page étant un squelette standard.
j'utilise la technique des description de bloc dans le fichier xml de la page.

Je n'arrive cependant pas a avoir accès a l'édition des noisettes sur le site public : Y'aurait il une étape supplémentaire que celles décrites dans cet article ?

merci de vos réponses.

Adapter un squelette pour être compatible avec le noiZetier

Historiquement, le projet Aveline + noiZetier a été porté presque exclusivement par moi-même. Or, ma vie profesionnel ne me laisse plus beaucoup de temps libre et mon engagment est donc réduit.

Ceci étant dit, il n'y a pas besoin de passer à spipr et à bootstrap pour faire du responsive. L'ensemble Zpip-vide + Aveline + noiZetier fonctionne très bien.

La seule difficulté c'est le fait qu'il y a peu de thème Z v1 responsive qui ont été proposé par la communauté. Mais c'est tout à fait faisable, sans avoir besoin de passer par un framework. Le problème est de trouver des personnes qui ont l'envie et les compétences et le temps pour développer de tels thèmes.

Cordialement

Adapter un squelette pour être compatible avec le noiZetier

Bonjour Mist. GraphX, depuis plusieurs années, j'utilise Aveline dans les sites que je mets en place cela permet à mes confrères de gérer eux même leurs interfaces (une liste d'article ici, un menu avec ci et ça, un diaporama là, etc ) surtout sans que j'ai à intervenir.
Depuis peu, je recherche le moyen de mettre tout les sites en responsive : qu'ils puissent s'adapter au format du terminal. Avec pour effet de rétracter certains menus (picto en 3 barres), diminuer ou faire disparaitre les images... bref, cela demande un niveau de connaissance en CSS, less et/ou JQ... que je laisse volontiers aux personnes passionnées de cela.
J'ai donc cherché un thème de type responsive qui puisse répondre à mes désirs.
Avec Aveliner je pensais avoir trouvé le graal, mais je ne retrouve pas tous les éléments (plugins) utilisés dans mes sites sous Aveline.
Par exemple, J'ai testé Initializer, mais z-core avec html5 et zpip-dist buggent ensemble.
Je te passe les détails qui font que je vais faire migrer mon serveur php5.2 en php 5.4 avant la fin de l'année )
Je ne dois pas être le seul dans ce cas, je vais attendre un peu et voir si des thèmes responsives font leur apparition.
Il est vital pour SPIP ( que je connait depuis la version 1.6) d'accompagner rapidement ces mutations.

Grand merci à tous et toutes les passionné(e)s du « code ».
merci Mist. GraphX

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,

un conseil il faut commencer par du simple et le complexifier, par petites couches sinon on ne sait plus à partir de quel moment ça part en vrille....

Si on ne maitrise pas un peut css, commencer par bootstrap ou un framework peut vite poser problème.
il faut de plus prendre en main LESS ou SCSS les pré-processeurs si besoin ...

Comme pour jQuery et javascript, on conseille toujours d'apprendre le langage de base, avant d'utiliser un framework : car quand ça bug il faut savoir si ça viens du framework ou de son code ...

Ceci étant on as pas besoin d'un framework pour faire un site responsive forcément, comme le souligne Joseph.

Vous n'avez pas trouvé dans les squelettes de contrib une base responsive, qui puisse vous servir de départ (il y'en as pas mal pourtant) ? ou il vous est vraiment nécessaire d'avoir autant de paramétrages , pour un seul site ?
en gros quels sont les fonctionnalité que vous recherchez ?

Adapter un squelette pour être compatible avec le noiZetier

Merci pour toutes ces réponses. j'ai beaucoup exploré des solutions simples pour avoir une interface responsive et paramétrable depuis le back office avec spip... (foundation, Initializer...)

Ceci étant dit, il est également possible de développer un thème responsive compatible avec les versions actuelles de Zpip-vide, Aveline et du noizetier.

Voir par exemple http://joseph.larmarange.net ou http://www.ceped.org

Cela demande néanmoins d'avoir les compétences pour développer un thème Z.

je comprend Joseph, mais malheureusement, je sèche devant le développement des thèmes en Z, les scripts, le java, le JQuery .... zcore et zpip buguent entre eux... donc pour moi, les solution sont trop complexes aujourd'hui pour faire mon site sous spip en responsive.

Adapter un squelette pour être compatible avec le noiZetier

En l'occurence, le Squelette vide n'est pas le gros du problème, ça se fait en une 1h ou deux ... vu qu'il est vide ^^ ... je ne vois toujours pas d'ailleurs pourquoi Spip-r vide et pas un Z-core vide ... mais bon c'est qu'un prefixe en fait

Le code du noizettier ne change que de quelques lignes ... donc idem (comme dit avec Joseph précédemment)

Le problème c'est de ré-écrire toutes les noisettes, avec des classes qui sont dépendantes d'un framework, qui change de nomenclature quand il veut et donc nous rend dépendant de leur bon vouloir ....

J'avais commencé a en ré-écrire une partie, au fur et a mesure de mes besoins, avant de me rendre compte que c'était une perte de temps. Il est beaucoup plus pertinent de mettre a jour le markup des noisettes aveline en html5, ARIA, Micro-format ... pour qu'elles puissent êtres partagées entre tout type de squelettes Z ou non, comme un collection de fragment html. (sujet de l'article au passage) Le markup de bootstrap est chargé et complex a adapté aux conditions des noisettes, c'est un casse tête : on se retrouve avec des conditions partout sur chaque ligne, et des squelettes illisibles ...

mes deux sous ...

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,

Spipr_vide a été mis sur la zone il y a une semaine, grâce au travail d'Alain Cousin et la participation de quelques autres.
http://zone.spip.org/trac/spip-zone/browser/_squelettes_/spipr-vide

Il a été déposé en l'état (on n'aurait peut-être pas dû le numéroter 1.0.0).
Maintenant la communauté va pouvoir le tester en long en large et en travers pour le finaliser.

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,

Je n'utilise plus du tout bootstrap (je construit mon framework css avec compass des modules Sass ), donc pas de Spip-r : refaire Aveline avec une dépendance a un framework ne pourrais être d'aucune utilité et dure a maintenir dans le temps.

A mon avis Une collection de noisette doit être comme un squelette : « Framewok agnostic »
pour être maintenable et evolutif (et ne pas subir les autres). On définie des class avec une méthodologie quelconque (BEM pour ma part) et on s'y tient : basta.

Pour le Noizettier Au final j'ai très peut d'utilisateurs qui sont interressés par le fait de se construire leur site tout seul et de le parametrer : ça me prend plus de temps de les former et de corriger, que d'écrire le squelette avec mes snippets.

Bref comme le dit Joseph, il est assez simple de faire un site responsive sans boottrsap et spip-r : pas besoin de 300kb de css pour 3 mediaqueries (phone,tablet,desktop) et encore je devrais dire 2 vu qu'on est en mobile first !!

Si besoin j'ai un squelette z-core dist qui est html 5 et parfaitement responsive si ça peut aider ... au passage 45 kb de css au lieu de 4 fois plus pour bootstrap ... avant de le passer sous Z-core je suis partit de la dist spip : donc j'ai les deux en responsive et Html5 avec Aria, micro-format etc , etc, . Les rêgles css sont les mêmes les thèmes partageables, et l'ensemble maintenable et partageable : ce qui était ma priorité dans mon cas.

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,

il faudrait voir avec Stéphane Santon et Mist. Graph X. Pour ma part, ma vie professionnelle ne permet pas actuellement d'avoir du temps à consacrer à ce projet.

Ceci étant dit, il est également possible de développer un thème responsive compatible avec les versions actuelles de Zpip-vide, Aveline et du noizetier.

Voir par exemple http://joseph.larmarange.net ou http://www.ceped.org

Cela demande néanmoins d'avoir les compétences pour développer un thème Z.

Cordialement

Adapter un squelette pour être compatible avec le noiZetier

Merci à vous pour tout ce travail.
- y-a-t-il une suite à cette discution (ailleurs) ?
- spipr_vide est-il disponible ?
J'ai un site test avec SPIPr-dist qui fonctionne en responsive, mais en je n'arrive pas à installer Aveliner.
...car un beau site responsive en spipr, paramétrable avec le noizetier et Aveline, c'est plutôt tentant !
encore merci

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,

Il me semble avoir trouvé le moyen d'éviter l'erreur 404 sur spipr_vide.

Dans zcore_pipelines.php , function zcore_recuperer_fond($flux) :
Si $GLOBALS['z_blocs_404']) n'existe pas, $z_blocs_404 prend comme minimum de blocs non vides le premier de la liste définie par $GLOBALS['z_blocs'], donc content.
Et à chaque zcore_recuperer_fond il dresse le bilan des blocs non vides, et déclenche l'erreur 404 au-delà du seuil déclaré.

Pour éviter ceci, il suffirait de déclarer dans \spipr_vide\spipr_vide_options.php :

$GLOBALS['z_blocs_404'] = array();

A valider.

Adapter un squelette pour être compatible avec le noiZetier

Bonjour Alain,

Où en es-tu de ce projet spipr_vide ?
Est-il disponible quelque part ?

Merci

Adapter un squelette pour être compatible avec le noiZetier

Euh oui tout à fait. Spip Zone est un espace collaboratif

Adapter un squelette pour être compatible avec le noiZetier

Pour Zcore, il faut en effet en discuter sur SPIP zone.

Pour le noizetier, créer une branche (pas un tag car on peut etre amené à faire de la correction de bug) de la version actuelle et ensuite faire évoluer le trunk (passer la nouvelle version en dev et changement majeur de numéro, faire pointer archivelist sur la branche).

Pour aveniler (version d'aveline adaptée à spipr) C'est su GitHub pour le moment https://github.com/larmarange/aveliner Forker et faire des pull request ou carrément me demander un droit de modif sur le dépot.

Adapter un squelette pour être compatible avec le noiZetier

Pour ton problème avec zcore c'est juste après dans la piepeline recuperer_fond au moment du test !test_espace_prive
AND strncmp($fond,"$z_contenu/",$z_nlength+1)==0
en gros si ça vaut 0 -> 404

Et sinon pour publier ton adaptation, pose la question sur irc ou sur la zone, pour voir comment les personnes qui gère le dépot voient le truc , mais a priori, comme le disait Joseph précédement :
- ajouter un /trunk pour le noizettier et déplacer la version précédente dans soit un tag ou une branche (en modifiant archivelist en fonction ^^)
- pour spipr-vide il faut créer le répertoire

et pour la paternité tant que tu ne met pas que tu est l'auteur en ayant éffacé les autres je ne vois pas ou pourrais être le problème ;-)

Adapter un squelette pour être compatible avec le noiZetier

Mon projet sur spir_vide est presque fini sauf le bug de la page vide, je voudrait savoir si j'ai le droit de le mettre sur spip zone car c'est juste une adaptation de spipr et du noizetier avec le travail de cedric et joseph donc moi je ne sais pas ou me situer ce n'est pas simplement du pompage de code mais une adaptation du noizetier à bootstrap 2 avec l'apport à spipr de configuration de layout plus performantes.

Adapter un squelette pour être compatible avec le noiZetier

merci joseph de ta réponse pour zcore je pense que c'est cette fonction en pipeline à modifier mais je n'ai pas la compétence pour je comprends le php mais ne sais pas vraiment l'adapter

function zcore_recuperer_fond($flux){ static $is_404 = false; static $z_contenu; if ($is_404){ if ($flux['args']['fond']==="structure"){ $is_404 = false; // pas de risque de reentrance $code = "404 Not Found"; $contexte_inclus = array( 'erreur' => "", 'code' => $code, 'lang' => $GLOBALS['spip_lang'] ); $flux['data'] = evaluer_fond('404', $contexte_inclus); $flux['data']['status'] = intval($code); // pas remonte vers la page mais un jour peut etre... // du coup on envoie le status a la main include_spip("inc/headers"); http_status(intval($code)); }

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,

désolé de répondre tardivement mais je n'ai malheurseusement guère de temps pour du développement SPIP. Et comme expliqué par Graph X, il y a encore de nombreux points non réellement stabilisés avant de passer à SPIPr.

Ceci étant dit, une petite remarque par rapport aux squelettes vides et Zcore. Le fait qu'un squelette vide n'est pas accepté par Zcore est une nouveauté par rapport à Zpip. Il faudrait voir dans Zcore où le test est effectué. Il serait plus simple de faire évoluer Zcore pour qu'il accepte des squelettes vides, éventuellement via une option à activer dans un fichier PHP d'options. Bien sur, une telle proposition devra être discutée au préalable sur la liste SPIP Zone.

Cordialement

Adapter un squelette pour être compatible avec le noiZetier

vous pouvez mettre votre version sur gihtub, cela me permettra de comprendre mieux le fonctionnement de github,, j'ai fait un spipr_vide avec la version des noisettes spipr par defaut importable donc une version très basique permettant de démarrer avec un spipr donc chaque page peut est noisifiées est transformable. version boostrap 2 mais sans aveline. pour l'instant j'ai réussi une deuxiéme version avec une adaptation d'aveline pour spirr mais sans aveline j'ai rapatriés toutes les fonctions aveline dans spipr ce qui m'a permis de comprendre le fonctionnement d'aveline mais grâce a cela les noisettes deviennent compatible boostrap 2 avec le bénéfice du travail de joseph. pour l'instant c'est spir sans aveline mais provisoirement l'adaptation à aveline sra à voir. j'ai une troisième version avec une version privé a la sarkaspip

Adapter un squelette pour être compatible avec le noiZetier

Je peut te mettre la version que j'ai faite sur GitHub de spipr-vide et noizettier,
- de mémoire je n'ai pas touché a structure.html, j'ai modifié les modèles du Noizettier pour qu'il prennent en charge les variables de zcore qui diffèrent de la version précédente. Effectivement les pages vide doivent contenir un commentaire html : sinon faut toucher a z-core.

Je n'ai pas beaucoup avancé sur ce projet : pour les raisons suivantes :

- la version de lessc maintenu par leafo et qui est la base du plugin less-css n'est plus maintenu par le dveloppeur : il est passé a scss et maintient maintenant uniquement cette class :/
Une autre class est dispo mais nécessite de ré-écrire le plugin....
La dernière version de less.php ne compile donc pas bootstrap3, et ne le compilera jamais tant que quelqu'un ne reprendra pas le developpement.

- donc outre le travail d'adaptation a bootstrap3 sur les class et sur les noizettes, il y'a déjà un travail a faire sur la compilation less pour la rendre compatible avec Bootstrap3.

Ensuite plus j'utilise bootstrap, plus je me demande si tout est bon et si suivre ce framework (ou un autre) est opportun, pour pérenniser un développement de squelette. Actuellement je travaille plus a construire un kit en utilisant le meilleur de chaque :
- Tetue a publié sur GitHub une base css pour la typo, bien mieux conçue que celle des autres frameworks que j'ai testé (généralement j'utilise celle de spip d'ailleurs même avec thelia ou autre), je la teste actuellement.
- J'ai refait une version du plugin Layout Gala pour Spip3, qui n'utilise pas la grille bootstrap, et propose une déclinaison responsive pour chaque layout, sans addition des class css, a la manière de semantic grid system.
- Modifié la version de less pour que les squelettes injectent leurs variables en priorité via des configs : l'utilisateur peut lui-même modifier son thème depuis l'espace privé, sinon on prend le fichier variables.less par defaut.
- Un plugin Font-awesome, pour ne plus utiliser les sprites glyphicon (au pire comme fall-down, pour les vielles croutes inférieures à ie8)
- pour une bonne partie du reste knacss me parrait être une base légère et très bien écrite (hormis le choix des noms de class qui me plait pas trop parfois, mais bon ...).
...

au final je n'utiliserais Bootstrap que pour les éléments UI, .... et encore certains plugins jquery externes sont mieux faits ou plus adaptés a mes besoins que ceux de bootstrap ///

Aussi après test je me suis rendu compte que le système du Noizettier prend pas mal de charge serveur lors des calculs ... donc sur une mutu ça me parait un peut gourmand ...

Adapter un squelette pour être compatible avec le noiZetier

sur spipr les pages ne peuvent pas êtres vides, je dois au minimum mettre un commentaire html pour ne pas avoir une erreur 404 avec Z-core. est-ce que quelqu'un a résolu le problème pour le spipr vide
j'ai créer un plugins spipr vide
dans structure.html j'ai ajouter la variable type et page

dans spipr_vide_options.php

define('_NOIZETIER_REPERTOIRE_PAGES','content/');
define('_NOIZETIER_LISTER_PAGES_SANS_XML',false);
define('_NOIZETIER_COMPOSITIONS_TYPE_PAGE',true);
define('_NOIZETIER_RECUPERER_FOND',true);

dans spipr_vide_pipelines.php, j'ai mis les blocs par défaut

function spipr_vide_noizetier_blocs_defaut($blocs) { unset($blocs['navigation']); unset($blocs['extra']); unset($blocs['contenu']); static $blocs_defaut = null; if (is_null($blocs_defaut)){ $blocs_defaut = array ( 'content' => array( 'nom' => _T('spipr_vide:nom_bloc_content'), 'description' => _T('spipr_vide:description_bloc_content'), 'icon' => 'bloc-contenu-24.png' ), 'aside' => array( 'nom' => _T('spipr_vide:nom_bloc_aside'), 'description' => _T('spipr_vide:description_bloc_aside'), 'icon' => 'bloc-navigation-24.png' ), 'extra' => array( 'nom' => _T('spipr_vide:nom_bloc_extra'), 'description' => _T('spipr_vide:description_bloc_extra'), 'icon' => 'bloc-extra-24.png' ), ); $blocs_defaut = pipeline('noizetier_blocs_defaut',$blocs_defaut); } return $blocs_defaut;
}

dans spipr_vide_pipelines.php je recupere les fonds mais pas avec le type defaut

function spipr_vide_recuperer_fond($flux){ // Le pipeline n'est utilisé que si le noiZetier est actif, ZPIP-vide pouvant être utilisé seulement pour un reset. if (defined('_DIR_PLUGIN_NOIZETIER')) { include_spip('inc/noizetier'); $fond = $flux['args']['fond']; if(!is_array($fond)) $bloc = substr($fond,0,strpos($fond,'/')); else $bloc = ''; // Si on est sur un bloc contenu, navigation ou extra, on ajoute les noisettes de la page par defaut // On ajoute également une ancre correspondant au nom du bloc if (in_array($bloc,array('content','aside','extra'))) { $contexte = $flux['data']['contexte']; $contexte['bloc'] = 'pre_'.$bloc; $contexte['composition'] = ''; if ($flux['args']['contexte']['voir']=='noisettes' && autoriser('configurer','noizetier')) $complements_pre = recuperer_fond('noizetier-generer-bloc-voir-noisettes',$contexte,array('raw'=>true)); else $complements_pre = recuperer_fond('noizetier-generer-bloc',$contexte,array('raw'=>true)); $contexte['bloc'] = 'post_'.$bloc; if ($flux['args']['contexte']['voir']=='noisettes' && autoriser('configurer','noizetier')) $complements_post = recuperer_fond('noizetier-generer-bloc-voir-noisettes',$contexte,array('raw'=>true)); else $complements_post = recuperer_fond('noizetier-generer-bloc',$contexte,array('raw'=>true)); $ancre = "\n"; $flux['data']['texte'] = $ancre.$complements_pre['texte'].$flux['data']['texte'].$complements_post['texte']; } } return $flux;
}

dans paquet.xml

Adapter un squelette pour être compatible avec le noiZetier

Fait (tu es ajouté comme collaborateur, tu dois donc pouvoir commiter directement sur le dépot original)

Adapter un squelette pour être compatible avec le noiZetier

Hello,

Je me suis abonné au projet, tu dois donc pouvoir m'ajouter ;-)

Adapter un squelette pour être compatible avec le noiZetier

C'est agréable de voir des personnes motivées. Libre à vous d'avancer. Je reviendrai dans les discussions quand j'aurai un peu de temps.

En résumé :

pour le noizetier, faire une branche sur spip-zone, pointer le zip sur la version actuelle, faire les modifs dans le trunk sans générer de zip
pour spipr-vide : développement directement sur la zone, puisque pas vraiment problématique
pour aveliner (noisettes aveline pour spipr), j'ai mis un espace de dev sur GitHub : https://github.com/larmarange/aveliner Si vous avez un compte GitHub, donner moi votre identifiant et je vous ajoute directement comme collaborateurs. Ainsi, vous pouvez publier directement dans le dépôt sans passer par pull request. N'hésitez pas à faire des branches pour tester

Adapter un squelette pour être compatible avec le noiZetier

Oui pour le noizettier, c'est juste les squelettes de visualisation/edition des noisettes qui sont a modifier, donc on peut peut-être les surcharger depuis le squelette spipr-vide dans un premier temps.

@Joseph

Prévoir peut-être aussi un squelette spipr-vide.

C'est sur ça que je suis parti, on est ok.

@alain : la prise ne main se fait rapidement, mais ça vaut le coup, on peut discutter de chaque noisette ou ligne de code et faire chacuns des pull-request simplement, c'est donc assez convivial. C'est basé sur le principe du Fork et ensuite chacun demande a poussé sa modification sur le projet principal.

Adapter un squelette pour être compatible avec le noiZetier

Pour le noizetier il n'y a pas de grand changement simplement le type page et les blocs le trunk en svn pour moi me va bien. github je ne connais pas mais je vais m'y mettre car l'idée me plait bien de mon coté un petit temps d'adaptation à github et je serait prêt pour le spipr vide et l'adaptation des noisettes et du noizetier.

Adapter un squelette pour être compatible avec le noiZetier

C'est en effet une bonne idée. Cela permettra de tester les évolutions d'Aveline sans perturber la Zone (par contre, je suis désolé mais j'aurai peu de temps à y consacrer dans les prochaines semaines).

Prévoir peut-être aussi un squelette spipr-vide.

Pour les évolutions du noizetier, cela peut se faire éventuellement sur la Zone, en créant une branche pour la version actuelle et en ne zippant que la version actuelle, ce qui permet de faire du dev dans le trunk sans danger.

Adapter un squelette pour être compatible avec le noiZetier

Hello,

Merci pour ces pistes, pour le moment je me demande si le plus pratique ne serait pas de partager cette « recherche/expérimentation » sur GitHub, afin de pouvoir profiter des différents outils que propose la plateforme, et au final si cela semble acceptable/utile à la communauté, il sera toujours temps de reverser, un projet cohérent et abouti sur Spip Zone/contrib...

C'est une proposition, après quelques heures passées sur les noisettes, il y'a pas mal de travaux (et réflexions) qui méritent d'êtres entamés a plusieurs, et il est inutile que nous fassions le même travail chacun de notre coté ;-).

Adapter un squelette pour être compatible avec le noiZetier

moi aussi je travaille aussi sur spir est le noizetier,, le fil de la discussion reflète bien le travail à faire pour bootstrap cedric a retiré tous les class de bootstrap dans zcore donc zcore est indépendant de tout framework. le passage de boostrap de 2 à 3 n'est pas à mon avis prioritaire pour ce projet. je me sers de ceci
http://bootstrap3.kissr.com/
http://upgrade-bootstrap.bootply.com/
pour votre projet avez-vous dans l'idée de mettre sur svn pour partager.

Adapter un squelette pour être compatible avec le noiZetier

Oui, en fait ça impliquerais un encore plus gros chantier du coup, et de longues discussions ;-)

Donc j'ai tenu compte de cet échange et commencé l'intégration du markup de spip-r, tel qu'il est décrit dans la documentation de la distribution, dans les noisettes Aveline.

Ce serait dommage de plus de ré-inventer la roue, et de ne pas profiter du travail énorme qui à été fait sur spip-r (micro-format, layout, ...), en plus de ré-écrire une doc, et de se priver de thèmes qui potentiellement pourraient êtres partageables.

Pour ce qui est de Bootstrap 3, j'ai commencé a étudier le problème et jouer avec la nouvelle version, en fait hormis le re-nomage de certaines class, ce n'est pas trop dur a ré-adapter, donc un gros rechercher/remplacer, peut déjà faire l'affaire.

Dans le principe, j'essaye de ne pas intégrer dans la mesure du possible, d'indications de layout/colonne dans les noisettes, pour limiter la casse.

Adapter un squelette pour être compatible avec le noiZetier

Je suis bien d'accord sur le problème évoqué ici : http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html

Car on perd la séparation HTML/CSS ou grosso modo on peut appliquer différentes CSS à une même structure HTML.

Mais du coup, on retrouve ce problème directement dans les squelettes spip-r. C'est un problème sans fin. La grande question est donc de voir si on pourrait partager un même markup entre différents squelettes (spip-r, Aveline, Sarka, la dist etc.) afin de mutualiser les thèmes. C'était justement une des grandes forces de Zpip qui semble-t-il disparait dans le cadre de spip-r.

Si tel est le cas, peut-être faut-il relancer un débat plus large. Malheureusement je pourrais pas être au Spip-noz. Sur Spip-Zone ?

Adapter un squelette pour être compatible avec le noiZetier

Tu as bien raison sur le point du thème, effectivement j'avais omis le fait que le thème le squelette : du coup ça complique un peut l'histoire :/ ...

Tiens, d'ailleurs en regardant rapidement http://spipr.nursit.com/html5 je vois des classes comme icon-calendar. N'est-ce pas pour le coup plus une mise en forme qu'une classe décrivant ce qu'est l'objet ?

Pour ceci c'est une css permettant d'afficher les icones du sprite fourni par bootstrap, donc tu as raison typiquement c'est de la mise en forme, c'est le genre de chose qui peut se solutionner :
le markup bootstrap utilisé est généralement

si par exemple tu est sur fond noir icon-white te permettra de choisir le sprite ou les iconnes sont blanches.

cela dit dans certains layout, je procède ainsi : pour afficher l'icon d'un bloc (gardon l'exemple du calendar) :
je met dans mon layout :


Calendrier
(...)

on pars ici du principe que sera une icone et dans la noisette on peut définir si oui ou non on souhaite afficher une icone...
et dans ma feuille de style theme.less utilisant bootstrap

#minical {
h3 > i {
.icon-calendar;
.icon-white;
}
}

Car less permet de réutiliser les class pour surcharger d'autres ....
C'est ce qui a été utilisé pour les layout_gala sur Sarkaspip et qui rejoint ce qui est expliqué dans cet article :
http://ruby.bvision.com/blog/please-stop-embedding-bootstrap-classes-in-your-html

On peut donc créer une « passerelle » entre un layout épuré ayant juste des ID et les

,

... tout en utilisant en théorie un framework ou l'autre, grâce a l'utilisation du pré-processeur css (ici Less ). La plupart des frameworks css proposent maintenant en standard une version SASS et LESS.

En gros pour résumer,dans l'idée, je pense que chaque framework peut avoir sa galerie de thème, mais pas forcément un squelette différent.

En effet, le but de zpip-vide + noizetier + aveline est de se passer d'un intégrateur. Le code des noisettes est prévu pour fonctionner directement avec un thème Z.
La question est donc comment faire pour que les noisettes fonctionnent avec les thèmes pour spip-r, c-à-d sans avoir à développer son propre thème.

Certe mais sur la version précédente de Z beaucoup de thème étaient proposés, la sur spip-r la plupart sont issus de Bootswatch, et finalement sont plus un changement des variables de bases du framework, il n'y a pas de réelle interaction sur le layout, juste des changement de couleur, de typo, de tailles ...je pense qu'un thème va un peut plus loin.

Je profite du sujet des thèmes pour évoquer la possibilité avec lessc.php d'injecter des variables à bootstrap avec php, je n'ai pas encore joué avec ça mais ça me trotte dans la tête depuis quelques temps ;-) on peut alors imaginer proposer à l'utilisateur de modifier son thème sans éditer le fichier variable.less, en profitant du cache, et tout ce qui va bien au niveau optimisation, sans passer par un éditeur de thème comme on peut le bidouiller actuellement sur spip en utilisant une feuille de style de type squelette_css.html, et en l'appelant par URL_PAGE.
La doc : http://leafo.net/lessphp/docs/#setting_variables_from_php

Bon ce sont des idées jetées comme ça, maintenant que la structure fonctionne et que l'injection de noisettes se fait au bon endroit et sur les bonnes pages, je vais me pencher sur Aveline et je te ferais un retour sur ce qui en résulte.

Adapter un squelette pour être compatible avec le noiZetier

Tiens, d'ailleurs en regardant rapidement http://spipr.nursit.com/html5 je vois des classes comme icon-calendar. N'est-ce pas pour le coup plus une mise en forme qu'une classe décrivant ce qu'est l'objet ?

Adapter un squelette pour être compatible avec le noiZetier

D'ailleurs, la question est plus générique que Aveline.

En effet, en quoi le contenu des différents blocs (qui est ce que génère le noizetier) est-il dépendant d'un framework CSS.

En fait, la question sous-jacente est : peut-on envisager que ce soit le thème et non le squelette qui dépende d'un framework CSS ? Autrement dit, pourrais-t-on avoir un contenu HTML des blocs de la page indépendant du framework ? (en effet, le HTML engloban les blocs est quant à lui fourni par le thème).

Adapter un squelette pour être compatible avec le noiZetier

Pour Aveline je suis un peu confus.

En effet, le but de zpip-vide + noizetier + aveline est de se passer d'un intégrateur. Le code des noisettes est prévu pour fonctionner directement avec un thème Z.

La question est donc comment faire pour que les noisettes fonctionnent avec les thèmes pour spip-r, c-à-d sans avoir à développer son propre thème.

Ensuite, ne connaissant pas bien ces différents frameworks, qu'appelles-tu composant spécifique au framework ? De quelles noisettes s'agit-il ?

Tu parles de normaliser les noisettes pour qu'elles puissent être utilisées par différent framework. Cela pourrait-être une bonne idée. Mais je ne vois pas dès lors comment tu fais l'articulation entre les noisettes et les thèmes ? Via un squelette vide du type spip-r vide ? dans les thèmes ?

D'ailleurs, n'ayant pas encore vraiment joué avec spip-r, qui embarque bootstrap ? est-ce les plugins squelettes ou bien les plugins de thèmes ?

Aurais-tu quelques exemples précis pour me dire à quoi tu penses ?

Adapter un squelette pour être compatible avec le noiZetier

Après une nuit de sommeil, qui comme dit souvent porte conseil ... ;-) Je reviens un peut sur ce que j'ai évoqué :

J'ai du modifié le squelette du noizettier d'affichage et édition des noisette, pour changer type en type_page, hormis ça je n'ai pas eut à intervenir sur le code du noizetier car tu avais prévu toute les pipelines adéquat, c'est plutôt bien et je pense opter pour une surcharge de ce squelette directement dans le plugin/squelette spipr_vide : ceci me parait la méthode la plus simple, plutôt que de faire un version du noizettier, pour un fichier.

Pour les noisettes de aveline c'est la réécriture en html5 qui va impacter la charge de travail, cela dit on peut se débrouiller pour que ce soit indépendant de la version du framework (ce serait le top), en documentant/normalisant suffisamment les ID et CLASS css et en utilisant les mixins et LESS.css, pour faire la passerelle. On peut même imaginer les rendre donc indépendant de bootstrap, et permettre a d'autres d'utiliser Aveline avec Fundation : ce qui serait le mieux quitte a faire le boulot et pérenniser : qui dit que bootstrap c'est LA solution ultime, ce n'est peut être qu'une mode après tout, et la rupture entre la version 2 et 3 m'as laissé un gout un peut amer quelque part, ayant passé 6 mois a migrer tout mes sites sous Bootstrap2 ^^.

Pour ce qui est des composants spécifiques aux frameworks css :
* j'opterais plus pour intégrer un dossier noizette dans le plugin du framework (comme pour les autres plugins) ceci permet de migrer facilement entre les version du dit framework, et de plus on peut alors imaginer qu'un autre framework comme Fundation ou KnaCSS pourrait lui aussi embarquer ses propres noizettes pour ses composants.

Ceci m'amène donc a déduire que le squelette devrait être plutôt un zcore_vide ou noizettier-dist au final, pour ne pas induire en erreur sur le lien avec un framework ou un autre, et surtout pérenniser le travail en s'affranchissant des dépendances, tout en laissant le maximum de liberté à l'intégrateur.

Bonne journée

Adapter un squelette pour être compatible avec le noiZetier

Merci pour ce retour détaillé qui sera très utile.

Pour ma part, je ne connais pas bootstrap et donc son impact sur le markup des noisettes. De plus, j'ai cru comprendre que la nouvelle version de bootstratp a des conséquences sur ce markup et que les squelettes spipr vont devoir être revu.

Il y a aura de toute façon un fork d'aveline vers un plugin aveline-spipr pour la mise en conformité des noisettes. Je me dis qu'il serait peut-être bon d'y voir plus clair sur les conséquences d'un éventuel changement de version de bootstrap (inutile de faire le travail de mise à niveau deux fois).

Bien cordialement

Adapter un squelette pour être compatible avec le noiZetier

il vaut mieux être débordé de travail ;-) C'est plutôt bon signe !

J'ai testé surtout l'adaptation/intégration du noizetier au layout pour le moment.
Quelques bricoles :
1- depuis le passage a z-core ce n'est plus type mais type-page, j'ai modifié dans le squelette, noizetier/noizetier-generer-bloc-voir-noizette.html

2-la navigation est dans inclure et n'as pas de dossier, j'ai modifié et créé un dossier /nav avec un fichier dist.html, histoire de tester avec le plugin menu, sur ce coup la par exemple il faut créer une noisette spécifique à bootstrap si on veut pouvoir utiliser la navbar-responsive + forms ou autres, celle du plugin menu casse le layout.

L'insertion des noizettes aveline se fait plutôt bien, pour les éléments natifs spip (cédric a très bien conçut la passerelle entre spip et bootstrap), mais je pense que pour profiter pleinement du passage a html5 il va effectivement falloir modifier une bonne partie du markup, et utiliser les nouvelles balises qu'on nous propose (figure,time, ...).
Ce qui nécessitera une version différente de Aveline répondant aux nouvelles spécifications.

L'autre sujet étant l'intégration des composant bootstrap en noisettes, la le markup est très spécifique, et je me pose la question : faut il fournir les noisettes de composant bootstrap dans un plugin/collection de noisettes à part de aveline ? ça me paraitrait le mieux, tout le monde n'as pas forcément envie d'utiliser la totalité du framework, même si je trouve ça un peut dommage, quand on embarque autant de css de n'en utiliser qu'un quart. L'exemple ci-dessus du plugin menu par exemple confirme.

Concernant le layout principal, j'ai mes petites manies et je n'utilise que très peut de div dans la structure principale , j'ai fait le choix dans body.html de ne pas utiliser la structure livrée en standard dans spip-r pour favoriser header,nav,section,aside en utilisant des mixins : mais ceci dit c'est un choix et chacun peut librement modifier ce fichier suivant ses principes.
Cette méthode m'arrange aussi car je ne travaille pas que avec spip et donc mes thèmes bootstrap peuvent passer d'une techno à l'autre avec très peut de modifications.

Voila pour le complément de test,je continue les expérimentations, si ça peut aider je poserais tout ça sur GitHub, avec mes notes, ça te fera toujours gagner un peut de temps, même si je pense que je n'arriverais certainement pas a une qualité de code comparable a la tienne ;-)

Adapter un squelette pour être compatible avec le noiZetier

Merci pour ce retour d'expérience.

Il est vrai qu'il faut que je commence ce chantier mais j'avoue être complètement débordé de travail en ce moment.

Y a-t-il bp de changement à appliquer à la synatxe HTML des noisettes d'Aveline pour vraiment suivre les spécifications de spip-r ?

Adapter un squelette pour être compatible avec le noiZetier

Bonjour Joseph,

J'ai fait mes premiers test sur Z-core,Spip-r , noizettier et aveline.

Effectivement ça se passe relativement bien, et on arrive assez rapidement a faire fonctionner l'ensemble. Je suis partit sur l'option spip-r_vide, afin de pouvoir utiliser la majorité des composant bootstrap dans les noizettes, et que l'utilisateur puis gérer complètement l'agencement des blocs.

La seul chose qui a l'aire de changer, en fait c'est que les pages ne peuvent pas êtres vides, je dois au minimum mettre un commentaire html pour ne pas avoir une erreur 404 avec Z-core.

Bravo encore pour ce travail, en tous cas.

Adapter un squelette pour être compatible avec le noiZetier

L'adaptation à Zcore / Spipr est bien prévue mais c'est un gros chantier qui n'a pas encore commencé (et pour lequel je n'ai actuellement pas le temps). Quelques précisions :

L'adaptation à Zcore est assez simple. Il n'y a pas de grands changements sauf sur un point : les fichiers contenu/page-sommaire.html deviennent content/sommaire.html Autrement dit les pages autonomes ne sont plus préfixés par page. Il faut aussi vérifier que le noizetier prenne bien en compte la déclaration des différentes zones. Ce n'est pas le plus dur.
Etre compatible Zcore est une chose. Ensuite reste à voir si on veut juste rajouter des noisettes aux squelettes de la distribution spipr existant ou bien avoir un spipr-vide (comme on a un zpip-vide). Ce n'est pas vraiment le plus dur mais il faut le coder.
Enfin, quelles noisettes ajouter. La structure HTML/CSS a évolué entre Zpip v1 et Spipr. La mise à jour d'Aveline à cette nouvelle structure HTML/CSS est le plus gros chantier en fait.

La question est de savoir aussi si le chantier SPIPr est assez stabilisé pour se lancer dans cette mise à jour. Pendant un bout de temps, ce n'était pas clair si la suite serait Zpip v2 ou Spipr. Il semble qu'aujourd'hui c'est effectivement plus clair. Mais le travail de portage reste un chantier conséquent.

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,

En quoi le Noizetier n'est-il pas compatible avc Zcore ?
Cette contribution permettrait-elle d'utiliser le noizetier avec spipr, qui me semble bien organisé comme zpip (contenu/, aside/, extra/) ?

Merci

Adapter un squelette pour être compatible avec le noiZetier

Merci pour votre réponse.

J'utilise effectivement un squelettes personnel et non un zpip

Merci pour la solution XML, j'ai finalement opté pour un plugin.
Voilà le code, si ça peut servir à quelqu'un à l'avenir...

// Fichier silo_noisettes_pipelines.php : Se brancher sur le pipeline du noizetier pour configurer les blocs function silo_noisettes_noizetier_blocs_defaut($blocs) { $categories = array(); $categories = lire_config($chemin='silo_noisettes/categories', $defaut=null); if (is_array($categories)) { foreach ($categories as $key => $value) { if ($value == '1') { unset($blocs['contenu']); } if ($value == '2') { unset($blocs['navigation']); } if ($value == '3') { unset($blocs['extra']); } } } $categorie_sup = lire_config($chemin='silo_noisettes/categorie_sup', $defaut=null); $categorie_sup_desc = lire_config($chemin='silo_noisettes/categorie_sup_desc', $defaut=null); if ($categorie_sup) { $blocs['cat_sup'] ["nom"] = $categorie_sup; $blocs['cat_sup'] ["description"] = $categorie_sup_desc; } return $blocs;
}

Hady

Adapter un squelette pour être compatible avec le noiZetier

A priori cette méthode dans mes options devrait pouvoir également s'appliquer aux pipelines des plugins (il n'y a pas de raison que le traitement soit différent).

Je vous invite donc à essayer.

Je suppose que vous utilisez un squelette personnel ?

Une autre approche consiste à déclarer chacune des pages à inclure dans le noizetier à l'aide d'un fichier XML (qui permet aussi de donner un titre, une icone et une description à chaque page) et d'y déclarer les blocs propres à la page à l'aide la balise . Voir exemple plus haut.

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,

Une question sur les trois types de blocs par défaut du plugin Noizetier (contenu, navigation, extra), dans la documentation il est indiqué « Les blocs ajoutés par défaut à chaque page peuvent être définis facilement à l'aide du pipeline noizetier_blocs_defaut. »

Comment faire pour se brancher sur ce pipeline sans passer par un plugin, directement dans mes_options.php ?

En effet, pour mon projet, je n'ai besoin que d'un bloc colonne de droite.
J'ai trouvé cette méthode pour « surcharger » un pipeline de spip, mais pas un pipeline de plugin

$GLOBALS['spip_pipeline']['nom_du_pipeline'] .= "|nom_de_la_fonction";
// Exemple d'ajout dans le pipeline "insert_head" :
$GLOBALS['spip_pipeline']['insert_head'] .= "|nom_de_la_fonction"; function nom_de_la_fonction($flux) { return $flux .= "Ce texte sera ajoute";
}

Merci pour vos éclaircissements.

Hady

Adapter un squelette pour être compatible avec le noiZetier

ok, j y suis arrivé !
me reste plus qu a comprendre comment j ai fait.....
merci bien.
triton

Adapter un squelette pour être compatible avec le noiZetier

Le contenu de cette page de doc est grosso modo destinée aux squelettes non Z.

Pour ton cas, peut-être que la lecure de ce commentaire http://www.spip-contrib.net/Creer-d... pourrait t'aider.

Adapter un squelette pour être compatible avec le noiZetier

Bonjour,
j avoue une certaine difficulté à comprendre le mécanisme...
J utilise zpip_vide et noizetier, je souhaite voir apparaitre un nouveau bloc administrable (sur le même principe que extra, contenu, navigation). sur mes pages squelettes a la fois en admin sur :
exec=configurer_page
et sur les pages publiques
Je ne vois pas ou je dois mettre quoi pour obtenir ce resultat ; j imagine un couple de fichier xml et html a surcharger quelque part, mais ou, et avec quoi dedans ?
Ou alors, je m attends à un truc qui n a rien a voir avec le systus (en gros le principe des « content placeHolder » sur sharePoint)
cordialement
triton