Recherche avancée

Médias (91)

Autres articles (55)

  • (Dés)Activation de fonctionnalités (plugins)

    18 février 2011, par

    Pour gérer l’ajout et la suppression de fonctionnalités supplémentaires (ou plugins), MediaSPIP utilise à partir de la version 0.2 SVP.
    SVP permet l’activation facile de plugins depuis l’espace de configuration de MediaSPIP.
    Pour y accéder, il suffit de se rendre dans l’espace de configuration puis de se rendre sur la page "Gestion des plugins".
    MediaSPIP est fourni par défaut avec l’ensemble des plugins dits "compatibles", ils ont été testés et intégrés afin de fonctionner parfaitement avec chaque (...)

  • Activation de l’inscription des visiteurs

    12 avril 2011, par

    Il est également possible d’activer l’inscription des visiteurs ce qui permettra à tout un chacun d’ouvrir soit même un compte sur le canal en question dans le cadre de projets ouverts par exemple.
    Pour ce faire, il suffit d’aller dans l’espace de configuration du site en choisissant le sous menus "Gestion des utilisateurs". Le premier formulaire visible correspond à cette fonctionnalité.
    Par défaut, MediaSPIP a créé lors de son initialisation un élément de menu dans le menu du haut de la page menant (...)

  • Des sites réalisés avec MediaSPIP

    2 mai 2011, par

    Cette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
    Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page.

Sur d’autres sites (9847)

  • Evolution #3445 (Nouveau) : ergonomie de revisions : lien retour à l’objet manquant et cas des révi...

    11 mai 2015

    Sur SPIP 3.1 beta l’ergonomie de la page révisions pose 2 problèmes (voir ma capture)

    - on n’a plus les 2 liens "retour à l’objet" / "éditer l’objet" (contrairement à SPIP 3.0)

    - en cas de nombreuses révisions la page est devient très haute ...
    dans ce cas, faudrait-il :
    - ajouter pagination ? (génant pour les diff)
    - ajouter un formulaire pour saisir les versions de début et de fin avec que l’on peut comparer. ?

  • Anomalie #3261 : Non prise en compte des champs

    10 septembre 2014

    2h d’investigation de la question... Quelques idées que je mets ici pour voir et vous lire...

    J’imagine donc un champ suppl dans spip_urls mais ne s’agissant pas d’un objet, et vu que les urls peuvent concerner des objets linguistiquement marqués ou non, on l’appelerait multi plutôt que lang.

    Idées, côté "privé" :
    - à chaque création/modification d’objet positionné sur lang_choisie=non ou n’ayant pas ce champ, voir si le titre est en et créer autant d’url que de langues présentes (url=>titre traduit, multi=> langue de la traduction)
    - si l’objet à une langue, soit inhiber le champ multi (un code défini), soit le remplir avec la langue de l’objet. Vérifier le cas où on change la gestion linguistique d’un objet sur un site en cours...
    - Idem pour les recalculs d’urls
    - pour le privé, on peut passer le paramètrre multi et le transmettre aux préférences auteur (ou forcer la dépendance au plugin mutlilang et la gérer) ?

    Côté public :
    - produire les urls (de tout type sauf "page" il me semble) en ajoutant /[code_langue]/ en début d’url (ou un paramètre multi=[code_langue] dans certains cas ?), selon l’#ENVlang...(si on est dans le public) ou...
    - si l’objet a une langue et lang_choisie=oui (ou pas de lang_choisie), on récupère sa langue pour définir #ENVlang
    - si l’objet n’a pas de lang, récupérer la langue de l’auteur ?
    - pour décoder l’url, avec le htaccess on détecte le [code langue] et on convertit en lang=[code_langue] pour avoir la valeur de multi ? Si pas de htaccess. On peut aussi s’en passer et récupérer la valeur de multi encodée en spip_urls pour l’url demandée (?)
    - il faut modifier le cookie de langue s’il est présent.

    ...

  • Evolution #3230 (Nouveau) : Ajouter une pagination standard intégrant les informations sur les pag...

    17 juin 2014, par RastaPopoulos ♥

    Nous n’avons pas de modèle de pagination contenant déjà les informations correctes à propos des pages générées, afin de répondre à la bonne pratique 133 :
    http://checklists.opquast.com/fr/oqs-v2/criteria/la-page-des-resultats-de-recherche-indique-le-nombre-de-resultats-le-nombre-de-pages-de-resultats-et-le-nombre-de-resultats-par-page

    Sur les trois informations demandées, le nombre total de résultats et facilement accessible grâce à #GRAND_TOTAL, et il est généralement utilisé en début de page. Ce point-là n’est donc pas un problème.

    En revanche, au moins un de nos modèles de pagination standard, devrait générer les informations suivantes :
    - Le nombre de pages de résultats
    - Le nombre de résultats par page

    Par exemple quelque chose comme "4 pages de 10 articles". À placer avant (ou après, mais je dirais plutôt avant) la liste des liens de pages.

    Idées en plus :
    - cela pourrait être une option à passer pour l’avoir, ce qui permettrait de l’ajouter sur tous les modèles fournis par défaut
    - il faudrait que la chaîne soit personnalisable pas trop difficilement (si on veut mettre "résultats" plutôt que le nom de l’objet par ex)

Navigation