Forum Ametys

La raison historique à ça est qu'à l'origine, l'authentification par formulaire n'existait pas. Nous n'avions que l'authentification par SSO (CAS, NTLM, ...) ou par HTTP/BASIC, pour lesquels la déconnexion n'a souvent pas de sens.

Mais il est vrai que maintenant, c'est nettement plus discutable
Il est prévu de régler ça très bientôt.

Sur un sujet connexe, en tant qu'administrateur, dans l'application _admin, il est possible de se connecter au CMS "en tant que" n'importe quel utilisateur.

Bonjour,

On développe tous sous Eclipse, mais on a pas de plugins dédiés.

Lepido était effectivement un plugin Eclipse pour manipuler les sitemaps Cocoon, mais il n'est plus maintenu depuis des années, et en fait n'avait jamais eu qu'une utilité toute relative. Ca n'avait d'ailleurs rien à voir avec Ametys, mais uniquement avec Cocoon.

On s'est souvent posé la question d'avoir un plugin Eclipse pour écrire un plugin Ametys, mais dans la pratique, on fonctionne souvent par copier/coller, donc on a jamais rien fait de ce côté.

Cédric

c'est juste que dans une instruction <xsl:with-param>, il ne faut pas utiliser de '{' autour de la valeur

Ca donne donc :

<xsl:attribute name="data-date"><xsl:call-template name="timestamp"><xsl:with-param name="date" select="$day/@date"/></xsl:call-template></xsl:attribute>

Bonjour,

Du point de vue du noyau Ametys, un blog est un site comme un autre, avec sa propre skin, qui est nommée comme vous le souhaitez.
Ensuite, pour fonctionner correctement, le plugin blog attend effectivement un template nommé "blog" dans sa skin.
Idéalement ce template doit au moins contenir trois zones "default", "about" et "aside" qui permettent de pré-positionner des services et des contenus à la création du blog.

Un embryon de documentation est disponible à , n'hésitez pas à nous dire s'il vous manque quelque chose.

Cédric

Oui il faut un hébergerment java.
Certains hébergeurs le proposent en mutualisé, mais pas tous.

Pour être complet sur le sujet, vous pouvez aussi jeter un œil à Lunacloud :

En effet il faut un hébergement Java.

Soit en hébergement mutualisé, il y en a beaucoup moins que d'hébergeurs PHP, mais ça existe tout de même : , , ...
Soit avec un serveur dédié chez n'importe quel hébergeur, c'est pas forcément plus cher (pour les petites configs), mais il faut tout installer soi-même.
Tout dépend donc du besoin et du budget ...

Indeed, your plugin.xml is syntactically wrong.

A plugin is made of "features", each feature may contains "extensions".

Your plugin should then look like :

<?xml version="1.0" encoding="UTF-8" ?>

<plugin xmlns="http://www.ametys.org/schema/plugin"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.ametys.org/schema/plugin http://www.ametys.org/schema/plugin-2.0.xsd"
        runtimeVersion="2.0" version="2.0">

  <feature name="spreadsheet">
    <extensions>
        <extension point="org.ametys.web.service.ServiceExtensionPoint"
            class="org.ametys.web.service.StaticService"
            id="org.ametys.plugins.spreadsheet.Spreadsheet">
 
            <url>service/spreadsheet/spreadsheet.xhtml</url>
 
            <label i18n="false">Spreadsheet</label>
            <description i18n="false">Create Custom Spreadsheet</description>
 
        </extension>
    </extensions>
  </feature>
</plugin>

Concerning the attributes :

- an extension is always an extension to an "extension-point". There's several extension points in Ametys to help plugin writers to customize many parts of Ametys. The "point "attribute" refers to one of these points.
A plugin itself may create new extension points if needed.
The list of existing extension points and all available extensions to them is found in the Administration application, under the "Plugins & workspaces" section.

- the id is the identifier of your extension. it should be unique among other extensions to the same "extension-point". We use to have globally unique identifiers.

- the "class" attribute points to the actual Java class implementing the extension. In your case, "StaticService" is the most simple implementation of a Service, taking all its parameters in the XML conf of the plugin.

Bonjour,

Alors je vais essayer de répondre dans l'ordre !

1) Tout dépend de ce que vous essayez de développer. Je pars du principe que vous voulez modifier la charte graphique ou les paramètres de l'application, donc dans ce cas le mieux est de partir du template de démo. Vous pouvez de manière générale vous référer à la documentation d'intégration :  ou poser vos questions ici.

2) les chartes graphiques crées dans le répertoire skins sont immédiatement disponibles dans Ametys. En allant dans l'interface d'administration des sites, et dans l'interface de configuration d'un site en particulier, vous pouvez modifier sa charte graphique en sélectionnant parmi toutes les skins existantes.

3) Là encore, tout dépend de ce que vous voulez migrer d'une instance à l'autre : du code, des paramètres, des chartes graphiques, des données ?
Si c'est une skin, il suffit de copier le répertoire dans son intégralité, il ne dépend de rien d'autre.

while you're 100% right when it comes to developing new features, it is more rarely the case for publishing internet/intranet sites, where composing should be often near real-time and where CMS have builtin workflow features to implement the compose/validate/publish cycle!

Anyway, copying the repository depends of the underlying storage system used by Jackrabbit. If you use the default one (embededd Derby database), the "repository" directory is self-contained and you may simply copy the whole directory from one place to another.

What do you mean by "development" ? Do you mean new features/plugins ? New graphical skins ? Updated config files ?

Hi,

My first guess is that you're having a filesystem rights issue.
Could it be that you're using the Ubuntu-packaged Tomcat 7 (process run as "tomcat7") and the application unzipped as another user (probably yours) in a directory where "tomcat7" does not have any write access ?
If so, there's two main solutions : either don't use the packaged Tomcat, but an unzipped Tomcat run with the same user than Ametys files, or give the Ametys files a write access to the user running Tomcat.

The environment you describe is perfectly suited to run Ametys, and actually probably the most used in production.

When write access is allowed, a log file is output in the WEB-INF/logs directory of the application

Regards,
Cédric