Forum Ametys

Même si la combinatoire le permettait, créer autant de gabarits que des pages éditoriales nécessaire est un peu un non sens : dans ce cas là autant créer un seul gabarit et éditer le contenu de manière personnalisée (avec un service de remontée de contenu au lieu de filtres).
Dans ce cas, couplé à la ré-écriture d'url ça pourrait marcher.

Je m'explique : dans le CMS vous créez n pages pour vos n profils (toutes filles d'une page commune), dans chacune, vous mettez de la remontée de contenu adaptée au profil. Et vous redirigez l'url de cette page commune vers la bonne page fille (grâce aux Alias qui supportent depuis peu les urls avec paramètres).
Les redirections ne sont pas mises en cache.
Par contre au niveau du fil d'ariane de la page vous verrez la page intermédiaire, et via le moteur de recherche ou le plan du site vous n'empéchez pas les visiteurs de voir les pages qui ne les concernent pas : c'est juste une redirection automatique.

(on aurait aussi pu simplement faire le travail en javascript, mais c'est pas très propre du tout !)

Avec textarea c'est logique, car du coup la chaine de caractère stockée contient de caractères de retours chariots mais ça en HTML ça ne donne rien, sauf si vous mettez par exemple une balise <pre> autour du rendu.

Par contre en rich-text cela devrait tout à fait marcher puisque dans ce cas la chaine de caractère contient des <p>. Le problème doit dans ce cas venir de la façon que vous utiliser pour récupérer cette valeur : en effet dans le cas d'un richtext il ne faut pas faire <xsl:value-of> mais plutot quelquechose comme

<xsl:apply-templates select="metadata/content/docbook:article">
    <xsl:with-param name="level" select="2"/>
</xsl:apply-templates>

où "content" est le nom de ma métadonnée
et où le "level" à 2 veut dire que les "Titre 1" doivent être convertis en <h2>

Non, il n'est pas possible de remplacer ce fichier
Normalement, on est est pas censé touché à ça, sauf si vraiment ça pêche au niveau de la charte (notamment à cause de marges par exemple) : c'est apporté par le CMS et pas par la skin.

Donc mettez le dans une CSS de la skin mais par contre, vous pouvez ne charger cette css QUE dans le backoffice
en fait <xsl:if test="$back-office = 'back' or $back-office = ''">

Pour l'emplacement du fichier, oui et non
Il est possible de surcharger en mettant le fichier là où vous l'avez mis mais du coup cela concerne toutes les chartes graphiques. Si vous en avez une seule, ça ne change pas grand chose.
Et normalement, quand ça marche, vous pouvez encore surcharger dans la charte.

L'algo est globalement:
* je cherche dans la charte graphique
* sinon je cherche dans WEB-INF/param
* sinon je prends la version par défaut du plugin

C'est bizarre car on fait cela tout le temps.
C'est bien le fichier article-main.xsl qu'il faut. J'ai encore un exemple sous les yeux pour un projet qui fonctionne skins\XXXXXX\stylesheets\content\article\article-main.xsl

Question bête : est-ce que votre test est bien fait avec un article ? (et pas un actualité par exemple)

pouvez-vous copier-coller le contenu de la XSL ?

une bonne astuce pour voir si le contenu de la xsl n'a pas d'effet, ou si la xsl n'est pas bien placée : vous pouvez saisir une XSL erronée qui ne contient pas de xml par exemple, ou qui contient des balises non fermées.
Du coup si elle est bien prise en compte vous aurez une erreur et saurez que le fichier est bien placé mais que son contenu ne va pas.

Oui, nous avons prévu d'ajouter cet étape de workflow.
Si vous êtes pressés et connaissez OSWorkflow (qui est l'outil de workflow que nous utilisons), vous pouvez modifier le fichier WEB-INF/param/workflow.xml....

Mais donc, ça viendra dans une prochaine version.

D'accord.

Alors en fait la technique que nous utilisons aujourd'hui est plus satisfaisante du point de vue intellectuel
* Afficher le titre du contenu
* Afficher les titres dans le contenu

Ca permet une meilleure indexation des contenus.
Si vous n'avez pas trop de contenu, c'est la solution que je vous recommande.

Si vous ne vous le sentez pas, vous pouvez ne plus afficher ce titre.
Pour cela, il faut surcharger le rendu par défaut de chaque type de contenus (article, actualités par ex)
Pour cela, lisez cette trop brève doc
En gros, vous devez créer un fichier dans votre skin : skins/VOTRESKIN/stylesheets/content/article/article-main.xsl. Pour remplir ce contenu, vous pouvez bien sur vous inspirer du fichier fourni par le noyau

(vous pouvez vous limiter à surcharger les templates que vous voulez modifier - dans votre cas c'est celui là
    <xsl:template name="view">
où vous devez retirer la ligne de titre (et de sous-titre)

Cela dit je vous déconseille cette solution, car le titre et le sous-titre n'ont plus d'intérêts à ce moment là
)

Vous pouvez aussi vous contenter de cacher le titre avec de la CSS, mais ne dites pas que c'est moi qui vous l'ai dit.

Non, quand vous mettez un tag <zone> c'est le CMS qui prend la main et vous ne pouvez plus rien faire.
Dans votre cas, je serai tenté de vous dire de créer deux zones à cet endroit là.

Bonjour,

est-ce que vous parlez de la charte graphique de démo ?
parce que pour elle ce n'est pas le cas je crois.

En tous cas, dans Ametys v3, il est possible de mettre plusieurs contenus par page, auquel cas le titre de la page est une sorte de "racine" (hierarchiquement) aux titres de tous les contenus
Si vous ne souhaitez mettre qu'un seul contenu par page, vous pouvez en effet retirer l'affichage du titire de la page et décaler les titres de contenus d'un niveau. Par exemple, si actuellement les titres de page sont des <h2> et les titres des contenus des <h3> ; ce qui deviendrait : les titres de pages n'apparaissent pas et les titres de contenus sont des <h2>
(pour cela, dans la déclaration de la zone, il faut baisse le "level")

Aïe ! en effet cela posera problème : Il faut que la page en question ne soit pas mise en cache.
Certains services (comme le moteur de recherche) désactive la mise en place du cache de la page, mais dans votre cas qu'est-ce qui pourrait se charger de cela ?

Vous pourriez mettre un service non-cachable ou en créer un à cette fin...

En bas de chaque newsletter doit être présent un lien qui permet de se désabonner.
Si il est absent, c'est l'intégrateur de votre charte graphique qui doit le mettre (en se basant sur la charte de démo par exemple)