Recherche avancée

Médias (91)

Autres articles (51)

  • Personnaliser les catégories

    21 juin 2013, par

    Formulaire de création d’une catégorie
    Pour ceux qui connaissent bien SPIP, une catégorie peut être assimilée à une rubrique.
    Dans le cas d’un document de type catégorie, les champs proposés par défaut sont : Texte
    On peut modifier ce formulaire dans la partie :
    Administration > Configuration des masques de formulaire.
    Dans le cas d’un document de type média, les champs non affichés par défaut sont : Descriptif rapide
    Par ailleurs, c’est dans cette partie configuration qu’on peut indiquer le (...)

  • Emballe médias : à quoi cela sert ?

    4 février 2011, par

    Ce plugin vise à gérer des sites de mise en ligne de documents de tous types.
    Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ;

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

Sur d’autres sites (7291)

  • allow configuration of imageSmoothingQuality. default is "low", othe…

    9 avril 2021, par redemption
    allow configuration of imageSmoothingQuality.  default is "low", other options are "medium" and "high".

    Usage :
    

    $(’#fileupload’).fileupload(
    
disableImageResize : /Android(?!.*Chrome)|Opera/
    
						.test(window.navigator && navigator.userAgent),
    
				imageSmoothingQuality : ’medium’,

  • Evolution #4727 : Des pictos / icônes symboliques pour tout le monde

    13 avril 2021, par RastaPopoulos ♥

    - et même amha assez simplement la balise #ICON pourrait détecter si l’image demandée est dans un sprite connu, auquel cas elle utilise le sprite, sinon elle utilise le fichier individuel

    Ça c’est bien prévu dans le cahier des charges :)

    Pour les classes, si ya une autre méthode que la fonte tant mieux hein, mais ce qui compte c’est continuer d’avoir l’option des classes, surtout pour l’interface d’admin. Car il y a plein de cas où c’est utile quand on veut avoir une interface cohérente maintenable, surtout si elle est modulaire (plugins infinis qui doivent avoir aussi le même style, sans devoir tout changer partout dès qu’on veut changer le style d’un morceau, dont les pictos).

    Et pour une interface d’admin, il y a encore moins de freinage y compris pour une fonte, on parle pas du site public qui utilise 3 pictos (là c’est au choix de la personne intégratrice de faire les bonnes décisions). Pour l’admin on charge de toute façon des choses permanentes, dont les sprites, et on va de toute façon utiliser un certain nombre de pictos un peu partout + en rendre dispo pour les plugins + le fait que les fontes sont à peu près toujours plus légères que les sprites. Avec tout ça je ne vois pas de problème énorme à charger une fonte de 80 pauvres kilos pour ce qui est de l’admin… (on parle pas de 500ko là…)
    Batailler pour ne pas intégrer 80ko voire même 40ko si on prend un jeu moins gros que bootstrap, c’est un peu dérisoire… :)
    (et du coup justement ya PAS à maintenir un sous-ensemble, car déjà l’ensemble complet pèse bien moins lourd que les sprites SVG, ça fait de la maintenance en moins)

  • Evolution #2173 : Date de création / publication

    3 juillet 2017, par tcharlss (*´_ゝ｀)

    Je reporte ici le ticket #3966 qui fait doublon : l’idée pourrait être étendue à tout type de contenu.

    Il n’y a pas longtemps j’ai eu besoin de faire des statistiques éditoriales : on voulait connaître l’évolution du nombre d’articles publiés chaque année.
    Mais les données ne sont pas fiables : les utilisateurs avaient pour habitude de faire des « remises en avant » en changeant la date de publication de vieux articles pour les refaire apparaître en page d’accueil. Donc un article écrit en 2014 mais remis en avant en 2017 se retrouve compté comme ayant été publié en 2017.

    Et c’est valable pour tout les objets éditoriaux en fait : on ne conserve pas leur date de création / 1ère publication.
    Certains objets ont une date de publication, mais elle peut être changée. Et d’autres objets n’ont tout simplement pas de date (hormis maj).

    Donc je me demandais s’il ne serait pas pertinent d’avoir cette information de façon générique pour tous les objets éditoriaux, un champ date_creation par exemple qui serait rempli soit à la création, soit à la 1ère publication, et qui ne bougerait pas ensuite.

    Ci-dessous, un tableau récapitulatif de ce qu’on a actuellement pour les principaux objets.

    Objet Champ de date Date pérènne ?
    Articles date Non : peut être modifiée manuellement
    Brèves date_heure Non : peut être modifiée manuellement
    Rubriques date Oui
    Auteurs X X
    Mot-clé X X
    Groupe de mots-clés X X
    Document date Oui
    Forum date_heure oui
    Pétition X X

Navigation