
Recherche avancée
Médias (1)
-
La conservation du net art au musée. Les stratégies à l’œuvre
26 mai 2011
Mis à jour : Juillet 2013
Langue : français
Type : Texte
Autres articles (72)
-
Des sites réalisés avec MediaSPIP
2 mai 2011, parCette page présente quelques-uns des sites fonctionnant sous MediaSPIP.
Vous pouvez bien entendu ajouter le votre grâce au formulaire en bas de page. -
Participer à sa traduction
10 avril 2011Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
Actuellement MediaSPIP n’est disponible qu’en français et (...) -
MediaSPIP v0.2
21 juin 2013, parMediaSPIP 0.2 est la première version de MediaSPIP stable.
Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)
Sur d’autres sites (11891)
-
Revision 109633 : Ma console réseau de mon navigteur indique : - jquery-ui.js : 508,86ko ...
22 mars 2018, par placido@… — LogMa 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 PhotonBien 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 2018Bonjour,
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.