Il est préférable d’avoir lu Fonctionnement par défaut du noiZetier au préalable.
Deux cas de figures peuvent se présenter :
- Votre squelette organise ses contenus d’une manière analogue à Zpip [1] : les contenus des différents blocs sont définis par des squelettes portant le nom de la page et situés dans un sous-répertoire portant le nom du bloc.
- Votre squelette suit une toute autre logique organisationnelle.
Squelette avec une organisation analogue à Zpip
Deux éléments devront, selon le cas, être personnalisés :
- le répertoire à examiner pour lister les pages pouvant recevoir des noisettes et
- la liste des blocs par défaut de chaque page.
Personnaliser le répertoire contenant les pages du site
Ce répertoire peut être facilement défini dans un fichier d’options en lui ajoutant :
define('_NOIZETIER_REPERTOIRE_PAGES','mon_repertoire/');
Si ce répertoire contient à la fois des squelettes qui correspondent à des pages et des squelettes inclus, il est possible de restreindre la liste uniquement aux pages décrites par un fichier XML en définissant dans un fichier d’options la constante _NOIZETIER_LISTER_PAGES_SANS_XML
à false
.
Personnaliser les blocs de chaque page
Les blocs ajoutés par défaut à chaque page peuvent être définis facilement à l’aide du pipeline noizetier_blocs_defaut
.
Une autre manière de procéder consiste à décrire chaque page à l’aide d’un fichier XML et d’inclure la définition des blocs dans ce fichier avec des balises <bloc />
de la forme :
<bloc id="sousrepertoire" nom="plugin:chainelange" description="plugin:chainelange" icon="img/fichier.png" />
Autre type de squelette
Si votre squelette suit une toute organisation, il est toujours possible d’utiliser le noiZetier à condition de lui définir les pages et les blocs et de lui préciser dans vos squelettes où inclure les noisettes.
Définition des blocs et des pages
Le plus souvent, à chaque page du site correspond un squelette situé à la racine. Dès lors, le plus simple consiste à décrire toutes les pages pouvant recevoir des noisettes à l’aide de fichiers XML situés à la racine, les blocs étant définis dans ces fichiers. Dans le fichier d’options, il suffit dès lors de définir les constantes _NOIZETIER_REPERTOIRE_PAGES
et _NOIZETIER_LISTER_PAGES_SANS_XML
comme suit :
define('_NOIZETIER_REPERTOIRE_PAGES','/');
define('_NOIZETIER_LISTER_PAGES_SANS_XML',false);
Si cette approche n’est pas adaptée à votre squelette, il est toujours possible d’utiliser le pipeline noizetier_lister_pages
pour transmettre au noiZetier la description adéquate des pages et des blocs.
Insérer les noisettes au bon endroit
Tout d’abord, vous pouvez désactiver l’insertion automatique des noisettes à la fin des squelettes bloc/page.html
en définissant dans un fichier d’options la constante _NOIZETIER_RECUPERER_FOND
à false
.
Ensuite, le plus simple consiste à inclure au bon endroit dans vos squelettes le fichier noizetier-generer-bloc.html
de la manière suivante :
<INCLURE{fond=noizetier-generer-bloc}{bloc=nombloc}{type=nompage}{composition=nom_composition}{env}>
ATTENTION : cette inclusion ne permet pas de bénéficier de la fonctionnalité d’édition des noisettes depuis l’espace public. Pour pouvoir bénéficier de cette fonction, utilisez plutôt le code ci-dessous :
[(#ENV{voir}|=={noisettes}|et{#AUTORISER{configurer,noizetier}}|oui)
<INCLURE{fond=noizetier-generer-bloc-voir-noisettes}
{bloc=nombloc}{type=nompage}{composition=nom_composition}{env}>
][(#ENV{voir}|=={noisettes}|et{#AUTORISER{configurer,noizetier}}|non)
<INCLURE{fond=noizetier-generer-bloc}
{bloc=nombloc}{type=nompage}{composition=nom_composition}{env}>
]
Discussions par date d’activité
7 discussions
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
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.
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
Répondre à ce message
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
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 :
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.
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.
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 ?
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 ;-)
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
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
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 ?
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).
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 ?
Tu as bien raison sur le point du thème, effectivement j’avais omis le fait que le thème
<utilise>
le squelette : du coup ça complique un peut l’histoire :/ ...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 :
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
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
<header>,<aside> ...
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.
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.
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 ?
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.
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.
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é ;-).
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.
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.
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
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.
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é :
Hello,
Je me suis abonné au projet, tu dois donc pouvoir m’ajouter ;-)
Fait (tu es ajouté comme collaborateur, tu dois donc pouvoir commiter directement sur le dépot original)
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
dans spipr_vide_pipelines.php, j’ai mis les blocs par défaut
dans spipr_vide_pipelines.php je recupere les fonds mais pas avec le type defaut
dans paquet.xml
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 ...
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
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
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
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.
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 ;-)
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.
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
:A valider.
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
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
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.
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.
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 ...
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...)
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.
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 ?
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
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
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 ?
ok autant pour Zspip-dist dans le trunk (en V2) est compatible Zcore ....
Répondre à ce message
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 ;
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.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 ....
Répondre à ce message
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.
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 :
Peux-tu tester et me dire si ça fonctionne ?
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.
Merci. Je viens de mettre la doc à jour.
Répondre à ce message
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
Merci pour vos éclaircissements.
Hady
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
<bloc />
. Voir exemple plus haut.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...
Hady
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.
Euh oui tout à fait. Spip Zone est un espace collaboratif
Bonjour Alain,
Où en es-tu de ce projet spipr_vide ?
Est-il disponible quelque part ?
Merci
Répondre à ce message
ok, j y suis arrivé !
me reste plus qu a comprendre comment j ai fait.....
merci bien.
triton
Répondre à ce message
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
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.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires : |