Recherche avancée

Médias (91)

Autres articles (105)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • Multilang : améliorer l’interface pour les blocs multilingues

    18 février 2011, par

    Multilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
    Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela.

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

Sur d’autres sites (7776)

  • Revision 84174 : Evolutions du plugin dont certaines peuvent être considérées comme des ...

    12 août 2014, par eric@… — Log

    Evolutions du plugin dont certaines peuvent être considérées comme des corrections :
    - la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
    - ajout et utilisation des autorisations classiques pour un obet ’page’ : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d’un coup.
    - ajout de l’autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
    - ajout des autorisations d’affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
    - utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d’articles éditoriaux. Par exemple, les listes d’articles de la page d’acceuil et de la page articles sont exemptes de pages uniques.
    Tout n’est pas parfait en particulier pour les autorisations car il est toujours possible d’accéder à une page unique en saisissant l’url même si on est pas autorisé. C’est en effet l’autorisation de l’article qui se déroule. Pour combler ce manque il faudrait surcharger l’autorisation de l’article en testant l’id de rubrique mais cela produirait des effets de bords avec d’autres plugins comme accès restreint.
    En fait, spécialiser un objet pour en créer un autre n’est pas une opération prévue dans l’api SPIP actuelle.
    Autre remarque : lors de la désinstallation du plugin on supprime la colonne ’page’ de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?

  • Revision 84174 : Evolutions du plugin dont certaines peuvent être considérées comme des ...

    11 juin 2018, par eric@… — Log

    Evolutions du plugin dont certaines peuvent être considérées comme des corrections :
    - la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
    - ajout et utilisation des autorisations classiques pour un obet ’page’ : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d’un coup.
    - ajout de l’autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
    - ajout des autorisations d’affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
    - utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d’articles éditoriaux. Par exemple, les listes d’articles de la page d’acceuil et de la page articles sont exemptes de pages uniques.
    Tout n’est pas parfait en particulier pour les autorisations car il est toujours possible d’accéder à une page unique en saisissant l’url même si on est pas autorisé. C’est en effet l’autorisation de l’article qui se déroule. Pour combler ce manque il faudrait surcharger l’autorisation de l’article en testant l’id de rubrique mais cela produirait des effets de bords avec d’autres plugins comme accès restreint.
    En fait, spécialiser un objet pour en créer un autre n’est pas une opération prévue dans l’api SPIP actuelle.
    Autre remarque : lors de la désinstallation du plugin on supprime la colonne ’page’ de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?

  • Revision 84174 : Evolutions du plugin dont certaines peuvent être considérées comme des ...

    11 juin 2018, par eric@… — Log

    Evolutions du plugin dont certaines peuvent être considérées comme des corrections :
    - la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
    - ajout et utilisation des autorisations classiques pour un obet ’page’ : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d’un coup.
    - ajout de l’autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
    - ajout des autorisations d’affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
    - utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d’articles éditoriaux. Par exemple, les listes d’articles de la page d’acceuil et de la page articles sont exemptes de pages uniques.
    Tout n’est pas parfait en particulier pour les autorisations car il est toujours possible d’accéder à une page unique en saisissant l’url même si on est pas autorisé. C’est en effet l’autorisation de l’article qui se déroule. Pour combler ce manque il faudrait surcharger l’autorisation de l’article en testant l’id de rubrique mais cela produirait des effets de bords avec d’autres plugins comme accès restreint.
    En fait, spécialiser un objet pour en créer un autre n’est pas une opération prévue dans l’api SPIP actuelle.
    Autre remarque : lors de la désinstallation du plugin on supprime la colonne ’page’ de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?

Navigation