Forum Ametys

il faut créer la page dans votre CMS: en tant qu'utilisateur je veux dire.
Il faut y mettre un contenu et le valider pour qu'il soit en ligne.

Là vous testez le site, coté visiteur, mais le site web n'a pas de page "index"

Ah oui, alors l'erreur du débutant, c'est que vous n'avez peut être pas de page "index" validée ?

Il faut que son url soit index. Du coup, il faut la créer avec comme titre "index" puis on peut la renommer en "Accueil"

Donc dans la conf du site de l'admin cms, vous mettez l'url du site. C'est ok.

Et dans la conf générale du CMS on vous demande l'url pour atteindre le tomcat du site, et l'ip pour protection.

Mais vos seconds screenshots, sont le conf du front office. Ce dont je vous parle, c'est dans la conf générale du backoffice. /cms/_admin et pas /_admin

Alors tant que vous n'arrive pas à vous connecter au tomcat directement, pas la peine de regarder du coté d'httpd.

Que contient votre fichier tomcat/logs/catalina.out comme log de démarrage ?

Je vous invite à faire un test de l'application en partant d'un tomcat vierge (sans même l'application CMS) : normalement il suffit de désarchiver l'application site dans le répertoire webapps/ROOT, afin d'obtenir par exemple le chemin suivant : tomcat/webapps/ROOT/WEB-INF/web.xml
Ensuite, vous vous connectez à http://localhost:8080/_admin et vous devriez voir l'administration du site (qui ressemble comme deux gouttes d'eau à celle du cms mais avec moins d'icones.

Est-ce bien le cas ?

Alors

Dans Ametys, il y a 2 applications à installer sur Tomcat.
Cela vous laisse la possibilité de les installer : sur le même tomcat, sur la même machine dans 2 tomcats ou sur deux machines différentes.

La première est le BO et la deuxième le FO.

Dans l'hypothèse d'1 seul tomcat, si votre tomcat est installé à l'url  et que le BO est installé dans le contexte /cms et le site dans le contexte ROOT alors vos urls de connexions sont

et /

Bonjour,

il s'agit d'un problème de configuration.

Quelle est l'url de votre back-office ? de votre front-office ? de votre site ? (il y a un piège : les deux dernières ne sont pas les mêmes )

Bonjour,

nous avons investigué le problème.
Actuellement, le plugin flipbook ne lance la préparation du PDF que si vous faites un lien de type flipbook vers le pdf.
Dans votre cas, vous avez un lien de type téléchargement simple.

Donc, dans l'état actuel des choses, il faut faire un lien flipbook pour que l'image flipbook fonctionne ; mais nous sommes en train d'améliorer la chose pour que l'image flipbook fonctionne de manière autonome.

Bonjour,
est-ce qu'après l'enregistrement, vous arrivez à visualiser le formulaire ? et est-ce qu'il fonctionne ?

Bonjour monsieur.

C'est la première fois que je vois cette erreur.
Savez-vous si java est installé sur votre machine et si oui en quelle version ?
(pour le savoir, vous pouvez lancer "invite de commande" dans le menu démarrer puis taper "java -version" et copier le résultat ici)

Concernant les modèles de charte: vous avez un modèle de charte (qui est grosso-modo une charte avec une liste de paramètres).
Ensuite vous pouvez "instancier" ce modèle et le paramétrer : vous obtenez alors une skin.
L'avantage est que les chartes restent liées au modèle et la modification du modèle peut être répercutée de manière automatique à toutes les chartes qui l'utilise.

Donc dans votre cas, vous auriez 1 seul modèle avec un paramètre de type image : "bandeau". Et vous auriez N chartes graphiques pour N sites. (Mais vous n'avez qu'à modifier le modèle pour que toutes les chartes graphiques soient corrigées). La modification du bandeau dans une charte graphiques n'impacte pas les autres chartes graphiques.

Pour répondre à votre question, si vous modifiez le bandeau sur 1 site, vous le modifiez en fait sur une skin. Mais comme chaque site à sa skin, pas d'effet de bord.
Par contre vous pouvez continuer aussi à partager la skin entre plusieurs sites si c'est votre cas d'utilisation et dans ce cas la modification du bandeau est visible sur tous les sites qui partagent la charte graphique.

Dans l'idée, c'est vraiment la solution propre : chaque site possède sa propre skin issu d'un modèle commun.

Si le docbook ne contient aucune données, c'est que le contributeur n'a pas "joué" avec la taille des colonnes. Et là vous ne pouvez rien faire d'autre que répartir la largeur en dur via une règle de 3.
A ma connaissance, FOP ne sait pas adapter la largeur d'une colonne à son contenu.

Bonjour,

en effet, c'est la XSL docbook2html qui fait le rendu graphique des champs de formulaire.
Par exemple, au niveau de votre skin vous avez peut-être déjà un fichier cms\skins\demo\stylesheets\io\docbook2html.xsl qui va pouvoir surchargé le rendu par défaut amené par le plugins forms :

Attention quand vous surchargez des rendus par défaut dans docbook2html.xsl, il faut comprendre que toutes les XSLs sont concaténées dans un ordre non-déterministe.
DONC contrairement aux imports classiques, lorsque vous souhaitez surcharger un rendu d'un template existante, il faut ajouter l'attribut *priority="100"* pour que votre template soit choisi à coup sûr.