Recherche avancée

Médias (91)

Autres articles (46)

  • 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" (...)

  • List of compatible distributions

    26 avril 2011, par

    The table below is the list of Linux distributions compatible with the automated installation script of MediaSPIP. Distribution nameVersion nameVersion number Debian Squeeze 6.x.x Debian Weezy 7.x.x Debian Jessie 8.x.x Ubuntu The Precise Pangolin 12.04 LTS Ubuntu The Trusty Tahr 14.04
    If you want to help us improve this list, you can provide us access to a machine whose distribution is not mentioned above or send the necessary fixes to add (...)

  • Taille des images et des logos définissables

    9 février 2011, par

    Dans beaucoup d’endroits du site, logos et images sont redimensionnées pour correspondre aux emplacements définis par les thèmes. L’ensemble des ces tailles pouvant changer d’un thème à un autre peuvent être définies directement dans le thème et éviter ainsi à l’utilisateur de devoir les configurer manuellement après avoir changé l’apparence de son site.
    Ces tailles d’images sont également disponibles dans la configuration spécifique de MediaSPIP Core. La taille maximale du logo du site en pixels, on permet (...)

Sur d’autres sites (3183)

  • Evolution #4391 : Squelettes de la dist : améliorer le markup et passer à BEM

    15 octobre 2019, par RastaPopoulos ♥

    tcharlss a parlé de deux rangements, ya le rangement par bloc à la mode Z, donc ça ok c’est possiblement too much, mais ça ne concerne pas tout ce qu’il y a dans inclure/.

    Ensuite il y a le découpage par fonctionnalité justement, et là c’est ce qu’il y a dans inclure/, avec d’un côté les listes/ (liste d’article, liste d’auteur, etc), les résumés (les morceaux individuels de chaque liste), et ça ça peut être mutualisé et rangé comme il faut dans inclure/ avec des sous-dossiers inclure/liste, etc. Là aussi en terme de bonne pratique, ça apprend aux débutants à réfléchir en terme modulaire, ce qui est bien mieux que de réfléchir en terme de "page" (design system, atomic design, etc) : on essaye de mutualiser ce qu’on détecte qui est commun à plusieurs pages, comme liste d’articles par ex.

    Sinon, vraiment, jamais pigé le principe de mettre un préfixe "inc" devant des noms de squelette qui sont déjà bien rangés séparément dans un sous-dossier qui les distingue. :D

  • Evolution #2812 : Avertir de l’absence de SQLite sur la page de backup

    12 mai 2013, par cedric -

    @Thierry : Les warning sur l’unicité des clés primaires sont "normaux" dans le sens où ils permettent de se protéger vis à vis de l’approximation inhérente à la reprise sur interruption. Les backups au format XML des versions précédentes avaient les mêmes défauts mais sans protection de ce côté là, conduisant à des données erronées au final.
    L’absence de table meta a la connexion est aussi normale lors du backup.
    Le fait que ce soit lent est lui inhérent au mode de sauvegarde où l’on lit les tables morceau par morceau pour les écrires dans un fichier (que ce soit SQLite ou XML ne change rien sur ce point).

    Et bien sur, mysqldump est bien plus rapide, de plusieurs ordres de grandeur. Mais le format SQL qu’il produit n’est pas portable, pose parfois des problèmes au ré-import sur un autre serveur avec une version mySQL différente, et n’est pas importable dans un SQLite par exemple.

    Bref pas de solution idéale, encore une fois celle proposée dans le core essaye d’être le plus générique possible.

  • Evolution #4146 (Nouveau) : Invalideur lors de la publication : facultatif

    2 juin 2018, par Maïeul Rouquette

    Partons d’un cas concret. Le réponses à un formulaire formidable peuvent avoir un statut "publié". Mais ce statut n’est pas vraiment un statut de publication côté publique. Il s’agit plus d’un statut sur la validité de la réponse.

    Or, SPIP invalide le cache dès qu’un objet est publié.
    Cf
    https://core.spip.net/projects/spip/repository/entry/spip/ecrire/action/editer_objet.php#L118

    Ne pourrait-t-on mettre une pipeline à cet endroit pour pouvoir désactiver au cas par cas cette invalidation ?
    Ou bien dans https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/modifier.php#L155 ?