Recherche avancée

Médias (9)

Mot : - Tags -/soundtrack

Autres articles (97)

  • Installation en mode ferme

    4 février 2011, par

    Le mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
    C’est la méthode que nous utilisons sur cette même plateforme.
    L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
    Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...)

  • Websites made ​​with MediaSPIP

    2 mai 2011, par

    This page lists some websites based on MediaSPIP.

  • Possibilité de déploiement en ferme

    12 avril 2011, par

    MediaSPIP peut être installé comme une ferme, avec un seul "noyau" hébergé sur un serveur dédié et utilisé par une multitude de sites différents.
    Cela permet, par exemple : de pouvoir partager les frais de mise en œuvre entre plusieurs projets / individus ; de pouvoir déployer rapidement une multitude de sites uniques ; d’éviter d’avoir à mettre l’ensemble des créations dans un fourre-tout numérique comme c’est le cas pour les grandes plate-formes tout public disséminées sur le (...)

Sur d’autres sites (9900)

  • 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