Recherche avancée

Médias (1)

Mot : - Tags -/musée

Autres articles (48)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Creating farms of unique websites

    13 avril 2011, par

    MediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
    This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)

  • Contribute to a better visual interface

    13 avril 2011

    MediaSPIP is based on a system of themes and templates. Templates define the placement of information on the page, and can be adapted to a wide range of uses. Themes define the overall graphic appearance of the site.
    Anyone can submit a new graphic theme or template and make it available to the MediaSPIP community.

Sur d’autres sites (10767)

  • Anomalie #3617 (Résolu) : objet_modifier_champ

    10 décembre 2015, par jluc -

    objet_modifier_champ est l’api générique de modification d’un objet,
    mais le code de la fonction appelle controler_md5 avec l’argument $_POST,
    pour des vérifications qui n’ont de sens éventuellement que dans un formulaire.
    cf https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/modifier.php#L170

    Du coup, quand on appelle pas objet_modifier_champ dans un formulaire, un conflit est parfois détecté sans raison.

  • Evolution #3361 (Nouveau) : Tri par défaut des entrées des menus du bandeau de l’espace privé

    5 décembre 2014, par tcharlss (*´_ゝ｀)

    Sur un site nu, sans aucun plugin, le bandeau de navigation de l’espace privé reste utilisable car il y a peu d’éléments.
    Par contre, dès que les menus commencent à se peupler en installant des plugins, ça devient difficile de s’y retrouver car il n’y a pas de logique de tri apparente.
    Mais surtout, entre 2 sites ayant les mêmes plugins, les entrées des menus peuvent être classées différement. C’est un peu gênant pour jongler entre un site de dev et un site en ligne, cf. image en pièce-jointe.

    À priori et à fortiori, les entrées sont organisées de la sorte :

    • D’abord les entrées des plugins du core, toujours dans le même ordre, fixé.
    • Ensuite les entrées ajoutées par les plugins, et là, c’est la fête. Ils sont rangés selon la date de leur installation, peut-être ?

    Bref, je propose :

    • Soit de tout classer alphabétiquement
    • Soit idem, tout en plaçant en premier les entrées du core (donc 2 groupes, chacun classés alphabétiquement)

    Qu’en pensez-vous ?

    Pour les gens curieux, les fichiers concernés sont ceux-là :

    Comme je suis sympa, je mets ça en priorité « bas »

  • Evolution #3361 : Tri par défaut des entrées des menus du bandeau de l’espace privé

    6 décembre 2014, par tcharlss (*´_ゝ｀)

    Voilà ma petite proposition de patch et mes explications (un peu verbeuses, mais ça m’aide à retenir).

    Dans http://core.spip.org/projects/spip/repository/entry/spip/prive/squelettes/inclure/barre-nav.html#L46, c’est la boucle , ligne 46, qui affiche les entrées.
    Tel quel, on ne peut pas faire de tri au moyen de {par xxx}, car la chaîne de langue n’est pas contenue dans #VALEUR{menu}, juste le nom de l’entrée i18n associé :

    array (size=6)
  ’auteurs’ => 
    object(Bouton)[301]
      public ’icone’ => string ’’ (length=0)
      public ’libelle’ => string ’icone_auteurs’ (length=13)
      public ’url’ => null
      public ’urlArg’ => null
      public ’url2’ => null
      public ’target’ => null
      public ’sousmenu’ => null
  ’rubriques’ => ...


    (Note : dans la boucle DATA, l’objet « Bouton » est traité comme un tableau associatif).
    Pour faire le tri alphabétique, il y a juste 2 points à traiter :

    • Rajouter la chaîne de langue dans les valeurs. Les premières lettres suffiront pour le tri.
    • Faire en sorte que cette paire clé/valeur soit au début du tableau. Anéfé, dans une boucle DATA, quand les #VALEUR sont des tableaux associatifs, {par valeur/toto} ne fonctionne pas. En revanche, on peut faire {par valeur} tout court et ça va prendre en compte la valeur associée à la première clé du tableau.

    Donc concrètement, en ajoutant 'tri' => 'chaine de langue' au début du tableau de chaque entrée, on peut faire {par valeur} dans la boucle et le tour est joué.
    Je propose 2 patchs, au choix :

    Patch A

    Dans le squelette barre_nav.html : juste avant la boucle DATA qui affiche les entrées, on fait une boucle qui modifie le tableau qui l’alimente (dans le patch, on fait gaffe au espaces blancs, mais là c’est pour la lisibilité).

    [(#REM) prépare les données des entrées ]
#SETsousmenu,#ARRAY

    #SETentree,#ARRAY#CLE,#ARRAY
    
    tri,#VAL#VALEURlibelle|_T|replace’\s+’,’’|substr0,3|strtolower,
    
    icone,#VALEURicone,
    
    libelle,#VALEURlibelle,
    
    url,#VALEURlibelle,url,
    
    urlArg,#VALEURurlArg,
    
    url2,#VALEURurl2,
    
    target,#VALEURtarget,
    
    sousmenu,#VALEURsousmenu
    

    
#SETsousmenu,#GETsousmenu|array_merge#GETentree
    

    [(#REM) Affiche les entrées ]
    

      ...

    Patch B

    Dans boutons.php, on ajoute $this->tri      = strtolower(substr(preg_replace('/\s+/','',_T($libelle)),0,3)); à la classe Bouton et on fait en sorte que ce soit la première donnée renvoyée.
    Du coup dans le squelette barre_nav.html il suffit de rajouter {par valeur}.

Navigation