Adapter un squelette pour être compatible avec le noiZetier

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}>
]

Notes

Discussion

7 discussions

  • 2

    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

  • 40
    Stéphane Santon

    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 :

      • 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.

    • 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 :/ ...

      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

      <i class="icon-calendar icon-white"></i>

      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 :

      <div id="minical">
      <h3><i></i>Calendrier</h3>
      (...)
      </div>

      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 <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.

      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.

    • 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

      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.

    • 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
    • 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

      <INCLURE{fond=body,env}{type=#ENV{type-page}}{page=#ENV{type-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 = "<a name=\"$bloc\"></a>\n";
      			$flux['data']['texte'] = $ancre.$complements_pre['texte'].$flux['data']['texte'].$complements_post['texte'];
      		}
      	}
      	return $flux;
      }

      dans paquet.xml

      <pipeline nom="autoriser" inclure="spipr_vide_autorisations.php" />
      <pipeline nom="noizetier_blocs_defaut" inclure="spipr_vide_pipelines.php" />  
      <pipeline nom="recuperer_fond" inclure="spipr_vide_pipelines.php" />
       <pipeline nom="ieconfig_metas" inclure="spipr_vide_ieconfig_metas.php" />
       <pipeline nom="noizetier_config_export" inclure="spipr_vide_pipelines.php" />
    • 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

      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));
      		}
    • 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.

    • Stéphane Santon

      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.

    • 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.

    • Stéphane Santon

      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...)

      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.

    • 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

  • 2

    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

  • 3

    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 :

      <INCLURE{fond=noizetier-generer-bloc}
          {bloc=nombloc}{type=nompage}{composition=nom_composition}{env}>

      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)
          <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}>
      ]

      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

  • 5

    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

    • 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...

      <!-- fichier paquet.xml : Se brancher sur le pipeline du noizetier "noizetier_blocs_defaut" -->
      
      <pipeline nom="noizetier_blocs_defaut" inclure="silo_noisettes_pipelines.php" />

      // 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

    • 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

    • Stéphane Santon

      Bonjour Alain,

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

      Merci

    Répondre à ce message

  • triton

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

    Répondre à ce message

  • 1
    triton

    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

    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 :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

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.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom