SPIP-Contrib

SPIP-Contrib

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

288 Plugins, 197 contribs sur SPIP-Zone, 75 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 – 144 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

Dernière modification de cette page le 29 octobre 2017

Retour en haut de la page

Tout afficher

Vos commentaires

  • Le 29 mai 2011 à 20:43, par Apprenti geek En réponse à : Ferme à SPIP

    Bonjour, j’ai installé le plugin mutualisation et tout marche impeccable.

    Seulement voilà, je ne sais pas comment faire un lien du dossier IMG d’un nouveau site mutualisé vers le dossier IMG du site existant avant la mutualisation...

    Dans le carnet Wiki sur la mutualisation, un auteur a écrit :
    “Ces répertoires peuvent être des liens symboliques vers les originaux du site à la racine, mais dans ce cas, le fichier mes_options.php devrait être déplacé dans /ecrire”

    J’ai bien mis mon fichier mes_options.php dans /ecrire/ mais je ne sais pas comment mettre en place ces liens symboliques.

    Quelqu’un aurait-il une idée ?

    Merci d’avance et comme d’hab, bravo pour le travail collaboratif de toute cette communauté !

    • Le 29 mai 2011 à 22:23, par Pierre KUHN En réponse à : Ferme à SPIP

      Bonjour

      Pourquoi ne pas déplacer le fichier IMG vers la mutualisation ?

    • Le 30 mai 2011 à 16:56, par Apprenti Geek En réponse à : Ferme à SPIP

      Bonjour,

      Tu as raison, mais étant que deux sites utiliseront la même base de données et donc les mêmes ressources à savoir le répertoire IMG, j’aurai aimé automatiser un peu le truc...

      Deux solutions s’offrent à moi :
      -  soit je mets en place une synchronisation automatique des deux sous répetoires IMG (aucune idée comment procéder mais cette solution supposerait de dupliquer automatiquement tout fichier dans le dossier IMG du site 1 vers le dossier IMG du site 2 ;
      -  soit je permets au site 2 d’aller chercher son dossier IMG non pas dans son sous répertoire, mais dans le sous répertoire du site 1 ;

      J’espère que je suis suffisamment clair... tu penses pouvoir m’aider ?

      Merci d’avance en tout cas pour ta réponse

    • Le 30 mai 2011 à 18:46, par Pierre KUHN En réponse à : Ferme à SPIP

      Alors à ta réponse voici une question : 2 sites OK

      Pourquoi la même base et les même images, autant faire un site non ?

    • Le 30 mai 2011 à 19:07, par Apprenti Geek En réponse à : Ferme à SPIP

      non parce que le site 1 n’a pas le même design et ne propose pas les mêmes fonctionnalités que le site 2 ... donc des templates différents mais un contenu de base similaire pour certaines rubriques...

    Répondre à ce message

  • Le 9 mars 2011 à 17:02, par filnug En réponse à : Ferme à SPIP

    Bonjour,

    Je pense créer un site internet et un blog. Idéalement le site sera multilingue et le blog dans une seule langue.

    Mon but est d’avoir une adresse internet www.adresseweb.com et un sous-domaine interne pour mon blog : blog.adresseweb.com

    Est ce que ce plugin est adapté à mon objectif ?
    Si non, y a t il une autre solution ?

    Merci

    • Le 9 mars 2011 à 20:03, par Pierre KUHN En réponse à : Ferme à SPIP

      Bonsoir
      L’intéré de ce plugins est de mutualiser un spip et ses plugins donc si tu as 2 sites et 2 squelettes cela ne vos pas le coup a mon avis.

      Peux tu nous en dire plus sur ton projet ?

    • Le 10 mars 2011 à 08:23, par filnug En réponse à : Ferme à SPIP

      Comme indiqué dans mon précédent message, je souhaite réaliser un site sur une adresse et un blog sur un domaine interne (par exemple http://blog.adresseweb.com.
      L’une des solution que je vois, est de créer des compositions différentes (une pour le site + une autre pour le blog) avec plusieurs rubriques dont l’une blog. Sur mon FTP, dans mon répertoire /blog, je pourrais placer un fichier de redirection php vers l’url générée par spip pour la rubrique blog.

      Néanmoins, tout ça me semble de la bricole. D’où mes recherches s’il n’y aurait pas une meilleure solution plus « propre ».

    • Le 10 mars 2011 à 10:07, par Pierre KUHN En réponse à : Ferme à SPIP

      Dans ce cas autant monter 2 sites a moins que tes plugins soit commun car si je comprend bien tu utiliserais Composition ?

    • Le 10 mars 2011 à 10:10, par filnug En réponse à : Ferme à SPIP

      Oui, j’utiliserais Compositions et d’autres plugins certainement en commun.
      Néanmoins, le désavantage de 2 sites est d’avoir 2 espaces privés. Mon but est d’en avoir idéalement un seul. D’ou mas recherche sur la mutualisation.

    • Le 10 mars 2011 à 10:17, par Pierre KUHN En réponse à : Ferme à SPIP

      Euh alors tu as pas compris ce qu’est la mutualisation. La mutu te permets d’avoir x sites sur 1 SPIP et donc x espaces privés.

      Si tu veux 1 espace privé, il te faut dans ce cas jouer avec le plugins multidomaine http://www.spip-contrib.net/Plugin-Multidomaines

    Répondre à ce message

  • Le 31 décembre 2010 à 14:39, par manu En réponse à : Ferme à SPIP

    La personnalisation de la variable $dossier_squelettes> via $GLOBALS['dossier_squelettes'] = 'mon_dossier' dans mes_options.php ne fonctionne pas chez moi dans le cadre d’une ferme à spip. C’est normal ça ?

    • Le 1er janvier 2011 à 11:43, par manu En réponse à : Ferme à SPIP

      Je me réponds à moi-même...
      En fait il faut indiquer le chemin complet du répertoire que l’on souhaite prendre en compte

      Par ex : pour le site1 :

      dans
      www/sites/monsite1/config/mes_options.php

      il faut indiquer
      $GLOBALS['dossier_squelettes'] ='sites/monsite1/skel';
      et le rép. skel est bien pris en compte.

      Quand on y réfléchit, c’est assez logique, mais c’est tout de même perturbant au premier abord puisqu’on a envie d’écrire
      $GLOBALS['dossier_squelettes'] ='skel';

      et dans ce cas, SPIP s’attend à trouver un dossier ’skel’ à la racine.. de la mutualisation ! Et non pas à la racine « du site1 »

      Logique, mais pas tout à fait « portable » : si on sort le site de la mutualisation (ex : sur mon site de développement en local, c’est en mutu <==> sur le site en production, ce n’est plus le cas), le contenu de mes_options.php n’est pas strictement le même

      N’y aurait-il pas moyen d’homogénéiser les deux écritures ?

      Allez, bonne année à notre écureuil et un énoooorme merci à ses développeurs !

    Répondre à ce message

  • Le 15 octobre 2009 à 10:08, par Marc VALLETEAU de MOULLIAC En réponse à : Mutualiser en domaines et pas en sous-domaines

    Bonjour, je trouve ce plugin vraiment formidable, car je suis en train de mettre en place sur mon serveur dédié (Apache 2) un hébergement de sites accessibles par nom de domaine et non en sous-domaine.

    J’ai alors modifié les lignes du haut pour les remplacer par ceci :

    $site = $_SERVER['HTTP_HOST'];
      if ($site != $_SERVER['HTTP_HOST']) {
         include_spip('inc/headers');
         redirige_par_entete('http://'.$site.'/');
    }

    En effet, en laissant le code d’origine, impossible d’accéder à mon site « maître » (http://www.atoutsweb.org)

    Ai-je bien fait ? La mise en place d’un autre site a été un peu cahotique, - en utilisant un autre domaine pointant sur le « maître », il m’a mis directement dans la fenêtre de création d’un répertoire, et non sur la demande du code (ecureuil) - mais ça a bien fonctionné en fin de compte.

    Par contre, j’ai un souci plus embêtant : sur la partie publique, il n’arrive pas à afficher les images du dossier IMG ou local/cache-vignettes car le chemin est incomplet (alors que tout s’affiche bien en privé).

    La modification ci-dessus en est-elle la cause ? Sinon, comment faire pour corriger cela ?

    Merci d’avance

    Marc

    • Le 7 octobre 2010 à 23:44, par Delorimier En réponse à : Ferme à SPIP

      Idem - j’ai le même problème avec les images dans la partie publique

    • Le 8 octobre 2010 à 07:06, par Pierre KUHN En réponse à : Ferme à SPIP

      Bonjour

      Est ce que l’on peux avoir l’adresse du soucis et le code du mes_options ?

    • Le 8 octobre 2010 à 10:20, par VALLETEAU de MOULLIAC En réponse à : Ferme à SPIP

      Bien, d’une part, je suis content d’avoir enfin (!) une réaction au sujet de mon post ...

      Par ailleurs, le problème a été résolu en complétant la config sur mon serveur (Mac os X) : j’ai autorisé toutes les dérogations, ce qui fait que depuis, cela fonctionne. Donc, le code du fichier mes_options.php n’est pas en cause ...

      Ce qui me soucie le plus, depuis cette solution, c’est la gesiton des plugins (en 2.0.10), car la plugin sensé permettre d’ajouter/enlever des plugins directement dans chaque site mutualisé est absolument inefficace. Il apparaît bien, en effet, la possibilité d’ajouter des plugins, mais ensuite, impossible de les activer !!

      Je suis donc obligé de les mettre dans le site maître, ce qui ne m’arrange pas toujours ...

      Merci à quiconque pourra m’aider à trouver une solution ...

    • Le 8 octobre 2010 à 20:16, par Pierre KUHN En réponse à : Ferme à SPIP

      Bonsoir

      ton message est dater de 2009 ... alors que j’en ai répondu en 2010 quand meme

      Est ce que tu peux nous en dire plus ?

      -  Tu es parti de quel exemple ?
      -  droit sur les dossiers ?
      ...

      Pour infos, sur ma mutu j’ai domaines et sous domaine et j’ai pas de soucis, les webmaster ont tous les droits

    Répondre à ce message

  • Le 8 septembre 2010 à 15:09, par rpapa En réponse à : Ferme à SPIP

    J’aimerai bien installer le plugin mutualisation chez free-h.org au travers d’une interface Plesk
    certain d’entre vous ont-ils réalisé cette installation

    merci

    Répondre à ce message

  • Le 6 juillet 2010 à 17:03, par PieroWbmstr En réponse à : Ferme à SPIP

    Salut et merci pour ce super plugin qui facilite vraiment les choses.

    Une précision pour les futurs utilisateurs, fruit d’une petite heure de prise de tête :

    il est préférable de s’arranger pour que le nom du répertoire de chaque site (donc dans l’exemple de cet article dans le répertoire ’sites/’) ne comporte pas de point !

    Je sais, c’est bateau mais si l’expérience peut servir ... j’aurai moins l’impression d’avoir perdu une heure pour une erreur d’inattention ;-)

    Explication rapide du problème rencontré :
    Si le répertoire d’un site est nommé du type ’sites/mondom.fr/’, certaines actions et notamment les téléchargements et accès aux documents sont impossibles (cas sur un serveur mutualisé OVH avec chmod limité à 755) ...
    Préférez donc des noms de répertoires du type ’mondom_fr/’ ou ’mondomfr/’

    Tchuss

    • Le 6 juillet 2010 à 17:16, par Pierre KUHN En réponse à : Ferme à SPIP

      Bonsoir

      Cela est possible chez OVH mais je n’ai pas ce soucis avec mon hébergeur même avec des sous.domaine.fr par exemple.

    Répondre à ce message

  • Le 29 juin 2010 à 11:05, par habbon En réponse à : Ferme à SPIP

    Bonjour,

    Petit truc de Matthieu Marcillaud passé sur l’IRC.

    Dans le cas d’une installation d’un mutualisation sur un site déjà existant, afin de conserver le site maitre accessible, rajouter autour des lignes 8/10 de mes_options.php :

    1. $mutualisation = ($_SERVER['HTTP_HOST'] == 'ledomaine.tld') ? false : true ;
    2. if ($mutualisation) {
    3. define ('_SITES_ADMIN_MUTUALISATION', 'ledomaine.tld');
    4. /* ici, tout le reste de votre mes_options.php concernant la mutualisation, et mettre le } pour finir le if */
    5. }

    Télécharger

    Une grand merci à Matthieu et à la communauté SPIP.

    Répondre à ce message

  • Le 19 avril 2010 à 16:27, par François Daniel Giezendanner En réponse à : Ferme à SPIP

    Recherche spécialiste SPIP pour enseigner la maîtrise de la création de Fermes à SPIP : Etat de l’art

    Pour dispenser cette formation à une équipe du SEM nous cherchons un spécialiste SPIP ayant la maîtrise et l’expérience de la mise en place de Fermes à SPIP avec les technologies les plus performantes.

    Les personnes intéressées sont priées de s’adresser à :

    François Daniel Giezendanner : francois-daniel.giezendanner at edu.ge.ch

    en indiquant des exemples de réalisations de fermes à SPIP.

    Information complémentaire : http://icp.ge.ch/sem/cms-spip/spip.php?article1039

    Répondre à ce message

  • Le 19 octobre 2009 à 12:46, par philp En réponse à : mutualiser_creer.php

    Bonjour,

    Je voudrais signaler un truc qui me semble important, dans le cadre d’une installation mutualisée par sous-domaines ou le serveur Apache n’est pas le serveur MySQL, et ou on souhaite utiliser le même utilisateur MySQL sur les bases des sites mutualisés (plutôt que de créer un utilisateur par base à chaque création de nouveau site). Cet utilisateur étant préexistant.

    L’installation plantait systématiquement après la création de la base, au moment de créer les tables, en déclarant que la connexion à la base était impossible. On se retrouvait avec un utilisateur MySQL déclaré comme opérant depuis le serveur MySQL (user@serveur_mysql), alors qu’il aurait du l’être depuis le serveur Apache (user@serveur_apache). Dans mon cas c’était user@IP_du_serveur_apache vu que l’utilisateur est unique pour tous les noms de domaines (même ceux qui n’existent pas encore).

    En clair : la connexion avec root fonctionne bien, elle crée la base, crée un utilisateur (alors qu’elle devrait juste ajouter des droits à l’utilisateur existant) et dès que ce nouvel utilisateur est utilisé -> connexion impossible.

    Finalement, en commentant la ligne 157 du fichier mutualiser_creer.php « define (’_INSTALL_HOST_DB_LOCALNAME’, _INSTALL_HOST_DB) » et en initialisant _INSTALL_HOST_DB_LOCALNAME avec l’IP du serveur Apache tout rentre dans l’ordre.

    Je sais pas si c’est très clair :) mais il me semble qu’au lieu d’affecter directement la valeur la ligne 157 devrait le faire uniquement dans le cas ou _INSTALL_HOST_DB_LOCALNAME n’est pas défini.

    Evidemment ça fonctionne bien tel quel sur les environnements de développement (testé sur WAMP et MAMP) puisque tous les serveurs sont sur la même machine (localhost).

    • Le 19 octobre 2009 à 15:28, par Fil En réponse à : mutualiser_creer.php

      @philip : tu n’as pas besoin de commenter la ligne en question pour ajouter ton propre

      define (’_INSTALL_HOST_DB_LOCALNAME’, '...');

      un peu en amont dans le fichier qui définit tes paramètres de mutualisation.

    • Le 19 octobre 2009 à 15:56, par philp En réponse à : mutualiser_creer.php

      J’ai fait ce dont tu me parles dès le début.

      La solution a consisté à commenter la ligne 157 du fichier mutualisation/mutualiser_creer.php « define (’_INSTALL_HOST_DB_LOCALNAME’, _INSTALL_HOST_DB) » et en initialisant _INSTALL_HOST_DB_LOCALNAME avec l’IP du serveur Apache dans le fichier /config/mes_options.php.

      J’ai perdu plusieurs heures là-dessus, ce n’est pas une situation simple, merci de bien lire mon message :) ...

      Voici le contenu du fichier mes_options.php :

      $TLD=« domaine.ext » ;

      $site = str_replace(’www.’, ’’, $_SERVER[’HTTP_HOST’]) ;
      if ($site != $_SERVER[’HTTP_HOST’])
      include_spip(’inc/headers’) ;
      redirige_par_entete(’http://’.$site.’/’) ;
      else $site = str_replace(’.’ . $TLD, ’’, $site) ;

      define (’_INSTALL_HOST_DB’, ’nom_serveur_mysql’) ;
      define (’_INSTALL_HOST_DB_LOCALNAME’, ’IP_serveur_apache’) ;
      define (’_INSTALL_USER_DB_ROOT’, ’root’) ;
      define (’_INSTALL_PASS_DB_ROOT’, ’root_passwd’) ;
      define (’_SITES_ADMIN_MUTUALISATION’, ’’) ;
      define (’_INSTALL_SERVER_DB’, ’mysql’) ;
      define (’_INSTALL_TABLE_PREFIX’, ’spip’) ;
      define (’_INSTALL_NAME_DB’, ’toto_’ . prefixe_mutualisation($site)) ;
      define (’_INSTALL_USER_DB’, ’tata’) ;
      define (’_INSTALL_PASS_DB’, ’tutu’) ;
      define(’_PRIVILEGES_MYSQL_USER_BASE’,’Alter, Select, Insert, Update, Delete, Create, Drop’) ;

      demarrer_site($site,
      array(
      ’creer_site’ => true,
      ’creer_base’ => true,
      ’code’ => ’tagada’,
      ’url_img_courtes’ => true,
      ’creer_user_base’ => true,
      ’table_prefix’ => false,
      ’cookie_prefix’ => true,
      ’repertoire’ => ’sites’,
      ’mail’ => ’admin@spip.u-bordeaux4.fr’
      )
      ) ;

      Si je ne commente pas cette ligne, je me retrouve avec un utilisateur_mysql@serveur_mysql qui ne risque pas d’ouvrir de connexion, au lieu de l’utilisateur_mysql@serveur_apache attendu.

    • Le 19 octobre 2009 à 16:29, par Matthieu Marcillaud En réponse à : mutualiser_creer.php

      Il y a un truc qui m’échappe. Le défine que tu commentes est conditionné par le fait de créer un utilisateur pour la nouvelle base, or tu dis :

      on souhaite utiliser le même utilisateur MySQL sur les bases des sites mutualisés (plutôt que de créer un utilisateur par base à chaque création de nouveau site). Cet utilisateur étant préexistant.

      J’en conclus qu’il devrait y avoir ’creer_user_base’ => false, et non true ?

      Il est possible qu’il y ait un bug avec cette configuration que tu décris cependant, mais on devrait s’en sortir à coup de define(). Si c’est pas le cas, il faut corriger… mais commenter le code n’est peut être pas la meilleure correction :)

    • Le 19 octobre 2009 à 17:37, par philp En réponse à : mutualiser_creer.php

      Oui, mais d’après ce que j’ai compris du code et les essais que j’ai faits, si je mets ’creer_user_base’ => false j’obtiens « La connexion à la base de données a échoué. » à l’étape 1 « Connexion à votre base de données », avec la nouvelle base créée et vide...

      Le ’creer_user_base’ => true me permet de passer dans le code qui ajoute les droits MySQL à l’utilisateur unique (qui ne doit pas être root) sur la base nouvellement créée.

      En utilisant la version actuelle de mutualiser_creer.php je me retrouve avec un nouvel utilisateur créé sur le serveur MySQL, qui porte le même nom que _INSTALL_USER_DB mais au lieu d’être @le_serveur_http il est @le_serveur_mysql, et évidemment ça ne peut pas fonctionner.

      J’avais commenté la ligne pour tester, et maintenant je pense qu’il faudrait mettre à la place quelque-chose comme

      if (!defined(’_INSTALL_HOST_DB_LOCALNAME’))
      define (’_INSTALL_HOST_DB_LOCALNAME’, _INSTALL_HOST_DB) ;

      qui permettrait de pouvoir différencier le cas ou le serveur MySQL n’est pas le serveur HTTP : la création de nouveau site fonctionnait sans modification avec la configuration de mes_options.php donnée précédemment sur l’environnement de développement ou serveur_MySQL = serveur_HTTP = localhost, le problème est apparu lorsque je l’ai essayée « en vrai », ou le serveur MySQL n’est pas le serveur HTTP et ou on doit donner à l’utilisateur MySQL nommé utilisateur_MySQL@serveur_HTTP (le _INSTALL_USER_DB donc) les droits sur la nouvelle base du nouveau site Spip.

      Sans modif du code, on se retrouve avec les droits de utilisateur_MySQL@serveur_HTTP inchangés, et un nouvel utilisateur_MySQL@serveur_MySQL ayant les droits sur la nouvelle base, mais inutilisable puisqu’on va s’en servir pour se connecter depuis serveur_HTTP...

      Avec modif, on obtient une mise à jour des droits de utilisateur_MySQL@serveur_HTTP, lui donnant les droits nécessaires sur la nouvelle base.

      Bon, d’accord, ce qui m’arrive n’est pas facile à expliquer :) ...

    • Le 19 octobre 2009 à 18:34, par Matthieu Marcillaud En réponse à : mutualiser_creer.php

      La correction proposée est tout aussi inutile, en théorie, que la première.

      if (!defined(’_INSTALL_HOST_DB_LOCALNAME’))
      define (’_INSTALL_HOST_DB_LOCALNAME’, _INSTALL_HOST_DB) ;

      Comme disait Fil, cela revient à laisser tel quel mutualiser_creer.php et à définir un define(’_INSTALL_HOST_DB_LOCALNAME’, ’serveur’) ; dans le mes_options.php du SPIP (avant l’appel à demarrer_site() donc).

      Si cela ne fonctionne pas, c’est que le problème est ailleurs.

      Par ailleurs aussi, le fait de mettre « creer_user_base = true » alors que ça ne semble pas répondre à votre besoin - si je comprends un peu - est ennuyeux. Peut être faut il ajouter une option « ajouter_user_base » (ou un meilleur nom) qui ne ferait qu’ajouter la permission à un utilisateur existant ?

    • Le 20 octobre 2009 à 13:51, par philp En réponse à : mutualiser_creer.php

      Tout ce que je peux dire c’est que par défaut je me retrouve avec une création du même nom d’utilisateur depuis un hôte portant le nom du serveur MySQL, et que ça ne fonctionne pas !

      Mais bon, ici le DNS est parfois un peu bizarre. Peut-être est-ce l’explication...

      Quoi qu’il en soit, « ajouter_user_base » correspond effectivement à ce j’ai besoin de faire : si vous pouviez étudier cette possibilité dans une future évolution ça éviterait de demander à chaque fois la création d’un utilisateur qui existe déjà, et c’est peut-être aussi ça qui me crée des problèmes.

      J’en sais rien en fait. L’essentiel pour moi étant d’obtenir le résultat recherché dans le temps imparti, je vais me contenter de ça pour l’instant jusqu’à ce que la cause de ce bronx soit isolée.

      Merci en tous cas pour votre disponibilité, et pour ce développement qui permet de voir plus grand.

    • Le 20 octobre 2009 à 18:15, par marcimat En réponse à : mutualiser_creer.php

      J’ai beau regarder le code, je vois pas où ça pourrait coincer.
      « creer_user_base » sous MySQL remplit bien ce que vous attendez : la requête SQL semble la même si on ajoute un utilisateur à une bdd que si on « crée et ajoute » un utilisateur à une bdd. Les define paraissent corrects également et devraient définir un « user@ip » que vous attendez SI le define est indiqué avant. Je ne vois pas ce qui pourrait clocher dans la mutu et ce que vous avez fait. C’est étrange.

    Répondre à ce message

  • Le 10 avril 2009 à 16:11, par Maxwell En réponse à : Ferme à SPIP

    il doit le faire automatiquement
    Quant tu va apeller le site http://www.tartenpion.org il va te créer les dossier manquant dans sites/ tartenpion / et quand tu va faire http://intranet.tartenpion.org il va te créer les dossier manquant dans sites/ intranet.tartenpion /
    mais si tu veux faire des sites http://www.tartenpion.org/intranet c carement autre chose

    C’est bon j’ai réussi à faire ce que je voulais !!Ca marche quand je fais http://serveur/spip/intranet ou http://serveur/spip/internet avec la creation des tables utilsant le prefixe intranet et internet.
    J’avais un gros souci avec le fichier mes_options.php.En fait je voulais faire de la mutualisation de répertoire.
    Merci beaucoup de m’avoir aidé :D

    • Le 13 août 2009 à 10:56, par Christophe Sevin En réponse à : Ferme à SPIP : mutualisation de répertoire

      Bonjour Maxwell,

      Si tu as réussi à faire de la mutualisation de repertoire avec SPIP 2.0, peux tu faire une contrib qui explique ou bien indiquer les contribs qui t’on été utiles pour le faire car j’aimerais faire la même chose mais je rencontre des difficultés.

      Merci.

    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

  • Diaporama responsive avec Nivo Slider

    15 septembre 2015 – commentaires

    Un diaporama responsive basé sur « Nivoslider ». Introduction Cette contribution est une adaptation liée à Nivo-Slider (http://contrib.spip.net/Nivo-Slider-3747). Ce dernier plugin disponible n’étant pas responsive, nous l’avons refait une adaptation (...)

  • Mon site affiche une page blanche ou je ne peux plus accèder à l’espace privé

    7 février 2008 – 32 commentaires

    Au secours ! « Tout à coup » votre site devient inutilisable ou inaccessible ! Comment faire ? Pourquoi ? Par où commencer ? Sans pouvoir couvrir tous les cas, cet article va essayer de vous guider rapidement vers la (...)

  • Polyhiérarchie

    14 juillet 2009 – 166 commentaires

    Ce plugin permet de rattacher un article ou une rubrique à plusieurs rubriques parentes.

  • Étiquettes

    18 avril 2008 – 80 commentaires

    Générer des formulaires pour ajouter facilement des mots-clés à tout et n’importe quoi.

  • Formidable, le générateur de formulaires

    23 janvier 2012 – 2278 commentaires

    Un générateur de formulaires facilement configurable pour les non-informaticiens et facilement extensible pour les développeurs. Introduction L’objectif était de créer un plugin permettant de générer des formulaires. Historiquement, 2 plugins (...)