Recherche avancée

Médias (0)

Mot : - Tags -/serveur

Aucun média correspondant à vos critères n’est disponible sur le site.

Autres articles (3)

  • Déploiements possibles

    31 janvier 2010, par

    Deux types de déploiements sont envisageable dépendant de deux aspects : La méthode d’installation envisagée (en standalone ou en ferme) ; Le nombre d’encodages journaliers et la fréquentation envisagés ;
    L’encodage de vidéos est un processus lourd consommant énormément de ressources système (CPU et RAM), il est nécessaire de prendre tout cela en considération. Ce système n’est donc possible que sur un ou plusieurs serveurs dédiés.
    Version mono serveur
    La version mono serveur consiste à n’utiliser qu’une (...)

  • Menus personnalisés

    14 novembre 2010, par

    MediaSPIP utilise le plugin Menus pour gérer plusieurs menus configurables pour la navigation.
    Cela permet de laisser aux administrateurs de canaux la possibilité de configurer finement ces menus.
    Menus créés à l’initialisation du site
    Par défaut trois menus sont créés automatiquement à l’initialisation du site : Le menu principal ; Identifiant : barrenav ; Ce menu s’insère en général en haut de la page après le bloc d’entête, son identifiant le rend compatible avec les squelettes basés sur Zpip ; (...)

  • Mise à disposition des fichiers

    14 avril 2011, par

    Par défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
    Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
    Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...)

Sur d’autres sites (1541)

  • Evolution #3926 : Remplacement de safehtml par le plug htmlpurifier ou autre

    14 janvier 2019, par Guillaume Fahrner

    Sorry je n’avais pas vu ce message :

    cedric - a écrit :

    Depuis https://core.spip.net/projects/spip/repository/revisions/24131 le plugin HTMLPurifier est fonctionel sans nécessiter de patch dans le core ?

    Malheureusement si : il reste une surcharge de la fonction propre() via inc/texte.php. Elle est utilisée pour réaliser la protection HTML via echappe_html() AVANT le 1er filtrage de sécurité via echapper_html_suspect(). Un deuxième est réalisé via echappe_retour_modeles($t, $interdire_script) ou $interdire_script est vrai en espacé privé ou si le mode parano actif et faux sinon. (Je n’ai pas su faire autrement, mais il y a peut être une astuce a trouver.)

    Je ne sais pas si tu considères que c’est le core mais une surchage des règles YAML de textwheel est également réalisé afin que l’on envoi bien tout qui doit l’être dans les filtres de sécurité.

    Donc non pas de modification du core nécessaire pour que le plugin fonctionne. A voir si ces surcharges mériterais une "intégration directe" future.

    on est bon et on peut release tel quel en indiquant que le plugin htmlpurifier est disponible pour tests et se laisser le temps ?

    A mon avis oui. Pour rappel : le mode parano est actuellement inutilisable avec l’actuel safehtml(). Du coup ça peut être une approche pour l’intégrer/le tester au fil de l’eau : commencé par les gens qui utilisent le mode parano en leur recommandant chaudement/forcant ce plugin.

    Ci dessous la liste des plugins que j’utilise sans problème hors textwheel/todo (cf https://core.spip.net/issues/4254) avec htmlPurifier :

    Abonnements 3.3.6 - stable
    Agenda 3.26.0 - stable
    API de vérification 1.8.1 - stable
    API Prix 0.1.16 - dev
    Article PDF 1.0.10 - stable
    Autorité 0.10.20 - stable
    Banque&paiement 3.6.7 - stable
    Cache Cool 0.5.4 - stable
    Challenge Hacking 1.0.0 - stable
    Champs Extras 3.11.7 - stable
    Chatbox 1.0.5 - stable
    Coloration Code 99 - stable
    Commandes 1.15.5 - stable
    Compositions 3.7.3 - stable
    Crayons 1.26.18 - stable
    CTF all the day 1.0.0 - stable
    Facteur 3.6.2 - stable
    Formulaire de contact avancé 0.16.5 - stable
    Frimousses 1.5.1 - stable
    GIS 4.44.24 - stable
    HTML Purifier 5.0.0.1 - test
    iCalendar 0.4.5 - test
    Import ics 4.4.3 - stable
    Imprimer document 0.2.2 - stable
    LangOnet 1.4.6 - stable
    MailShot 1.27.3 - stable
    MailSubscribers 2.11.3 - stable
    Markdown 1.0.2 - test
    Messagerie 3.1.8 - test
    Mini Calendrier 2.4.1 - stable
    Mot de passe dès l’inscription 1.0.19 - stable
    Newsletters 1.6.0 - stable
    Nombres de visiteurs connectés 0.2.3 - stable
    NoSPAM 1.5.18 - stable
    Notation 2.4.2 - test
    Notifications 3.6.8 - stable
    Notifications avancées 0.4.2 - test
    Pages 1.3.7 - stable
    Pre & Code 99 - test
    Saisies pour formulaires 3.11.1 - stable
    Social tags 1.1.1 - stable
    SPIP Bonux 3.4.6 - stable
    Tip A Friend 1.6.9 - stable
    Todo 2.2.1 - stable
    Traduction entre rubriques 3.1.3 - stable
    YAML 1.5.4 - stable

    Je pense que si on doit intégrer le plugin ça sera sur la version dev 3.3, pas sur la version stable, et ça va demander de prendre le temps de voir toutes les modifs et les impacts éventuels que tu n’aurais pas vu ou auxquelles tu n’aurais pas pensé.

    Clairement je pense me faire insulter :-) Je suis prêt ^^ Plus sérieusement il faut absolument tester/restester/reretester. J’ai tenté de faire au mieux mais je ne peux pas revoir tout le code HTML généré par les plugins... Au moindre écart de conformité HTML ca ne passera pas. Le bug https://core.spip.net/issues/4254 en est un bon exemple : avec htmlpurifier l’élément

    est supprimé ; avec "safehtml() standard" le code invalide est conservé et c’est le navigateur qui va corriger.

    Il faut voir les bons cotés : cela force les bonnes pratiques, met SPIP au plus haut niveau du standard (Drupal fait moins bien), aide a identifier des bugs et ce qui passe dans propre() sera obligatoirement valide. C’est aussi a terme moins de problèmes d’injection XSS a traiter pour la team.

    Sur la fonction de survol des logos le sujet reste ouvert ? On est en effet d’accord que cette écriture est obsolète et devrait être revue de toute façon, mais c’est donc un point à traiter dans le core le cas échéant

    Euh je comprend pas, faut-il intégrer le patch des puces de statut dans ce plugin ? Je pensais plus coder le truc """proprement""" avec un JS dans le directement dans /prive/. A décolérer complètement à mon sens.

    Encore merci pour le temps que tu y passes :)

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

    17 février 2021

    Bon bon bon, on a pas mal réfléchi au sujet avec rastapopoulos, et je crois qu’on est arrivé à une solution satisfaisante.
    En tout cas une solution qui répond complètement aux problèmes et besoins soulevés dans ce ticket, en ce qui me concerne.

    Le problème était de ne traiter des icônes que sous l’angle d’une utilisation dans des boutons, de ne le faire qu’à moitié en proposant un jeu d’icônes très restreint, et avec des icônes pas toutes prévues pour cette utilisation qui plus est.

    Dans l’immédiat, pour clôturer ce ticket au plus vite, il s’agirait de faire ça :

    • dans le CSS, retirer complètement les variantes de boutons avec icônes : .bouton_add, .bouton_supprimer, etc. (ça sera fait différemment et mieux).
    • renommer la classe .bouton en .btn : c’est moins verbeux et on comprend aussi bien.
    • préfixer les variantes génériques qui restent : .btn_mini au lieu de .btn mini, etc.
    • finir les derniers petits ajustement visuels.

    Avec ça le ticket pourra enfin être fermé.

    Mais alors comment fait-on pour avoir des icônes dans les boutons ?
    C’est l’étape suivante.

    Des icônes

    On s’est dit, tant qu’à faire, autant proposer tout de suite un jeu complet d’icônes symboliques.

    Les besoins sont multiples pour pleins d’éléments d’interface, dans les plugins et dans le core : plier/déplier des trucs, dupliquer un contenu, afficher un menu, remonter dans la hiérarchie, etc., etc. (je fais vite).
    Et chacun doit réimplémenter ça un peu à sa sauce.

    On reprendrait un jeu d’icônes existant, qu’on n’aura pas à maintenir, optimisé, et qui fournit des icônes cohérentes visuellement, utilisables dans tous les contextes.
    Il y a plusieurs choix de jeux d’icônes libres : Bootstrap-icons, Octicon, Material, Entypo, etc.

    Ces icônes seraient utilisables de 2 façons :

    1. Des classes

    Quand il s’agit d’icônes purement décoratives, des classes que l’on peut ajouter à n’importe quel élément inline.
    Pour éviter les conflits, on propose la contraption de spip + icon = spicon.
    Cette solution utilise une fontface, l’icône hérite de la taille et de la couleur du texte.

    Pour les boutons, même principe : la classe signifie « ajoute une icône dans cet élément »

    Exemples :

    <span class="CodeRay"><span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spicon_menu</span><span class="delimiter">"</span></span><span class="tag">></span>Ouvrir le menu<span class="tag"></span>
    
<span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spicon_truc</span><span class="delimiter">"</span></span><span class="tag">></span><span class="tag"></span> Du texte
    
<span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">titrem spicon_machin</span><span class="delimiter">"</span></span><span class="tag">></span>Mon titre<span class="tag"></span>
    
</span></span></span></span>

    2. Une balise #ICON

    En complément, on peut vouloir embarquer une icône svg dans le HTML.

    On propose de reprendre et d’adapter la super balise #ICON du plugin Zcore, qui fait ça très bien.
    Cette balise permet d’embarquer une icône du set par défaut, mais également n’importe quelle autre (je rentre pas dans les détails).

    Un modèle correspondant permettra aussi d’inclure des icônes svg dans les textes : 

    <span class="CodeRay">#ICONE{identifiant}
    
#ICONE{chemin/vers/mon_icone.svg}
    
#ICONE{#identifiant_autre_set}
    
</span>

    Identifiants sémantiques

    Les identifiants des icônes seront directement ceux du jeu d’icônes choisi.
    Mais ils peuvent avoir des noms un peu barbares : chevron-double-right, eye-slash, grip-vertical, etc.

    Dans tous les cas on pourra les utiliser tels quels, mais en plus de ça, on propose de faire une correspondance sémantique pour les icônes correspondants aux actions les plus courantes. Par exemple au lieu de faire #ICONE{chevron-double-down} on pourra faire #ICONE{deplier}.

    La liste initiale est visible ici : https://demo.hedgedoc.org/3zIXkcFLTVSwV0nKC1_qcA?both

    Voilà, je crois que c’est tout, rastapopoulos tu complètera si j’ai oublié des trucs.
    Peut-être qu’on peut partir sur un nouveau ticket pour ce sujet et la branche dev qui ira avec.

    À vous les studios.

  • Revision 30332 : On passe la génération de la file d’attente et donc des inserts en base ...

    29 juillet 2009, par kent1@… — Log

    On passe la génération de la file d’attente et donc des inserts en base dans l’action spipmotion_ajouter_file
    On ajoute un suffixe au nom de fichier -encoded pour éviter de boucler sur les encodages
    On clean aussi un chouilla

Navigation