Recherche avancée

Médias (0)

Mot : - Tags -/page unique

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

Autres articles (37)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • Support de tous types de médias

    10 avril 2011

    Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)

  • L’utiliser, en parler, le critiquer

    10 avril 2011

    La première attitude à adopter est d’en parler, soit directement avec les personnes impliquées dans son développement, soit autour de vous pour convaincre de nouvelles personnes à l’utiliser.
    Plus la communauté sera nombreuse et plus les évolutions seront rapides ...
    Une liste de discussion est disponible pour tout échange entre utilisateurs.

Sur d’autres sites (6727)

  • Revision 109633 : Ma console réseau de mon navigteur indique : - jquery-ui.js : 508,86ko ...

    22 mars 2018, par placido@… — Log

    Ma console réseau de mon navigteur indique :
    - jquery-ui.js : 508,86ko
    - jsdyn-formulaires_dateur_jquery_dateur_js_14fce12d.js : 517,89 ko
    Le fichier js dynamique est chargé via $.getScript depuis le fichier formulaire/dateur/inc-dateur.html qui inclut déjà lui-même jquery-ui !
    On se retouve donc avec une double dose d’un jquery-ui (déjà pachidermique) à la moindre saisie date appelée. C’est clairement un problème.
    Je m’interroge sur la nécessite de l’insertion des css et js via affichage_final. Sauf cas particulier qui m’échappe, je pense que cette fonction saisies_affichage_final n’a pas (plus) lieu d’être.
    Je propose d’opter pour un chargement des éléments globaux via insert_head et insert_head_css (sans jquery-ui) et pour les cas particuliers, cela doit se gérer au niveau du squelette de la saisie (à l’instar de ce que fait déjà la saisie date qui fait un #INCLURE de inc-dateur.html).
    En attendant des avis, on peut déjà rendre cette fonction surchargeable (désactivable).

  • Evolution #3821 : [sécurité - cookie] possibilité de gérer l’attribut "secure" du cookie spip sess...

    19 novembre 2018, par Absurde Photon

    Bien lire "javascript" au lieu de "java" dans mon message ci-dessus.

    Je n’avais pas assez cherché, je viens de me rendre compte que l’attribut httponly est bien mis sur le cookie de session, donc tout va bien de ce côté.

    Reste l’attribut "secure" dans ce cas, qui est une recommandation OWASP depuis un bon moment : https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)

    Pour ce qui est de l’attribut domain, c’est déjà implémenté dans Spip. Il n’en manque donc plus qu’un pour être complet, "secure" !

  • Anomalie #4222 (Nouveau) : r21880 n’a pas été reporté sur trunk/3.1/3.2

    12 novembre 2018

    Bonjour,

    Je suis tombé sur un bug suite à la mise à jour d’un site de 3.0 en 3.2 et j’ai fini par trouver que id_table_objet ne me trouvait plus les éléments pourtant bien déclarés via base/

    Tout ça parce que les tables en question étaient préfixées par tbl_ au lieu de spip_ (donc, un base SPIP avec les 2 préfixes).

    Voici le patch (testé en 3.2.1 SVN) qui remédie au problème en 3.2

    AMHA, il faudrait reporter en 3.1, 3.2 et trunk.

Navigation