SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribs sur SPIP-Zone, 265 visiteurs en ce moment

Accueil > Administration et BDD > Mutualisation > Plugin Mutualisation > Ferme à SPIP

Ferme à SPIP

3 janvier 2008 – par Ben., ElJuez, Fil, Matthieu Marcillaud, Pierre KUHN, YannX – 124 commentaires

22 votes

Un petit article synthétique qui explique en quelques mots et captures d’écrans comment faire une « ferme à SPIP » avec le plugin "Mutualisation" à partir d’un nom de domaine principal.

ATTENTION , cet article nécessite d’utiliser une version stable > à 2.0

Les prérequis (au 1er janvier 2008) :

-  posséder un nom de domaine disponible
-  avoir la possibilité de modifier la configuration apache

Dans l’exemple suivant on supposera que l’on cherche à mettre la ferme sur le site GrmlEU [1]

Installation SPIP

Installer un SPIP (une version récente est recommandée). Pour la suite de l’exercice on supposera que le SPIP est installé dans le répertoire « /home/grml/public_html/ ».

Installation plugin mutualisation

Installer le plugin Mutualisation [2] (il est plus simple de ne pas le mettre dans le répertoire plugin) . Nous avons donc « /home/grml/public_html/mutualisation »

Configuration apache

Modifier la configuration apache

Si vous êtes sur apache2 il faut créer un fichier grml.eu.

etc/apache2/sites-available# more grml.eu
<VirtualHost *>
ServerName grml.eu
ServerAlias *.grml.eu
DocumentRoot /home/grml/public_html
</VirtualHost>

Ce qui veut dire que tous les sous domaines de grml.eu vont pointer vers le répertoire « /home/grml/public_html ».

Ensuite il faut faire une lien symbolique pour que le domaine soit actif

cd etc/apache2/sites-enable
ln -s /etc/apache2/sites-available/grml.eu  grml.eu

Enfin il faut prendre en compte ces changements

/etc/init.d/apache2 force-reload

Configuration DNS

Il faut maintenant que lorsque l’on tape grml.eu, il redirige vers l’adresse ip du serveur

voici la config utilisée chez gandi


Configuration de la mutualisation

Copier le fichier /home/grml/public_html/mutualisation/mes_options.php.txt vers « /home/grml/public_html/config » et enlevez l’extension « .txt » . Ouvrez ce fichier et procédez au paramétrage.

Pour vous aider voici le fichier de config utilisé sur scriibe

  1. <?php
  2.  
  3. $GLOBALS['taille_des_logs']=1000;
  4. #parametrage a faire
  5. $monTld="scriibe.net";
  6.  
  7. require _DIR_RACINE.'mutualisation/mutualiser.php';
  8. define ('_ID_WEBMESTRES', 1);
  9.  
  10. $site = $_SERVER['HTTP_HOST'];
  11.  
  12. $type_urls = 'propres2'; # par defaut, surchargeable ci-dessous
  13.  
  14. switch($site) {
  15. case "www.$monTld":
  16. $site=$monTld;
  17. break;
  18. case 'www.spip-blog.net':
  19. $site='spipblog';
  20. break;
  21. case 'spip-blog.net':
  22. $site='spipblog';
  23. break;
  24. default :
  25. $site = str_replace('.scriibe.net', '', $site);
  26. break ;
  27. }
  28. define ('_SITES_ADMIN_MUTUALISATION', ''); // ici sites esclaves
  29. define ('_INSTALL_SERVER_DB', 'mysql');
  30. define ('_INSTALL_HOST_DB', 'plouf');
  31. define ('_INSTALL_USER_DB_ROOT', 'plouf');
  32. define ('_INSTALL_PASS_DB_ROOT', 'plouf');
  33. define ('_INSTALL_TABLE_PREFIX', 'spip');
  34. define ('_INSTALL_NAME_DB', 'scr_'.prefixe_mutualisation($site));
  35. if ($site != "$monTld") {
  36. demarrer_site($site,
  37. 'creer_site' => true,
  38. 'creer_base' => true,
  39. 'code' => 'plouf',
  40. 'url_img_courtes' => true,
  41. 'creer_user_base' => true,
  42. 'mail' => 'ben.spip@gmail.com'
  43. )
  44. );
  45. }
  46. else {
  47. $GLOBALS['dossier_squelettes']=":mutualisation";
  48. }
  49.  
  50. ?>

Télécharger

pour celui sur GrmlEU

  1. <?php
  2.  
  3. if (!defined("_ECRIRE_INC_VERSION")) return;
  4. require _DIR_RACINE.'mutualisation/mutualiser.php';
  5.  
  6. $site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
  7. if ($site != $_SERVER['HTTP_HOST']) {
  8. include_spip('inc/headers');
  9. redirige_par_entete('http://'.$site.'/');
  10. }
  11.  
  12. define ('_INSTALL_SERVER_DB', 'mysql');
  13. define ('_INSTALL_HOST_DB', 'localhost');
  14. define ('_INSTALL_USER_DB', 'plouf');
  15. define ('_INSTALL_PASS_DB', 'plouf');
  16. define ('_INSTALL_NAME_DB', 'grml');
  17. #define ('_INSTALL_TABLE_PREFIX', 'spip');
  18.  
  19. define ('_SITES_ADMIN_MUTUALISATION', 'grml.eu');
  20.  
  21.  
  22. demarrer_site($site,
  23. 'creer_site' => true,
  24. 'creer_base' => false,
  25. 'creer_user_base' => false,
  26. 'mail' => 'ben.spip@gmail.com',
  27. 'code' => 'ecureuil',
  28. 'table_prefix' => true,
  29. 'cookie_prefix' => true,
  30. 'repertoire' => 'sites',
  31. 'url_img_courtes' => true,
  32. 'url_creer_base' => ''
  33. )
  34. );
  35.  
  36. ?>

Télécharger

On peut noter que pour scriibe, une base et un utilisateur mysql sont créés pour chaque site. Par contre sur GrmlEU, il n’y a qu’un user et qu’une seule base, avec un préfixe différent pour les tables de chaque site.

P.-S.

(voir aussi dans le Carnet Wiki Carnet Wiki : La mutualisation facile : modifications manuelles)

Notes

[1GrmlEU est un site qui permet d’essayer SPIP : vous pouvez créer un SPIP en quelques clics. Les sites sont effacés tous les mois

[2télécharger sur la zone.

Dernière modification de cette page le 5 février 2014

Retour en haut de la page

Tout afficher

Vos commentaires

  • Le 17 mars à 10:39, par Julien En réponse à : Ferme à SPIP

    Bonjour,

    J’ai pu configurer sans problème un SPIP 3.1 mutualisé avec 4 sous-domaines. Très intéressant cette méthode. Cependant, j’aurais deux questions :

    1. Est-ce que je peux avoir en commun un dossier « squelettes-all » pour tout mes sous-domaine et partager les mêmes ressources (css, js, img, formulaires, modèles, etc...) ?

    2. Dans ma configuration j’ai ces 4 sites ci-dessous :

    site1.example.com
    site2.exemple.com
    site3.exemple.com
    site4.exemple.com

    Mais quand au site principale : www.exemple.com, est-ce que je peux acquérir les informations de chaque sous-domaines ? Ou chacune des ces ressources sont distinctes.

    Merci, Julien.

    Répondre à ce message

  • Le 25 février à 01:27, par Stéphane Santon En réponse à : Ferme à SPIP

    Bonjour,
    Je viens de tester sous Spip 3.1 et la dernière version du plugin.
    Quand je crée un nouveau site, tout est parfaitement géré, sauf qu’à la fin il m’envoie vers http://www.example.com/ecrire/ecrire/?exec=install, donc un ecrire/ de trop dans l’url ...

    Répondre à ce message

  • Le 9 janvier à 17:20, par pgiron En réponse à : Ferme à SPIP

    Ce plugin est-il compatible avec la nouvelle version 3.1 ?

    • Le 9 janvier à 19:44, par Pierre KUHN En réponse à : Ferme à SPIP

      Bonsoir,

      Pas encore tester mais tu peux et nous dire si tu as des problèmes.

    • Le 10 janvier à 15:22, par pgiron En réponse à : Ferme à SPIP

      Merci, mais très honnêtement, j’ai plus de vingt sites mutualisés, je ne vois pas commenter tester avec un seul et voir si ça marche ou pas ! je préfère d’autres retours d’expériences que mon crash éventuel... :- !

    • Le 10 janvier à 15:46, par Pierre KUHN En réponse à : Ferme à SPIP

      Je te conseil de monter une mutu en 3.1 et modifier tes vhost pour tester.
      perso je passe pas encore en 3.1 car j’ai des plugins non compatible.

    • Le 10 janvier à 15:54, par pgiron En réponse à : Ferme à SPIP

      Ça tombe bien, moi aussi ;-) J’attendrai donc !

    • Le 18 janvier à 18:11, par Philippe B. En réponse à : Ferme à SPIP

      Bonjour,

      J’ai testé en local ce plugin avec SPIP 3.1 et j’ai des problèmes pour créer de nouveaux sites. A noter que tout fonctionnait parfaitement en 3.0 . Avec les sites déjà installés tout semble OK.

      Les fichiers connect.php et chmod.php ne sont pas créés dans config.

      Tout semble se passer bien jusqu’à la phase d’installation de SPIP c’est à dire :
      -  Activation avec un code OK
      -  Création du répertoire dans sites/ OK
      -  Création des répertoires config, IMG, local et tmp OK
      -  Création de la base de donnée (vide !) OK

      On arrive alors à l’écran indiquant : La base de donnée mu_mondomaine a été créée. Vous pouvez poursuivre l’installation de SPIP.

      On démarre la phase Installation du Système de publication... puis suivant... puis on reste bloqué sur Installation du système de publication à l’étape 1. Dans les logs de SPIP, on a : Pub : !INFO : spip_connect : fichier de connexion ’’ non trouve .

      A suivre !

    • Le 2 février à 10:27, par RealET En réponse à : Ferme à SPIP

      Pour ma part, je suis passé en 3.1 dès juillet 2015. En mutu. Et j’ai créé plusieurs sites sans problème.

      Voici mon config/mes_options.php :

      1. require _DIR_RACINE.'mutualisation/mutualiser.php';
      2.  
      3. $site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
      4. $site = str_replace('ww2.', '', $site);
      5. $site = str_replace('ww3.', '', $site);
      6.  
      7. define ('_INSTALL_SERVER_DB', 'mysql');
      8. define ('_INSTALL_HOST_DB', 'localhost');
      9. define ('_INSTALL_HOST_DB_LOCALNAME', 'localhost');
      10. define ('_INSTALL_USER_DB_ROOT', 'root');
      11. define ('_INSTALL_PASS_DB_ROOT', 'mot2passeroot');
      12. define ('_INSTALL_NAME_DB', 'mutu_'.prefixe_mutualisation($site));
      13. define ('_INSTALL_USER_DB', prefixe_mutualisation($site));
      14. define ('_INSTALL_TABLE_PREFIX', 'spip');
      15.  
      16. demarrer_site($site,
      17. 'creer_site' => true,
      18. 'cookie_prefix' => false,
      19. 'table_prefix' => false,
      20. 'creer_base' => true,
      21. 'creer_user_base' => true,
      22. 'code' => 'ecureuil',
      23. 'mail' => 'mutualisation@domaine.tld',
      24. 'annonce' => '<h3>SPIP 3.1</h3>',
      25. )
      26. );
      27. // Pour bloquer l'installation automatique des plugins
      28. define('_DIR_PLUGINS_AUTO', '');
      29. // Pas de log pour gagner en écritures
      30. #$GLOBALS['nombre_de_logs'] = 0;
      31. #$GLOBALS['taille_des_logs'] = 0;
      32.  
      33. # Dans le cadre d'une mutualisation, l'affichage d'une nouvelle version de SPIP est inutile
      34. function genie_mise_a_jour($t) {
      35. effacer_meta('info_maj_spip');
      36. return 1;
      37. }

      Télécharger

    • Le 2 février à 12:39, par Philippe B. En réponse à : Ferme à SPIP

      J’ai finalement entièrement réinstallé SPIP sans rien changé à mon fichier mes_options.php et ça marche !

      Désolé pour le bruit !

    Répondre à ce message

  • Le 8 mars 2012 à 15:10, par DM En réponse à : Ferme à SPIP

    Bonjour,
    J’essaie d’installer la mutualisation sur Gandi Simple Hosting.
    J’avais réussi sur Gandi Serveurs, mais là je sèche.
    J’ai suivi la méthode indiquée ici : http://www.spip-contrib.net/La-mutualisation-facile-modifications-manuelles, avec le plugin Mutualisation, et le fichier mes_options.php dans /config/ + .htacess à la racine.
    J’ai mis les fichiers spip 2.1 dans un répertoire de vhosts, sans site spip installé.

    Seulement, quand je lance l’install pour un 1er site mutualisé (depuis un nom.domaine.tld dirigé vers le vhost où se trouve Spip, j’ai les formulaires d’installation de Spip standards (pas de mutualisation, pas de code d’activation ecureuil demandé).
    Que faire ?

    Peut-être qu’il faut avoir obligatoirement déjà installé un site spip standard avant d’en installer des mutualisés ?

    Merci pour toute piste utile.

    Voici mon mes_options.php (on dirait qu’il n’est pas pris en compte du tout ?) :

    <?php

            /*
             * Inscrire ici le nom du site d'administration du tableau de bord
             * de la mutualisation (ou plusieurs, separes par des virgules)
             * (dans cet exemple, 'scriibe.net' est le top level domain, TLD)
             * pour autoriser tous les sites, ne pas definir la constante ;
             * Si le site maitre n'est pas dans sites/ mais a la racine, mettre ''
             * et ajouter 'mutualisation' dans $dossier_squelettes
             */
            define ('_SITES_ADMIN_MUTUALISATION', 'nom.domaine.tld');

            if (!defined("_ECRIRE_INC_VERSION")) return;
            if (!is_readable (_DIR_RACINE.'mutualisation/mutualiser.php')) {
                    echo _L("Fichier 'mutualisation/mutualiser.php' manquant dans la racine " . _DIR_RACINE);
                    exit;
            }
            require _DIR_RACINE.'mutualisation/mutualiser.php';

            /* placer dans ce tableau les sites ou l'on ne veut pas la redirection canonique */
            $www = array();
           
            $site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
            if ($site != $_SERVER['HTTP_HOST'] AND !in_array($site, $www)) {
                    include_spip('inc/headers');
                    $req = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '/';
                    if (isset($_SERVER['HTTPS'])
                    AND test_valeur_serveur($_SERVER['HTTPS']))
                            $protocole = 'https';
                    elseif (!isset($_SERVER["SCRIPT_URI"]) OR !($p = strpos($_SERVER["SCRIPT_URI"], '://')))
                            $protocole = 'http';
                    else $protocole = substr($_SERVER["SCRIPT_URI"],0,$p);
                    redirige_par_entete($protocole . '://' . $site . $req);
            }

            // Compatibilite avec le ":" de $dossier_squelettes
            // Si l'url indique explicitement un port (grace a ":")
            // tout eliminer s'il s'agit du port 80
            // et remplacer ":" par _ pour les autres ports

            if (strpos($site, ':')) {
                    if (preg_match('/:80$/', $site)) $site = substr($site,-3);
                    else $site = str_replace(':', '_', $site);
            }

            define ('_INSTALL_SITE_PREF', prefixe_mutualisation($site));
            define ('_INSTALL_NAME_DB', 'mu_'. _INSTALL_SITE_PREF);

            define ('_INSTALL_SERVER_DB', 'mysql');
            define ('_INSTALL_HOST_DB', 'localhost');
            define ('_INSTALL_USER_DB_ROOT', 'root');  
            define ('_INSTALL_PASS_DB_ROOT', 'mon-mot-de-pass-root');
           
            /* mettre en commentaire la ligne suivante si vous utilisez l'option table_prefixe plus bas dans la config */
            define ('_INSTALL_TABLE_PREFIX', 'spip');

            /*
             * Si le nom du serveur est different du nom dns,
             * ca peut parfois poser probleme
             * il faut alors le definir ici
             */
            # define ('_INSTALL_HOST_DB_LOCALNAME', 'nom_serveur');
           
            /*
             * Si le serveur n'est pas mysql, il faut le preciser obligatoirement.
             * # define ('_INSTALL_SERVER_DB', 'pg'); // mysql|pg|sqlite2|sqlite3
             *
             * /!\ En PG, il est conseille d'utiliser la creation d'utilisateur SQL
             */
           
            /*
             * Creer automatiquement les users SQL (pg|mysql)
             *
             * Cela permet
             * - d'avoir un utilisateur root possedant les droits
             * de creation de bases (cet utilisateur possedant obligatoirement
             * une base a son nom en PG - PG ne se connecte pas sans donner un nom de bdd)
             * - de creer des utilisateurs sql automatiquement
             * ne possedant que les droits d'administation
             * de leur base de donnee qui sera creee
             *
             * Il faut remplacer alors
             * _INSTALL_(USER|PASS)_DB par _INSTALL_(USER|PASS)_DB_ROOT
             *
             * et ajouter dans demarrer_site l'option
             * 'creer_user_base' => true
             */
            # define ('_INSTALL_USER_DB_ROOT', 'mon_root');
            # define ('_INSTALL_PASS_DB_ROOT', '********');

            /*
             * Creer les bases de donnees via un ping sur une URL (methode AlternC)
             *
             * Il suffit de renseigner l'option url_creer_base, en lui passant les bons parametres :
             * 'url_creer_base' => 'https://bureau.tld/admin/sql_doadd.php?username=USER&password=PASS&dbn='.prefixe_mutualisation($site)
             */
             
             
            /*
             * Transformer sur les pages publiques les url des images
             * /sites/mon_site/IMG/* -> /IMG/*
             * /sites/mon_site/local/* -> /local/*
             *
             * - Necessite le mod_rewrite (reecriture d'url) d'apache
             * - Ne fonctionne qu'avec des mutualisations de nom de domaine
             * ('http_host' : http://mon_site_mutu.tld)
             * (donc pas avec une mutualisation de repertoire - http://site/mon_spip_mutu/)
             *
             * et ajouter dans demarrer_site l'option
             * 'url_img_courtes' => true
             *
             * Il est possible de regenerer les fichiers .htaccess
             * crees automatiquement dans /IMG et /local
             * grace a ?var_mode=creer_htaccess_img
             *
             */
           
            demarrer_site($site,
                    array(
                            'creer_site' => true,        // Creer ou non le site s'il n'existe pas (defaut: false)
                            'creer_base' => true,        // Creer ou non la base de donnee si elle n'existe pas (false)
                            'creer_user_base' => true,  // Creer ou non un utilisateur pour la nouvelle base de donnee (false)
                            'mail' => '',                // Adresse mail pour recevoir un mail lors d'une creation de site mutualise ('')
                            'code' => 'activation',        // Code d'activation ('actvation') pour tentative VHOST spip
                            'table_prefix' => false,     // Definir automatiquement le prefixe de table (false) ... mettre true si tous les sites dans la meme base
                            'cookie_prefix' => true,     // Definir automatiquement le prefixe de cookie (false)
                            'repertoire' => 'sites',     // Nom du repertoire contenant les sites mutualises ('sites')
                            'url_img_courtes' => true,   // Utiliser la redirection des URL d'images courtes dans la partie publique (false)
                                                                                     // /!\ il faut qu'apache ait le droit d'ecrire dans les dossiers IMG/ et local/ a la racine du site !
                                                                                     // C'est la que la mutualisation va ecrire les regles de redirection automatiques pour les images de chaque site
                            # 'utiliser_panel' => false, // Utiliser une table externe pour recuperer des identifiants ... (code, user, pass) permettant a un utilisateur d'installer le site (false)
                            # 'annonce' => '<p>Un service propos&eacute; par <a href="http://www.spip.net/">la communaut&eacute; SPIP</a></p>', // Texte a afficher en bas du formulaire d'activation de la mutualisation
                            'url_creer_base' => ''       // Creer la base de donnees via une URL (methode AlternC)
                    )
            );

    ?>
    • Le 17 mars 2012 à 20:18, par DM En réponse à : Ferme à SPIP

      Bon, finalement, ça a marché !, avec ce même fichier mes_options.php
      en repartant à zéro sur un autre espace vhost, pourtant les réglages sont les mêmes
      Pas compris pourquoi avant ça ne marchait pas, bizarre...

      Conclusion, la mutualisation spip (2.1 en l’occurence) peut fonctionner sur Gandi Simple Hosting, si ça peut servir à d’autres...

    • Le 25 janvier 2015 à 04:44, par sebreb En réponse à : Ferme à SPIP

      Bonjour,
      Malgré les indications précédentes, je n’arrive pas à installer une mutualisation spip 3 sur Gandi Simple Hosting... Est-il possible de contourner le réglage des fichiers VirtualHost ? (etc/apache2/sites-available/ n’est pas accessible). Je serais curieux de savoir ce que DM a ajouté dans son .htaccess.
      Merci d’avance pour votre aide,
      Sébastien

    Répondre à ce message

  • Le 30 novembre 2014 à 22:21, par mrskater En réponse à : Ferme à SPIP

    Bonjour,
    je rencontre un problème avec les sites de ma ferme. Les images des squelettes des sites ne s’affichent pas avec la nomenclature classique : « squelettes/img/image.jpg ».
    Je suis obligé d’utiliser celle-ci : « sites/nomdusite/squelettes/img/image.jpg ».
    Ce qui est très embêtant lorsque je dois mettre un site en production sur un serveur client. Comment faire pour changer ce fonctionnement ?

    Merci par avance.

    • Le 1er décembre 2014 à 07:32, par Pierre KUHN En réponse à : Ferme à SPIP

      Bonjour, vous pouvez donnez le fichier mes_options ?

    • Le 1er décembre 2014 à 20:07, par mrskater En réponse à : Ferme à SPIP

      Bonsoir Pierre,
      le fichier mes_option.php à la racine dans le dossier config contient ce code :

      <?php
      define ('_SITES_ADMIN_MUTUALISATION', '');

      if (!defined("_ECRIRE_INC_VERSION")) return;
      if (!is_readable (_DIR_RACINE.'mutualisation/mutualiser.php')) {
      echo _L("Fichier 'mutualisation/mutualiser.php' manquant dans la racine " . _DIR_RACINE);
      exit;
      }
      require _DIR_RACINE.'mutualisation/mutualiser.php';

      $www = array();
             
      $site = str_replace('www.', '', $_SERVER['HTTP_HOST']);
      if ($site != $_SERVER['HTTP_HOST'] AND !in_array($site, $www)) {
      include_spip('inc/headers');
      $req = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '/';
      if (isset($_SERVER['HTTPS'])
      AND test_valeur_serveur($_SERVER['HTTPS']))
      $protocole = 'https';
      elseif (!isset($_SERVER["SCRIPT_URI"]) OR !($p = strpos($_SERVER["SCRIPT_URI"], '://')))
      $protocole = 'http';
      else $protocole = substr($_SERVER["SCRIPT_URI"],0,$p);
      redirige_par_entete($protocole . '://' . $site . $req);
      }

      if (strpos($site, ':')) {
      if (preg_match('/:80$/', $site)) $site = substr($site,-3);
      else $site = str_replace(':', '_', $site);
      }

      define ('_INSTALL_PREFIX_DB','mu_');
      define ('_INSTALL_SITE_PREF', prefixe_mutualisation($site));
      define ('_INSTALL_NAME_DB', _INSTALL_PREFIX_DB. _INSTALL_SITE_PREF);

      define ('_INSTALL_SERVER_DB', 'mysql');
      define ('_INSTALL_HOST_DB', 'localhost');
      define ('_INSTALL_USER_DB', 'root');  
      define ('_INSTALL_PASS_DB', 'root');
             
      define ('_INSTALL_TABLE_PREFIX', 'spip');
             
      demarrer_site($site,
      array(
      'creer_site' => true,  
      'creer_base' => true,      
      'creer_user_base' => false,
      'mail' => '',  
      'code' => 'ecureuil',
      'table_prefix' => false,
      'cookie_prefix' => true,  
      'repertoire' => 'sites',  
      'url_img_courtes' => true,
      'url_creer_base' => ''
      )
      );
      ?>

      Je pensais que ça pouvait venir d’une mauvaise configuration de Mamp mais sur serveur OVH il y a le même problème. Le problème concerne uniquement les images référencées dans les squelettes, les images du back-office s’affichent normalement.

      Merci par avance.
      Mathieu.

    • Le 2 décembre 2014 à 08:10, par Pierre KUHN En réponse à : Ferme à SPIP

      Comment tu appels les images sur le site ?

    • Le 3 décembre 2014 à 11:51, par mrskater En réponse à : Ferme à SPIP

      Classique : <img src="squelettes/img/image.jpg" alt="" />

    • Le 3 décembre 2014 à 11:57, par Pierre KUHN En réponse à : Ferme à SPIP

      Euh utilise #CHEMIN alors

    • Le 3 décembre 2014 à 12:08, par mrskater En réponse à : Ferme à SPIP

      Malheureusement ça ne donne rien.

    • Le 3 décembre 2014 à 12:17, par Pierre KUHN En réponse à : Ferme à SPIP

      Tu fait comment exactement ?
      </code

    • Le 3 décembre 2014 à 12:18, par Pierre KUHN En réponse à : Ferme à SPIP

      <img src="#CHEMIN{img/image.jpg}" alt="" />

    • Le 3 décembre 2014 à 12:31, par mrskater En réponse à : Ferme à SPIP

      Yes merci ça marche, je faisais <img src="#CHEMIN{squelettes/img/image.jpg}" alt="" />

      Merci encore.

    Répondre à ce message

  • Le 29 juillet 2014 à 17:15, par pgiron En réponse à : Ferme à SPIP

    Bonjour, J’ai 16 sites SPIP mutualisés en 3.0.16. Jusque là je n’ai eu aucun problème non résolu mais là... Le code d’activation ne fonctionne plus pour le 17e site ! Le pire c’est que je l’ai noté quelque part et donc c’est ce code que je rentre mais j’ai toujours « Erreur » qui s’affiche. Mystère très ennuyeux...
    Où puis-je trouver le code ? J’ai fait une première recherche dans chmod.php sans succès.
    Merci d’avance.
    Philippe G.

    • Le 29 juillet 2014 à 19:19, par pgiron En réponse à : Ferme à SPIP

      Honte sur moi, le code est dans mes_options.php (en plus c’est moi qui l’ai mis). Par contre il ne marche plus ! !! :-(

      JPEG - 31.4 ko
    • Le 8 septembre 2014 à 13:39, par Pierre KUHN En réponse à : Ferme à SPIP

      Bonjour,
      Je vois un caractère  sur la capture, c’est pas logique déjà.

    Répondre à ce message

  • Le 4 février 2013 à 07:09, par lupitek En réponse à : Ferme à SPIP

    Bonjour,

    J’ai un soucis avec les plugins sur un spip3 mutualisé.
    Dès que je mets à jour un plugin sur le noyau mutualisé et que je repasse sur chacun des sites, le plugin mis à jour ne se réactive pas... je suis obligé de les réactiver un par un manuellement.
    Dans spip2 ca fonctionnais correctement, un plugin mis a jour dans la mutualisation était automatiquement mis à jour et activé dans les sites mutualisés.

    Help, c’est hyper pénible !

    • Le 4 février 2013 à 08:03, par Pierre KUHN En réponse à : Ferme à SPIP

      Bonjour

      Tu as une dépendance par hasard qui s’active en même temps ?
      Comment mets tu à jour ?

    • Le 4 février 2013 à 08:27, par lupitek En réponse à : Ferme à SPIP

      Je mets a jour les plugins dans la mutualisation / gestion des plugins quand elle est signalée.
      Mes plugins sont dans plugins/auto/
      Pas de problèmes de dépendances, même une mise à jour mineure (3.1.1 à 3.1.12 par exemple) n’est pas réactivée automatiquement. J’ai testé sur tous les plugins de ma mutualisation (50 au moins), ca ne marche jamais (CFG, Couteau suisse, Court cirtuit, barre typo, etc...) je dois réactiver 1 par 1.

    • Le 7 août 2013 à 11:33, par Manu En réponse à : Ferme à SPIP

      Je réactive le sujet car il semble que ce soit un souci récurrent cette histoire de désagréments constatés mise à jour de plugin dans le cadre d’une mutualisation...
      Quelqu’un pourrait-il faire un point là-dessus et donner la bonne méthode pour effectuer les mises à jour sans que « ça casse » ?

    • Le 23 août 2013 à 16:02, par pierrot En réponse à : Ferme à SPIP

      Je constate le même problème et pour l’instant j’envisage de basculer sur un dossier plugins par site au lieu d’un dossier plugins central pour éviter ce problème.
      Mais je rencontre un problème avec le plugin Saisies (enfin pas forcément avec ce plugin mais c’est ce plugin qui semble le révéler), je le décrit ici :

      http://contrib.spip.net/Saisies?debut_comments-list=-1#forum470211

      P.

    • Le 15 février 2014 à 18:12, par DavidM En réponse à : Ferme à SPIP

      Même problème (spip 3.0.14) chez moi.
      Seul le site d’où la mise à jour du plugin se fait reste activé. Le plugin se désactive sur les autres sites, et du coup peut générer des erreurs sur le site public, etc.
      Parfois (dans le cas je crois des mises à jour Saisies et/ou Couteau Suisse), j’ai été obligé de vider le cache pour me sortir des pages publiques blanches qui ont suivies ce genre d’erreurs.
      (le problème est le même qu’une mise à jour soit lancée depuis la page plugin de l’admin ou depuis la page « mise à jour auto » du Couteau Suisse)

      Donc, peut-être que je vais devoir faire comme Pierrot, un dossier plugin par site, au moins pour les sites les plus importants. Mais c’est ennuyeux car on perd un des intérêts de la mutualisation du noyau...

    • Le 15 février 2014 à 18:57, par Manu En réponse à : Ferme à SPIP

      Non ! Il faut garder la mutualisation car sinon, effectivement on perd l’intérêt du truc.
      Le souci rencontré est dû au fonctionnement de SVP qui « nomme » les dossiers.Lors d’une mise à jour, le nom du dossier change, et du coup, paf, les plugins des autres sites se désactivent. Normal.
      La solution consiste à faire les mises à jour sans passer par SVP.
      Soit tu mets à jour par SVN
      Soit tu fais la mise à jour par FTP : le nom du dossier ne changeant pas (seuls les fichiers contenus sont modifiés) et rien ne se désactivera.

    • Le 15 février 2014 à 20:02, par Pierrot En réponse à : Ferme à SPIP

      Pour ma part j’ai essayé ceci :

      http://contrib.spip.net/Et-si-on-automatisait-tout-ca

      Vers le bas, Gestion des plugins et suggestions de modifs du plugin SVP pour que la mise à jour de plugins conserve les versions précédentes et ainsi ne désactive rien dans les autres sites de la ferme. Il faut ensuite bien sûr passer sur chaque site pour activer les nouveaux plugins si on souhaite les mettre à jour.

    • Le 15 février 2014 à 20:43, par DavidM En réponse à : Ferme à SPIP

      Ok Manu, merci pour le truc.
      Par ftp, je sais faire, ce n’est pas très pratique, mais c’est mieux que de devoir réactiver les plugins sur chaque site.
      Par SVN, je ne sais pas bien faire. Il faut un accès ssh pour le faire direct sur l’espace d’hébergement des sites c’est ça ? Pas sûr que ça marche sur mon hébergeur Gandi Simple Hosting...

      J’imagine que je peux gérer un dossier des plugins sur mon disque dur mis à jour par SVN ?, et envoyer ça par FTP ensuite (en gardant les mêmes noms des dossiers des plugins)
      Dans ce cas, il vaut mieux sortir les plugins du site du dossier « auto » non ?

      Pour les solutions de Pierrot, ça parait trop compliqué pour mo !, ça a l’air intéressant, mais j’attendrai une version ad hoc du plugin Mutualisation. En tout cas, merci, là je comprends mieux pourquoi ça plante actuellement.
      D’autant que je n’ai pas de sites Maître/esclaves, ils sont tous au même niveau a priori.

      -  Idée : Pour l’avenir, un truc qui serait top, c’est que la page admin (plugins actifs ou inactifs) des plugins dans Spip puisse afficher la liste des sites web qui utilisent chaque plugin, pour mieux s’y retrouver.

    • Le 16 février 2014 à 09:50, par YannX En réponse à : Ferme à SPIP

      Si on ne peut pas utiliser SVP pour faire la mise a jour (c’est presque aussi dommage de pas pouvoir mutualiser ses mises a jour ;-), il faut peut-etre revenir au systeme précédent :
      avant, en SPIP2 (et meme au debut de SPIP 3 par habitude), j’utilisais une lame du couteau suisse pour identifier et lancer les mises a jour..... http://contrib.spip.net/Mise-a-jour-automatique-des-plugins

      Mais, ne l’ayant pas appliqué sur des mutualisations, je n’ai pas vérifié le fonctionnement en détail sur le point évoqué.... l’un d’entre vous peut-il essayer ? et transmettre son résultat...

      Cdlt
      @+

    • Le 16 février 2014 à 10:37, par Pierre KUHN En réponse à : Ferme à SPIP

      DavidM : - Idée : Pour l’avenir, un truc qui serait top, c’est que la page admin (plugins actifs ou inactifs) des plugins dans Spip puisse afficher la liste des sites web qui utilisent chaque plugin, pour mieux s’y retrouver.
      => tu as cela sur la page exec=mutualisation, disponible dans le site maitre uniquement.

    • Le 16 février 2014 à 10:38, par DavidM En réponse à : Ferme à SPIP

      @YannX, j’ai testé la mise à jour auto par la lame Couteau Suisse, pour le plugin Saisies ça a désactivé pareillement les plugins sur les autres sites.
      Donc a priori ça ne marche pas mieux que SVP de spip 3...

    • Le 16 février 2014 à 10:45, par DavidM En réponse à : Ferme à SPIP

      @ Pierre, je croyais qu’il n’y avait plus de site Maître dans cette configuration ? C’est le site où est installé les fichiers spip communs ? Je ne l’ai pas créé celui-ci (j’utilise 7 sites mutualisés, dont 4 en production).

    • Le 16 février 2014 à 10:59, par Pierre KUHN En réponse à : Ferme à SPIP

      Euh perso j’en indique 1 dans le fichier de configuration du plugins afin de limiter qui utilise cette page.

    • Le 16 février 2014 à 11:16, par DavidM En réponse à : Ferme à SPIP

      Pardon, je n’avais pas regardé ça attentivement. Du coup, j’avais mal compris et mis un site non actif (celui avec Spip) dans le code         define ('_SITES_ADMIN_MUTUALISATION', 'monsite.tld'); de mes_options.php

      Là j’ai mis un site actif à la place, et j’ai effectivement une liste utile avec ecrire/ ?exec=mutualisation, merci !

    • Le 11 juin 2014 à 23:26, par DavidM En réponse à : Ferme à SPIP

      J’ai testé pour un plugin le fait de l’avoir dans un dossier « plugins » pour un seul site mutualisé :

      Il faut mettre un code dans le fichier mes_options.php du site concerné :
      // code pour que le dossier plugins/auto du site concerné soit prix en compte en plus du dossier plugins/auto de l’install spip mutualisée qui est à la racine :

      1. define('_DIR_PLUGINS_SUPPL',_DIR_RACINE.'sites/monsite.tld/plugins/');

      En mettant ce code (remplacer monsite.tld par le bon nom de site), le plugin test apparaît bien sur le site concerné (il faut juste le réactiver après son déplacement d’un dossier à l’autre), et la mise à jour ensuite est ok.

      Comme ça je peux mettre à jour les plugins de chaque site séparément, en évitant les plantages dues aux mises à jour qui ne sont pas suivies par les autres sites (problème SVP indiqué ci-dessus).
      Accessoirement, ça permet de tester une màj plugin sur un seul site.

    • Le 12 juin 2014 à 12:34, par Pierrot En réponse à : Ferme à SPIP

      Bonjour,

      J’ai évoqué cette solution mais elle me pose (en tous cas me posait) des pbms évoqués ici :

      http://contrib.spip.net/Saisies?debut_comments-list=-1#forum470211

      Certains plugins semblent buguer sur cette solution, peut-être n’utilisez-vous pas ces plugins ou peut être qu’un bug a été corrigé. Pour ma part j’ai fini par peu à peu abandonner ces mutualisations qui me posaient plus de soucis que de gains, chaque mise à jour était un sac de noeuds, la modif de SVP était à surveiller ... bref j’ai re-séparé mes installations et c’est beaucoup plus zen (j’avais 3 fermes avec environ 25 sites).

    • Le 13 juin 2014 à 23:02, par DavidM En réponse à : Ferme à SPIP

      Après quelques essais supplémentaires, je me suis rendu compte que le système décrit ci-dessus n’est pas terrible. En fait, si on met les plugins de chaque site dans « auto », avec une mise à jour du plugin la nouvelle version du plugin se remet dans le dossier plugins du spip mutualisé, c’est retour à la case départ.

      Finalement, j’ai laissé tel quel (les plugins mutualisés pour tous les sites), c’est encore le moins compliqué, et je met à jour les plugins un par un depuis un site, avec ensuite réactivation du plugin sur chacun des autres sites.
      En attendant une solution intégrée, je ferai donc les mises à jour moins souvent.

    • Le 18 juin 2014 à 13:38, par DavidM En réponse à : Ferme à SPIP

      @ Pierrot : Récemment (sur spip 3.0.14), je n’ai pas eu de problème avec la mise à jour de Saisies. Faut juste le réactiver sur tous les sites.... comme pour les autres plugins. Perso j’ai 7-8 sites, donc 5 seulement sont publics, donc c’est gérable.

      Sinon, comme disait je crois Pierrot sur un autre fil, peut-être que pour la méthode que j’ai testée (http://contrib.spip.net/Ferme-a-SPIP#forum475819, ci-dessus) marche pour les mises à jour, il faudrait supprimer le dossier plugins du site mutualisé ? (pour éviter que Spip ne remette les plugins dedans lors d’une mise jour de plugin)
      Mais je ne testerai pas, pas le temps. Je préfère rester comme ça et attendre une vraie solution qui permette de vraiment mutualiser les plugins efficacement en plus de spip.

    Répondre à ce message

  • Le 1er février 2014 à 12:46, par ElJuez En réponse à : Ferme à SPIP

    Bonjour,

    J’ai passé la matinée pour réussir à monter une ferme, je pense avoir à peu près tout compris, même si certaines zones restent un peu obscures pour moi.

    Je pense que la partie configuration du fichier mes_options mériterait quelques informations supplémentaires car il y a plusieurs façons de travailler (il suffit de voir les deux exemples qui sont différents)
    Particulièrement le paramétrage de la variable de SITE_ADMIN ... parfois blanc, parfois pas ... comment cela marche exactement m’échappe.

    Ce que je sais uniquement c’est qu’en le remplissant et en essayant de configurer un site qui n’était pas le même que la dedans, ça plantait ...

    Bon mes questions sont les suivantes :

    La doc du wiki indique que le site « principal » n’est pas accessible. Moi je me suis inspiré du fichier de scriibe.net et l’ai configuré pour créer mon premier site. La procédure a été jusqu’au bout.
    Initialement j’ai créé le spip à l’adresse « fermeaspip.e-delmotte.com », installation sans soucis, j’ai ajouté tout un jeu de plugins à l’intérieur, les ai activé, puis suis passé à la suite ...

    Question 1 :
    -  si je tape aujourd’hui « fermeaspip.e-delmotte.com » j’arrive sur une page avec erreur de squelettes, à priori autour de z ... pourquoi mon domaine est joignable ? Je pensais arriver sur un dashboard particulier.
    Si tel n’est pas le cas, à quoi sert cette adresse ? Comment accede t on a « l’administration de la mutualisation » comme on en parle dans le wiki ?

    Question 2 :
    -  quand j’ai installé le second site, il avait tous les plugins ... mais inactifs, c’est le comportement attendu ? On active les plugins qui nous intéresse en fonction des sites ?

    Question 3 :
    -  on peut installer des plugins depuis n’importe quel site et ils sont mis à disposition de tout le monde ?

    Merci d’avance

    • Le 1er février 2014 à 13:28, par ElJuez En réponse à : Ferme à SPIP

      Bon pour accéder à l’administration, j’ai trouvé cela
      http://fermeaspip.e-delmotte.com/ecrire/?exec=mutualisation

      Si c’est bien cela ... pourquoi c’est vide ? Alors que j’ai installé un site ...

      J’ai activé les plugins sur le site installé ... et même problème de squelettes, zcore marche pas après installation.
      Faut que je fasse un truc particulier ?

    Répondre à ce message

  • Le 15 octobre 2013 à 11:53, par Arielle En réponse à : Ferme à SPIP

    Bonjour,

    Depuis la mise en place du pluggin (spip 3) je n’arrive plus à lire mes fichiers pdf (plugin pdf.js) -> spip.php ?page=pdfjs&id_document=x..
    Dans le fichier sip.log j’ai le message d’erreur ci dessous :
    :Pri:ERREUR : fonction execute_pipeline_renseigner_document absente : pipeline desactive

    Auriez vous déjà rencontré ce genre de problème ?

    Cordialement,
    Arielle.

    PNG - 20.3 ko

    Répondre à ce message

  • Le 23 septembre 2013 à 00:00, par soon7 En réponse à : Ferme à SPIP

    Hello,

    J’ai rédigé un petit billet concernant l’installation de spip mutualisé en spip 3 sur un mutualisé OVH avec serveur sql dédié : http://www.soon7.com/developpements/mutualisation-du-noyau-spip-3-sur-un-mutualise-de-chez-ovh/

    Répondre à ce message

Répondre à cet article

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • Mailsubscribers

    16 janvier 2013 – 274 commentaires

    Ce plugin permet de gérer les inscriptions (ou abonnements) à la diffusion de contenu par email. Mailsubscribers permet de gérer les inscriptions par Opt-in simple ou double et la désinscription par URL. Ce plugin gère également plusieurs listes (...)

  • noiZetier v2

    9 novembre 2012 – 36 commentaires

    Le noiZetier offre une interface d’administration permettant d’insérer au choix des éléments modulaires de squelettes (noisettes) et de les ajouter ainsi à ses squelettes. Compatibilité La version 2 du noizetier fonctionne sous SPIP 3. Elle est (...)

  • cirr : plugin « rédacteur restreint »

    29 octobre 2010 – 60 commentaires

    Ce plugin « cirr : rédacteur restreint » permet d’affecter des rubriques aux rédacteurs et modifie les droits afin qu’un rédacteur restreint (ou un administrateur restreint) voit dans l’espace privé uniquement les rubriques qui lui sont affectées (et leur (...)

  • Un retour d’expérience d’utilisation de Formidable

    26 octobre – commentaires

    Il s’agissait de créer un formulaire d’inscription à un évènement modérer les inscriptions dans le privé publier les inscriptions dans le public Nous avons discuté de cette présentation lors de l’apéro SPIP du 15 février 2016 à la Cantine (...)

  • Métas +

    3 décembre – 14 commentaires

    Améliorez l’indexation de vos articles dans les moteurs et leur affichage sur les réseaux sociaux grâce aux métadonnées Dublin Core, Open Graph et Twitter Card. Installation Activer le plugin dans le menu dédié. Dans le panel de configuration, (...)

Ça spipe par là