
Recherche avancée
Autres articles (72)
-
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 (...) -
Gestion des droits de création et d’édition des objets
8 février 2011, parPar défaut, beaucoup de fonctionnalités sont limitées aux administrateurs mais restent configurables indépendamment pour modifier leur statut minimal d’utilisation notamment : la rédaction de contenus sur le site modifiables dans la gestion des templates de formulaires ; l’ajout de notes aux articles ; l’ajout de légendes et d’annotations sur les images ;
-
Supporting all media types
13 avril 2011, parUnlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)
Sur d’autres sites (12038)
-
Anomalie #3386 : Spip derrière Varnish : port non-standard dans l’URL ?
15 février 2015, par Mathieu MDBien vu. La doc de `mod_rpaf` précise en effet qu’il réécrit « REMOTE_ADDR, HTTPS, and HTTP_PORT to the values provided by an upstream proxy ».
Ça n’a pas l’air d’être le cas du module Realip de Nginx (que j’utilise), ni de mod_remoteip, qui remplace mod_rpaf depuis Apache 2.4.
http://wiki.nginx.org/HttpRealipModule
https://httpd.apache.org/docs/2.4/mod/mod_remoteip.htmlOn pourrait forcer, dans la conf Varnish, un entête `X-Forwarded-Port` qui serait parsé directement par Spip. Quelque chose comme ça :
- Varnish :
Soit :
sub vcl_recv set req.http.X-Forwarded-Port = server.port ;
Soit :
sub vcl_recv if (req.http.X-Forwarded-Proto == "https" ) set req.http.X-Forwarded-Port = "443" ; else set req.http.X-Forwarded-Port = "80" ;
- Spip, dans `ecrire/inc/utils.php` :
if (isset($_SERVER[’SERVER_PORT’]) AND $port=$_SERVER[’SERVER_PORT’] AND strpos($host," :")==false) # X-Forwarded-Port doit être ajouté par le proxy inverse (Varnish, etc.) if (isset($_SERVER[’HTTP_X_FORWARDED_PORT’]) AND $xport=$_SERVER[’HTTP_X_FORWARDED_PORT’]) if ($http=="http" AND $xport !=80) $host.=" :$xport" ; if ($http=="https" AND $xport !=443) $host.=" :$xport" ; else if ($http=="http" AND $port !=80) $host.=" :$port" ; if ($http=="https" AND $port !=443) $host.=" :$port" ;
-
Revision 67227 : Toujours dans l’optique d’une inclusion un peu générique, permettre de ...
28 octobre 2012, par rastapopoulos@… — LogToujours dans l’optique d’une inclusion un peu générique, permettre de ne pas lister des docs déjà listés par ailleurs, avec le critère habituel de SPIP doublons (il suffit alors de passer des doublons à l’inclusion)
-
Revision 67227 : Toujours dans l’optique d’une inclusion un peu générique, permettre de ...
28 octobre 2012, par rastapopoulos@… — LogToujours dans l’optique d’une inclusion un peu générique, permettre de ne pas lister des docs déjà listés par ailleurs, avec le critère habituel de SPIP doublons (il suffit alors de passer des doublons à l’inclusion)