
Recherche avancée
Autres articles (48)
-
Automated installation script of MediaSPIP
25 avril 2011, parTo overcome the difficulties mainly due to the installation of server side software dependencies, an "all-in-one" installation script written in bash was created to facilitate this step on a server with a compatible Linux distribution.
You must have access to your server via SSH and a root account to use it, which will install the dependencies. Contact your provider if you do not have that.
The documentation of the use of this installation script is available here.
The code of this (...) -
La sauvegarde automatique de canaux SPIP
1er avril 2010, parDans le cadre de la mise en place d’une plateforme ouverte, il est important pour les hébergeurs de pouvoir disposer de sauvegardes assez régulières pour parer à tout problème éventuel.
Pour réaliser cette tâche on se base sur deux plugins SPIP : Saveauto qui permet une sauvegarde régulière de la base de donnée sous la forme d’un dump mysql (utilisable dans phpmyadmin) mes_fichiers_2 qui permet de réaliser une archive au format zip des données importantes du site (les documents, les éléments (...) -
Personnaliser en ajoutant son logo, sa bannière ou son image de fond
5 septembre 2013, parCertains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;
Sur d’autres sites (5459)
-
Anomalie #4592 (Nouveau) : Problème avec la désinstalation de plugs
31 octobre 2020, par Franck DHello
Windows 10 (1909)Laragon avec :
Php 8.0.0RC3 (VS16 x64 Non Thread Safe) https://windows.php.net/qa
Apache 2.4.46 Win64 avec mod_fcgid-2.3.10-win64-VS16 https://www.apachelounge.com/download/
Mysql 8.0.22 (mysql-8.0.22-winx64.zip) https://dev.mysql.com/downloads/mysql/
phpMyAdmin 5.0.4 https://www.phpmyadmin.netInstallation en MySQL
Prefix des tables à l’installation : "test7"
SPIP 3.3.0-dev GIT [master : 2d07177b]Je viens de faire un test avec un spip 3.3 tout neuf, j’ai juste fait l’activation de gd2, des miniatures et du dépôt de la zone
Pour faire le test, il faut mettre dans le dossier "plugins" le squelette "galactic" https://git.spip.net/spip-galaxie/galactic et celui de contrib https://git.spip.net/spip-galaxie/contrib.spip.net
Ce qui nous donne donc 3 dossiers dans le dossier "plugins" (auto, contrib.spip.net, galactic)Puis j’active les plugs via svp ce qui télécharge les dépendances. Plus tard quand je coche toutes les cases pour les supprimer d’un coup, il me reste contrib... (voir copie d’ecran)
-
Anomalie #3386 (Nouveau) : Spip derrière Varnish : port non-standard dans l’URL ?
13 février 2015, par Mathieu MDSpip ajoute intempestivement le port aux URL qu’il génère quand celui-ci est non-standard (ie. ni 80 ni 443). Ça pose un problème quand le serveur applicatif (Apache+PHP, Nginx+PHP, etc.) se trouve derrière un reverse proxy (Varnish) sur la même machine, et écoute donc non pas sur 80 mais sur 81 ou 8080, par exemple.
Ça casse notamment l’URL de `spip_admin.css` et du SPIP-CRON en toute fin de page.
Pour « corriger » sur mon installation, j’ai modifié la fonction `url_de_base()` du fichier `ecrire/inc/utils.php` en commentant ce bloc :
if (isset($_SERVER[’SERVER_PORT’]) AND $port=$_SERVER[’SERVER_PORT’] AND strpos($host," :")==false) if ($http=="http" AND $port !=80) $host.=" :$port" ; if ($http=="https" AND $port !=443) $host.=" :$port" ;
Évidemment c’est un peu barbare... Pourquoi ne pas utiliser l’URL de base spécifiée dans l’interface d’admin (Configuration > Identité du site : Adresse (URL) du site public) ? Le commentaire de la fonction `url_de_base()` précise que c’est parce que `meta(adresse_site)` peut être fausse ; mais alors à quoi bon la demander et à quoi sert-elle ?
Bref, il devrait être possible de servir Spip sur un port non-standard sans pour autant casser les URLs.
Pour info :
- L’architecture initiale (traditionnelle) : Client -> Nginx (port 80) -> PHP (Spip)
- Nouvelle archi avec reverse proxy : Client -> Varnish (port 80) -> Nginx (port 81) -> PHP (Spip)
Versions :
- SPIP 3.0.17 [21515]
- Nginx 1.2.1
- Varnish 3.0.2
- Debian 7.8 Wheezy
-
Evolution #4358 (Nouveau) : Supprimer l’explication d’inscription qui préjuge de l’utilisation
5 juillet 2019, par RastaPopoulos ♥À l’intérieur même du formulaire d’inscription (et non pas dans les squelettes qui l’appellent), il y a un message d’explication qui préjuge de ce pour quoi on demande aux gens de s’inscrire. Ce message change suivant le type de compte à créer (rédac ou visiteur).
Depuis peu, ce morceau est dans un squelette séparé (inc-) qui permet de le surcharger pour le vider (avant il fallait essayer de le cacher en CSS, et il n’y avait même pas de sélecteur précis).
Je postule (avec raison bien sûr), que de nos jours, le nombre de sites qui sortent où ces messages ont un sens, et notamment celui pour les visiteurs publics ("Vous avez demandé à intervenir sur un forum réservé aux visiteurs enregistrés.") , sont moins nombreux que ceux où cela n’a strictement aucun sens.
Je pense donc que dans les prochaines versions (dès 3.3), cela doit disparaitre complètement par défaut. Les chaines peuvent rester, et on peut dire aux quelques rares personnes au monde pour qui ces messages ont un sens, comment l’afficher avant leur formulaire. On peut même l’ajouter dans squelettes-dist pour montrer comment on fait.
Mais par défaut, le formulaire d’inscription fourni, doit être générique, avec juste le nécessaire. Les explications autour sont du ressort du site qui utilise (squelettes-dist par défaut et chacun dans son coin suivant son besoin).