Recherche avancée

Médias (91)

Autres articles (102)

  • 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 (9220)

  • Anomalie #4537 (Nouveau) : {tri} oubli d’implémenter "sinum" qui existe pour {par}

    10 août 2020, par RastaPopoulos ♥

    Normalement, on doit pouvoir trier pareil, à part que tri est mieux car dynamique. Mais tri sinum XXX plante avec Unknown column ’sinumXXX’ in ’order clause’

    Car la fonction tri_champ_order() implémente "multi", "num", mais pas "sinum". Vu qu’on s’attend logiquement à pouvoir utiliser pile la même chose dans les deux critères, d’après moi c’est bien un bug que ça ne marche pas comme attendu (et pas un truc manquant à faire évoluer).
    https://git.spip.net/SPIP/spip/src/branch/master/ecrire/public/fonctions.php#L262

    C’est d’ailleurs un peu dommage de pas pouvoir mutualiser du code et de devoir implémenter à chaque fois deux fois les différents cas, une fois pour par puis une fois pour tri. :(
    Mais bon comme c’est vraiment pas fait pareil apparemment…

  • Evolution #4548 (Nouveau) : Améliorer _request et set_request pour prendre en compte les champs qu...

    9 septembre 2020, par RastaPopoulos ♥

    Dans la norme HTML, tout champ posté dans un formulaire peut être un tableau, même très profond.
    Dans ce cas la norme est que le nom du champ dans le code soit name="tableau[index][index]".

    Dans Saisies c’est plus ou moins bien pris en compte avec une surcharge saisies_request et saisies_set_request, qui gère aussi le cas où on doit chercher ou enregistrer la valeur dans un sous-index du champ racine. Mais cela n’a strictement aucune spécificité à Saisies. N’importe quel formulaire HTML, fait de n’importe quelle façon, peut avoir des champs qu’on veut enregistrer dans des sous-index.

    Je pense donc que _request() et set_request() devraient directement le prendre en compte dans le core.

    Il faut au moins gérer la notation officielle des champs de ce type gérés par HTML. Si on fait _request('tableau[index]') alors ça ne doit PAS chercher cette chaine telle quelle dans le tableau, ce qui n’a jamais aucun sens, mais bien chercher "tableau", puis si c’est bien un tableau, chercher "index" à l’intérieur, et renvoyer cette valeur là.

    De même pour set_request() dans l’autre sens.

    Pour compléter, ces deux fonctions devraient aussi prendre en compte la notation qu’on utilise aussi partout ailleurs : tableau/index/index.

    Cela ferait une mutualisation à priori simple, et éviterait à chaque formulaire de gérer ces cas, en étant raccord à la fois avec la notation HTML et l’autre que l’on utilise partout.

  • Anomalie #4562 (Nouveau) : Suite #4468 : Unification des CSS pour les boutons et les icônes

    1er octobre 2020

    Je propose de parler ici des détails et corrections éventuelles à apporter suite à l’intégration de #4468.
    Déjà, c’est hyper bien globalement (ne me faites pas dire le contraire :))

    Voilà ce que j’ai observé pour ma part, qui me chagrine.

Navigation