
Recherche avancée
Autres articles (61)
-
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
Configuration spécifique d’Apache
4 février 2011, parModules spécifiques
Pour la configuration d’Apache, il est conseillé d’activer certains modules non spécifiques à MediaSPIP, mais permettant d’améliorer les performances : mod_deflate et mod_headers pour compresser automatiquement via Apache les pages. Cf ce tutoriel ; mode_expires pour gérer correctement l’expiration des hits. Cf ce tutoriel ;
Il est également conseillé d’ajouter la prise en charge par apache du mime-type pour les fichiers WebM comme indiqué dans ce tutoriel.
Création d’un (...) -
Creating farms of unique websites
13 avril 2011, parMediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)
Sur d’autres sites (6059)
-
Anomalie #3273 : Bug fonctions avancées sous spip 3.0.17
26 septembre 2014, par Ben .Je ne reproduis pas non plus.
Il faut surement regarder du coté de l’errorlog apachepourquoi affect*er* à Cédric au fait ?
-
ffmpeg install on my machine but not display in phpinfo()
17 février 2017, par Pratik Bachchheffmpeg extension not loaded in
phpinfo()
when I follow the steps below :- Download ffmpeg from here : https://ffmpeg.org/download.html
- Copy
php_ffmpeg.dll
from thephp5
folder to theC:\wamp\bin\php\php5.2.9-2\ext
- Copy files from
common
to thewindows/system32
folder - Add
extension=php_ffmpeg.dll
tophp.ini
file (\apache...php.ini
) - Restart all services (Apache, PHP...)
- Enable
extension=php_ffmpeg.dll
directive in yourphp.ini
.
-
Anomalie #3386 : Spip derrière Varnish : port non-standard dans l’URL ?
24 septembre 2018, par Pierre KUHNBonjour,
Je me permet de ré-ouvrir ce ticket car j’ai encore le problème sur des sites en 3.2.1 à jour avec svn.
Quand j’active le cache chez mon hébergeur, cela rajotue des ports 80 dans les chemin d’image et du coup le site perds la css et les images dans le BO de SPIP
Je cite mon hébergeur :
De mémoire, j’ai fait la même chose que pour le dernier site, c’est-à-dire ajouté un bout de code dans le fichier de configuration du site (sauf que pour l’autre site, je l’ai mis dans le index.php à la place).
C’est le code là :
- <span class="CodeRay">> <span class="keyword">if</span> (<span class="predefined">$_SERVER</span>[<span class="string"><span class="delimiter">'</span><span class="content">HTTP_X_FORWARDED_PROTO</span><span class="delimiter">'</span></span>] == <span class="string"><span class="delimiter">'</span><span class="content">https</span><span class="delimiter">'</span></span>) {
- > <span class="predefined">$_SERVER</span>[<span class="string"><span class="delimiter">'</span><span class="content">HTTPS</span><span class="delimiter">'</span></span>]=<span class="string"><span class="delimiter">'</span><span class="content">on</span><span class="delimiter">'</span></span>;
- > <span class="predefined">$_SERVER</span>[<span class="string"><span class="delimiter">'</span><span class="content">SERVER_PORT</span><span class="delimiter">'</span></span>] = <span class="integer">443</span>;
- > }
- > <span class="keyword">if</span> (<span class="predefined">isset</span>(<span class="predefined">$_SERVER</span>[<span class="string"><span class="delimiter">'</span><span class="content">HTTP_X_FORWARDED_HOST</span><span class="delimiter">'</span></span>])) {
- > <span class="predefined">$_SERVER</span>[<span class="string"><span class="delimiter">'</span><span class="content">HTTP_HOST</span><span class="delimiter">'</span></span>] = <span class="predefined">$_SERVER</span>[<span class="string"><span class="delimiter">'</span><span class="content">HTTP_X_FORWARDED_HOST</span><span class="delimiter">'</span></span>];
- > }
- > </span>
La subtilité avec Varnish est que Varnish renvoi sur le port non HTTPS de Apache donc certaines variables renvoyés par Apache ne correspondent pas à la réalité.
C’est à dire : HTTPS, SERVER_PORT, REQUEST_SCHEME
C’est pour cela que des headers supplémentaires HTTP_X_FORWARDED_PROTO, HTTP_X_FORWARDED_HOST comme sont passés.Il faut également faire attention avec le "SERVER_PORT", quelque chose de 443 peut aussi être du HTTPS, dans notre cas, c’est 4430 par exemple car un reverse proxy écoute déjà le 443 normal. (sauf que dans ce cas précis, le reverse proxy renvois sur le port SSL d’apache).
En résumé, il y a deux cas différents :
- reverse proxy écoute sur SSL (443) : renvoi sur le port SSL d’apache (4430, le port choisi est arbitraire). Généralement cela pose pas de problème car cela passe par le circuit HTTPS d’apache.
- reverse proxy écoute sur SSL (443) : renvoi sur le port HTTP d’apache (8080 par exemple), en passant des headers supplémentaires (HTTP_X_FORWARDED_PROTO par exemple). C’est du "offload" de SSL, cela passe par le circuit HTTP d’apache donc certaines variables peuvent être définie différemment. L’application hébergé doit contrôler les headers supplémentaires et essayer de "détecter" cela.Un réglage via mes_options serait jouable ?
Merci