Dans le cadre de la refonte de mon SiteBlogPortfolio, j'ai été amenée à défaire un WordPress multisite pour le transformer en WordPress « normal ».
Je n'ai trouvé aucun tutoriel en français, et, même si j'ai pu me débrouiller à l'aide de quelques tutos en anglais, je me suis dit que ça ne serait pas du luxe d'expliquer comment j'ai fait dans la langue de Simone de Beauvoir.
Ma configuration de base
- Mon site repose sur un WordPress multisite que j'ai installé en 2010. À l'époque, je trouvais que c'était une idée de génie de séparer en plusieurs « sites » les différentes catégories de mon site. Un site « blog », un site « portfolio », un site « CV », etc. En effet j'avais alors un design complètement différent pour mon portfolio, pour mon blog et pour mon CV, et je me disais que ça serait plus simple de gérer chaque site depuis la même installation WordPress, et non plus en leur consacrant un nom de domaine chacun. (Je n'étais alors pas du tout dans un esprit d'unification graphique, mais voyais uniquement le soit-disant aspect pratique de la chose.)
- J'ai configuré trois « sous-sites » sur mon WordPress multisite :
- un pour mon blog (ID 2) ;
- un pour mon portfolio (ID 3) ;
- et un pour mon CV (ID 6).
- J'ai un hébergement mutualisé chez OVH.
- Je veux installer un WordPress normal en local, en y récupérant toutes les infos de mon WordPress multisite.
N.B. : les ID ne sont pas 1, 2 et 3 car j'avais fait mumuse, ce qui nous donne donc les IDs 2, 3 et 6. Je le précise car ça sera utile pour plus tard.
Le problème
Tout ça était bien joli, mais me posait plusieurs problèmes. D'une part, je trouve que le multisite a énormément ralenti les performances de mon site. Alors que jusque-là mon blog s'affichait dans un temps normal, il mettait des plombes à charger depuis que j'avais activé le multisite. Ça, ça avait tendance à m'énerver.
Mais surtout, au fur et à mesure qu'avançait ma réflexion sur la refonte de mon site et l'unification de ma charte graphique, et après deux ans de maniement du multisite, je me suis rendue compte que ce que j'avais imaginé être plus simple était devenu en fait une grosse machine à gaz ! Par exemple, pour installer un plugin, il faut passer par le tableau de bord du site principal, et non par le tableau de bord de chaque sous-site. Idem pour mettre à jour un thème ou un plugin. Idem pour mettre à jour un thème. Etc., etc. Au quotidien, ça ne me convenait pas.
Clairement, j'avais installé un WordPress multisite pour de mauvaises raisons : je pensais qu'il serait ainsi plus simple de gérer trois sites différents. Et puis, j'admets que la nouveauté du multisite à l'époque m'avait aussi donné envie de tâter la bête ! (Pour l'anecdote, mon tutoriel sur l'installation d'un WordPress multisite est l'article le plus commenté de mon blog.)
Ce que je veux obtenir
Sur le même nom de domaine où est déjà installé WordPress multisite, je veux désinstaller ce multisite, y installer un WordPress « normal » (c'est à dire pas multisite), et y transférer toutes les données de mon site actuel.
Allez, c'est parti !
N.B. : ce tutoriel part du principe que vous avez configuré votre machine pour travailler en localhost.
Désinstaller WordPress multisite
Première étape : une sauvegarde minutieuse
Premièrement, sauvegardez minutieusement votre WordPress multisite.
On ne le dira jamais assez ! J'insiste car j'en connais qui font leurs mises à jour WordPress sans backup, hein. Oui, j'ai les noms.
Si jamais une étape se passe mal, une sauvegarde fraîche et complète vous permettra de rétablir votre site à son état initial, ou bien de récupérer les données ou les fichiers manquants.
- Sauvegardez votre site via FTP : ne lésinez pas sur les dossiers et les fichiers à télécharger. Je vous conseille de tout télécharger pour avoir l'esprit tranquille. Veillez en particulier à vérifier que votre dossier
wp-contenta bien été téléchargé en intégralité, c'est important pour les images. - Sauvegardez votre base de données :
- chez OVH, connectez-vous à votre manager ;
- sélectionnez votre site dans la liste des « produits à configurer » ;
- allez dans la rubrique « Hébergement » ;
- cliquez sur l'item « Gestion SQL » ;
- cliquez sur l'item « Sauvegarde ».
Vous recevrez un email dans les minutes suivantes, contenant un lien de téléchargement unique avec les identifiants vous permettant de récupérer votre fichier .dump. Téléchargez immédiatement ce fichier (le lien n'est valide que quelques heures), et gardez-le sur votre machine, à portée.
La partie facile : les fichiers WordPress
Je stocke mes sites en local dans mon dossier « Sites » (je suis sous Mac). Quel que soit le dossier qui sert de répertoire principal à votre localhost, créez-y un dossier du nom de votre site (tout attaché, le nom, hein). Par commodité, je vais prendre comme exemple le dossier « MonSite » dans la suite de ce tutoriel.
- Dans le dossier « MonSite », donc, copiez tous les fichiers que vous avez sauvegardés via FTP. Ainsi, votre dossier « MonSite » doit contenir exactement les mêmes fichiers que ceux qui se trouvent à la racine de votre hébergement ;
- Ouvrez ensuite le fichier
wp-config.phplocal :- Modifiez les paramètres de connexion à votre base de données en local : à ce point-là, si vous affichez votre site en local, il doit s'afficher comme sur Internet. Si ce n'est pas le cas, vérifiez les paramètres de connexion à votre BDD locale ;
- Enfin, supprimez les lignes suivantes :
define('WP_ALLOW_MULTISITE', true);
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'url.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
define( 'SUNRISE', 'on' );
À ce point-là, vous avez cassé WordPress multisite :-) Votre site en local ne s'affiche pas, et c'est normal : pas de panique, la manipulation n'est pas terminée.
Les images
WordPress multisite stocke un peu différemment les images qu'un WordPress normal :
- WordPress par défaut stocke tous vos uploads (images, vidéos, etc.) dans le dossier
wp-content/uploads; - WordPress multisite, lui, les stocke dans le dossier
wp-content/blogs.dir/x, oùxcorrespond à l'ID de chacun de vos sous-sites.
Pour remettre en route le fonctionnement normal de WordPress, il va donc falloir déplacer le contenu du dossier wp-content/blogs.dir/x vers wp-content/uploads. Comme vous avez un WordPress multisite, normalement le dossier uploads n'existe pas dans le dossier wp-content : créez-le à la main.
La partie délicate : la base de données
Rien ne fonctionne sur votre nouveau WordPress « démultisité » : c'est normal. Il faut maintenant s'attaquer à la base de données !
La base de données d'un WordPress multisite se divise en deux grandes parties :
- Les tables communes au site principal et aux « sous-sites » ;
- Les tables spécifiques à chaque « sous-site ».
Supprimer les tables spécifiques à WordPress Multisite
Dans votre base de données locale, supprimez les tables suivantes, qui sont spécifiques à WordPress multisite et dont vous n'avez plus besoin :
- wp_blogs
- wp_blog_versions
- wp_registration_log
- wp_site
- wp_sitemeta
- wp_signups
- wp_sitecategories (si elle est présente).
Transférer les tables spécifiques aux sous-sites vers les tables générales de WordPress
Il s'agit maintenant de transférer le contenu des tables spécifiques à chaque sous-site dans les tables générales de WordPress. (N'aie pas peur, mon petit canard. Ça va bien se passer.)
Par exemple, mon WordPress multisite à moi repose sur toutes ces tables :
Si on y regarde de plus près, on distingue bien les tables propres à chaque « sous-site », préfixées par une chaîne de type wp_ID_. Celles qui m'intéressent en particulier sont celles qui concernent mon blog (qui a l'ID 2, et dont les tables spécifiques commencent donc par wp_2_).
En effet, c'est dans mon blog que j'ai publié des billets et des liens. Je n'ai quasiment pas utilisé les deux autres « sous-sites » que j'avais créés, n'ayant pas eu le temps de m'en occuper et n'étant pas sûre de conserver le format multisite. Voilà pourquoi, dans mon cas, je ne vais pas m'occuper des sites 3 et 6 (d'ailleurs le site ID 6 n'a même pas de tables, c'est vous dire…).
Il va donc falloir transférer le contenu de la table wp_2_posts vers wp_posts, et ainsi de suite, pour toutes les tables commençant par wp_2_ ; ainsi que, si c'est votre cas, toutes les autres tables spécifiques aux autres sous-sites vers les tables générales de WordPress.
Comme je n'avais qu'un seul sous-site à transférer vers le site principal, je n'y suis pas allée par quatre chemins : j'ai simplement vidé les tables principales, et les ai re-remplies avec le contenu des tables spécifiques de mon blog.
Évidemment, c'est une méthode empirique qui fera hurler les puristes : je serais heureuse de savoir comment les pros du SQL font, alors n'hésitez pas à détailler votre propre méthode dans les commentaires ! ;-)
Remplacer l'URL des images dans les articles et les pages
Rappelez-vous : nous avons déplacé toutes nos images dans le dossier wp-content/uploads, puisque c'est là que WordPress range tous les uploads, et qu'il s'attend à trouver toutes vos images hors WordPress multisite.
Seulement, le contenu de vos billets et de vos pages n'est pas à jour, lui, et continue pour le moment à appeler des images stockées dans wp-content/blogs.dir/x.
Pour simplifier, disons que vous avez besoin que toutes les URLs de type ancienne-url.com/files/ soient remplacées par nouvelle-url.com/wp-content/uploads/.
Il va donc falloir procéder à un petit chercher/remplacer dans la base de données. Là, c'est le Codex qui nous aide à trouver la requête SQL qui va bien, à savoir :
UPDATE wp_posts SET post_content = REPLACE(post_content,'ancienne-url.com/files/','nouvelle-url.com/wp-content/uploads/');
Cette requête veut dire : « mets à jour la table wp_posts en remplaçant dans le champ post_content toutes les occurences de ancienne-url.com/files/ par nouvelle-url.com/wp-content/uploads/ ».
À vous d'adapter ces deux URLs en fonction de vos propres URLs. Vous pouvez aussi modifier le nom de la table dans laquelle il faut procéder à ce remplacement – bien qu'en théorie, vous ne devriez pas avoir inséré d'images de votre site ailleurs que dans vos articles ou vos pages.
Les catégories WordPress n'apparaissent plus dans le tableau de bord
Dans l'ensemble, ma désinstallation de WordPress multisite au profit d'un WordPress normal s'est correctement passée, mais j'ai quand même rencontré un problème encore non élucidé.
Après avoir transféré le contenu des tables spécifiques wp_2_terms, wp_2_term_relationships et wp_2_term_taxonomy rétrospectivement vers les tables générales wp_terms, wp_term_relationships et wp_term_taxonomy, la liste de mes catégories WordPress s'affichait de manière incomplète dans mon tableau de bord.
J'ai donc recommencé l'opération plusieurs fois, en me disant qu'il y avait peut-être eu un timeout ou un problème quelconque qui aurait empêché le transfert de se dérouler correctement. Que nenni : après vérification attentive, le contenu des tables avait bel et bien été copié sans souci. Je n'ai pas réussi à identifier le problème.
Ce qui a remis les choses dans l'ordre, ça a été de créer une nouvelle catégorie factice via le tableau de bord : dès qu'elle a été créée, toutes les autres catégories ont réapparu comme par magie. Je n'avais plus donc qu'à supprimer la catégorie factice.
Déménager un WordPress, c'est l'occasion de vérifier à quel point <?php home_url('/'); ?> (alias <?php bloginfo('url'); ?>) est utile. Il ne faudrait jamais utiliser d'URL en dur dans WordPress, justement pour des raisons de compatibilité, et pour éviter les liens brisés sur le nouvel hébergement ! (Lire la doc à ce sujet.)
Voilà ! J'espère que ce tutoriel vous aura aidé, et présenté des pistes pour votre propre configuration. N'hésitez pas à poser vos questions dans les commentaires, et à partager les problèmes que vous auriez rencontrés ainsi que les solutions trouvées, pour que cela bénéficie à tout le monde ! Les commentaires sont désormais fermés, car je n'ai hélas plus le temps de fournir du support sur WordPress.
Quelques liens utiles :
- Downgrade Multisite to regular wordpress
- Bien que cela n'ait pas été mon cas, cela peut vous servir : Déménager un WordPress multisite vers une nouvelle URL (en anglais)
1 novembre 2012
Bonjour Marie,
Personnalisation de votre header, pas mal du tout et l'article également ...
j'ai eu la même blague pour un client qui voulait deux langues, le français et le néerlandais, j'avais donc jugé génial de partir sur un WPMU et de faire avec deux blogs. Mais j'ai eu un problème, il est peu probable que l'on puisse mettre deux langues différentes sur un WPMU et du coup certains termes restaient en anglais, ce qui ne plaisait pas au client.
Donc j'ai installé dans un répertoire NL une autre installation avec son fichier en néerlandais, et pour la version FR j'ai un MU non utilisé et avec des soucis pour certains plugins ... donc ton article arrive à point pour le remettre en mode normal :)
Je me demande quand même si il ne serait pas plus simple "d'exporter" les données du blog, de supprimer carrément l'installation, réinstaller une version normale propre et réimporter les données ?
Amicalement
Patrick
2 novembre 2012
Bonjour Patrick,
Bienvenue par ici, et merci pour votre commentaire =)
En effet, c'est une solution ! J'ai songé un temps à utiliser cette méthode (aaah, l'attrait d'une installation WP fraîche…), mais en fin de compte, j'allais de toute façon réinstaller exactement les mêmes plugins, les mêmes thèmes, avoir besoin des mêmes images, et des mêmes contenus… En outre, ma version de WordPress était déjà à jour.
L'avantage de copier les fichiers WP du site multisite existant dans le nouveau dossier, c'est qu'on zappe du coup la phase où on doit rechercher et réinstaller tous ses plugins et thèmes préférés.
Je n'ai donc pas vu l'intérêt immédiat de partir plutôt sur un WP neuf, plutôt que récupérer le WP existant qui était bien configuré et à jour.
Maintenant, si vous optez pour cette méthode, je serais bien entendu très intéressée d'avoir vos retours !
Bon courage :-)
NB : il existe un plugin réputé pour créer un WordPress multi-langues, c'est WPML. Cela pourrait peut-être simplifier votre projet.
2 novembre 2012
Bonjour Marie,
j'ai entendu parler de WPML mais à l'époque, j'étais dans mon trip WPMU la solution à (presque) tous les problèmes :)
Pour la réinstallation d'une liste de plugins, je me sers d'un plugin, plugin central, on peut lui donner une liste et il installe le tout.
Pour mon cas, le site n'est pas très fréquenté, donc je n'ai pas encore de problèmes pour le moment, et la méthode que je vais appliquer avant de me lancer dans la conversion, c'est "wait an see" :)
bien belle journée
Amicalement
Patrick
2 novembre 2012
salut,
@Patrick :
WPML c'est très ien mais cela devient cher.
La solution la plus solide reste encore de faire deux sites avec 2 WordPress mais c'est un sacré taf !
WPMU est idéal pour le multilingue. Ce qu'il faut bien faire c'est le développement de ton thème en utilisant bien les _e() et __(), notamment dans tes templates à chaque fois que tu prévois une traduction. Cela requiert une certaine organisation pour ne pas faire d'erreur.
En fait, cette solution est très bien, si tu l'utilises au départ de ton projet et si ton projet est pas trop gros pour WordPress. Très pratique quand tu commences à avoir 3 ou 4 langues : une seule installation. Et puis après y a plus qu'à dupliquer ton blog, notamment certaines tables de ta BDD. Tu gagnes environ une moitié de boulot et surtout c'est moins chiant. Perso, je n'ai jamais eu de blem.
Après si cela ne te convient pas, tu as bien raison de ne pas continuer avec.
Si t'es curieux et que tu lis l'anglais, j'ai fait un petit tuto : http://tinyurl.com/bp4xvoz
@marie :
Oh que oui. Malheureusement, on l'apprend souvent à nos dépends et puis bah on ne recommence plus >> certains appellent cela l'expérience.
Pour ma part, je considère qu'avoir à désinstaller WPMU ne peut se produire que par accident (comme ici) ou par négligence dans le choix des outils au moment de la création du site.
Au moment de l'installation, il y a quand même deux fois le même message qui te dit en gros "j'espère que tu sais ce que tu fais, c'est une manip délicate".
Bien souvent les gens ne lisent pas la doc qui accompagne et se lancent dans WPMU à tort.
En revanche, je trouve dommage de proposer des outils dont l'installation est définitive ou presque. Merci de partager en français ta solution.
2 novembre 2012
Bonsoir Jmlapam,
En final, si je devais refaire un site multilingues, je ferais des installations séparées et je les gérerais avec IWP qui est un script installé sur un hébergement et qui permet de gérer depuis une interface tous les WP que tu configures, mises à jour de wp, thème et plugins sont faits en un click, ainsi que les backups.
Vais allez voir ton tuto :)
Amicalement
Patrick
2 novembre 2012
Bonjour,
En lisant votre article, je viens de prendre conscience que je ne faisait pas de sauvegarde correcte de mon blog, ne sauvegardant que les fichiers WP et pas la base (je pensais naïvement que la base était quelque part dans le répertoire sauvegardé, c'est dire mon ignorance) ; merci, donc, pour cette prise de conscience (je ne comprends pas très bien où est cette base, et pourquoi elle n'est pas accessible via le ftp pour la sauvegarde, mais c'est une autre histoire)...
Par ailleurs, j'ai un problème qui tourne autour du multisite pour lequel vous pouvez peut-être apporter vos lumières : j'ai un hébergement 240plan chez OVH, et je désirerais avoir deux sites WP indépendants, avec une gestion indépendante et... je ne sais pas trop comment faire, et quelles sont les répercussions.
- Pour ce qui est du paramétrage des DNS et de la gestion multisite chez OVH, pas de pb, ça fonctionne.
- Pour WP, je pensais (bêtement) que je pouvais installer avec le manager deux modules WordPress dans deux répertoire, et basta... mais cette histoire de base dissociée des répertoire WordPress me fait subodorer que ça ne va pas peut-être pas se passer aussi simplement... J'ai vu que dans le mode avancé de l'installation des modules, on pouvait choisir une nouvelle base, mais je ne sais pas trop si c'est cela qu'il faut faire. Avez-vous une idée sur la question ?
Cordialement
Jean-Louis
2 novembre 2012
Bonjour,
Je zieute wp_post et je vois qu'il y a des tas d'url dans la colonne guid, aussi je me demande si en plus de :
UPDATE wp_posts SET post_content = REPLACE(post_content,'ancienne-url.com/files/','nouvelle-url.com/wp-content/uploads/');
Il ne faut pas faire aussi :
UPDATE wp_posts SET guid= REPLACE(guid,'ancienne-url.com/files/','nouvelle-url.com/wp-content/uploads/');
Cordialement
Jean-Louis
2 novembre 2012
Bonjour Jean-Louis,
Bienvenue par ici et merci pour vos commentaires !
La base de données est une sorte de répertoire virtuel dans lequel sont stockées les données SQL de votre site (disponibles en général via PHPMyAdmin), générées par ses fichiers PHP (disponibles par FTP). Ce sont en effet deux choses différentes, qui sont à la base du fonctionnement de WordPress.
Il faut penser à faire une sauvegarde des deux volets (SQL + PHP) pour sauvegarder efficacement votre WordPress !
Oui c'est possible, mais dans ce cas vous ne faites plus du WordPress multisite : vous allez avoir deux installations WP dissociées, totalement indépendantes l'une de l'autre.
Pour gérer plusieurs sites avec LA MÊME installation de WP (= une seule installation), alors oui il faut partir sur la base d'un WP multisite, c'est ce que je décris dans ce tutoriel-là.
Tout dépend de votre installation actuelle : si vous n'avez pas encore créé vos sites, cela sera très facile de configurer un WP multisite. Si vous avez déjà plusieurs installations différentes de WP que vous souhaitez réunir en UNE SEULE installation WP multisite, oui, c'est plus délicat : c'est la marche à suivre que je détaille plus haut.
Aucune idée, je ne comprends pas bien de quoi il s'agit ! Dans le langage WordPress, un module est égal à un « plugin » en anglais, et leur installation ne requiert pas de choisir une base de données puisqu'ils s'installent sur la même base de données que celle où WP est installé.
La seule étape où l'on doit effectivement choisir une base de données, c'est pendant l'installation initiale de WP, étape qui n'est à effectuer qu'une seule fois.
2 novembre 2012
Bonjour,
J'ai suivi la démarche de suppression des tables spécifiques :
wp_blogs
wp_blog_versions
wp_registration_log
wp_site
wp_sitemeta
wp_signups
wp_sitecategories (si elle est présente).
Et j'ai désormais un magnifique message d'erreur :
"Erreur de connexion à la base de données...
Nous avons cherché la table wp_blogs dans la base de données
What do I do now? Lisez la page de gestions des bugs (en anglais). Certaines des bonnes pratiques qui y sont présentées pourraient vous aider à comprendre ce qui a mal tourné. Si vous êtes toujours bloqué par ce message, vérifiez alors que votre base de données contient bien les tables suivantes :
wp_users
wp_usermeta
wp_blogs
wp_signups
wp_site
wp_sitemeta
wp_registration_log
wp_blog_versions
Avec l'impossibilité de se connecter à l'interface d'administration + disparition du site "Erreur de connexion à la base de données"
Au secours...
2 novembre 2012
Bon ben apparemment, c'est parce que je n'avais pas mis "false" à la place de "true" dans "define( 'MULTISITE', true );"
Je ne l'avais fait qu'à la première ligne.
Dsl pour le dérangement.
2 novembre 2012
Petite MAJ le tuto dont je parlais dans un précédent commentaire est dispo à cette adresse : http://tinyurl.com/cnh2km5
C'est pour éviter à ceux que cela intéresse de tomber sur une 404.
2 novembre 2012
@Fred : oui il faut bien suivre le tuto en entier.
@Jmlapam : merci pour l'info :)
15 janvier 2013
Bonjour,
Avec WP 3.5 et avec un seul site installé sur le multisite passer de ça dans le wp-config :
define('WP_ALLOW_MULTISITE', true);define( 'MULTISITE', true );
A ça
define('WP_ALLOW_MULTISITE', false);define( 'MULTISITE', false );
Puis réactiver tous les plugins dans l'admin classique semble suffisant.
Je viens de tester et tout marche parfaitement, tous les réglages sidebar et plugins ont été sauvegardés.
26 janvier 2013
Bonjour Marie et merci pour le partage de vos connaissances.
Je viens de complètement bousiller un site multisite wp.
Longue histoire, j'avais engagé un coder pour le faire pour moi mais il n'avait réussit que partiellement. Donc j'ai mis la main à la pâte et j'ai tout bousillé.
Petite question à toi Marie: Offres-tu tes services pour remettre un wp MultiSite en régulier? Si oui, à combien pour un site de 4 sites en multisite?
Mario Bruneau
29 janvier 2013
Bonjour Mario,
Je suis bien désolée d’apprendre vos soucis techniques avec WordPress.
Je ne suis cependant pas en mesure d’offrir mes services, dans quelque domaine que ce soit.
Bon courage !
1 février 2013
Petit correctif suite à mon post du 15.01
Effectivement le site ainsi "downgradé" fonctionne parfaitement mais il semble que cela cause quelques soucis sur le serveur au niveau des redirections.
Donc avant d'en savoir plus, je déconseille la solution.
28 février 2013
Bonjour,
Tout est très bien expliqué et je me sentirais capable de tenter l'aventure du multisite mais je ne suis pas encore sûre qu'il s'agisse de la solution idéale en ce qui me concerne... alors je tente ma question de novice! J'ai depuis peu un blog que je tiens en francais et je souhaiterais l'avoir aussi en allemand en gardant la meme apparence et le nom en effectuant moi même les traductions. J'ai déjà cherché pas mal de temps et j'ai trouvé des infos qui me font hésiter entre la création d'un multisite et d'un sous-domaine. Pourriez-vous éventuellement m'expliquer concrètement les différences pour un blog bilingue et me donner votre avis? Je voudrais prendre la bonne décision!
Merci d'avance
Maude
3 mars 2013
Bonsoir Maude,
Un WordPress multisite te permet de gérer soit plusieurs sous-domaines (sousdomaine1.url.com et sousdomaine2.url.com par exemple), soit plusieurs dossiers (url.com/dossier1 et url.com/dossier2 par exemple), soit plusieurs noms de domaine (url1.com et url2.com par exemple).
Pour le coup c'est à toi de décider quelle solution est plus adaptée à tes besoins. Si ça peut t'aider, j'ai expliqué en détails comment installer un WordPress multisite avec l'option sous-domaines.
Pour avoir un site bilingue, je recommande un Multisite en sous-domaines, avec un thème unique, appliqué à tes deux sites, que tu auras internationalisé.
Bon courage ! :-)
6 mars 2013
Bonsoir Marie!
Merci beaucoup pour ta réponse, j’avais déjà selectionné ton tuto pour le faire si jamais il s’agissait de la marche à suivre la plus adaptée à mon cas. Tes explications sont très claires et accessibles même si on si connait très peu dans ce domaine! Je vais m’y mettre dés que j’ai le temps.
Bonne soirée et merci encore de nous faire partager ton savoir!
Maude
21 mars 2013
Je t'en prie ! :)
7 mars 2013
Avec WPMU multi langues il existe une solution très efficace, c'est d'utiliser le plugin Multi languages switcher avec des sites en sous-répertoires. Aucun problème de référencement, de duplicate content, bien au contraire la solution est considérée comme ad hoc dans la mesure où il s'agit d'une véritable traduction. Une condition limiter le nombre de langues à 3 ou 4. Quant à la lenteur de WPMU, je suis un peu réservé; il faut utiliser un serveur statique dans lequel on place le css, les js et les images. Ca peut être le même serveur mais il faut utiliser un nom de domaine différent. Avantage pour les images, on peut utiliser les mêmes images pour tous les sites, ce qui n'est pas très évident avec les 'blog dir'...
21 mars 2013
Bonsoir Alain,
Un serveur statique, c'est bien gentil, mais pas pour les particuliers comme moi qui n'ont pas le budget (ni l'usage hein). Héberger ses ressources sur un serveur statique n'est heureusement pas le seul moyen d'améliorer les performances d'un site web. Cela a un coût qui se justifie ans doute pour les sites à fort trafic, mais pas pour un site perso comme le mien.
Mouais, pas convaincue, ça crée surtout une requête DNS supplémentaire…
C'est faux. On peut tout à fait appeler une image du site 1 sur le site 2 avec WordPress multisite. Certes l'URL de l'image sera sans doute plus longue qu'avec une URL réécrite, mais encore une fois, attention aux requêtes DNS.
Le seul intérêt que je vois, c'est pour paralléliser les téléchargements. Mais bon, à moins que ton site appellent 15 JS, 48 images et 18 CSS, cela me semble overkill.
21 mars 2013
Bonjour Marie,
Je trouve votre site vraiment génial. J'ai cependant une préoccupation concernant le Multi Site. J'en ai conçu un en 2011, et j'y ai ajouté un plugin pour passer d'une langue à une autre. Jusque là pas de problème. Seulement il y'a quelques jours, un hacker nommé "SJ" est passé par là, "Heureusement" il n'a attaqué que le le noyau du site, celui là ou je pouvais créer du contenu, celui là ou je pouvais activer ou désactiver mes extensions et changer de thèmes. J'y ai plus accès. J'ai eesayé la méthode de création d'un administrateur via php my admin, seulement une fois fini, l'utilisateur en question n'a aucun droit!
pitié au secours!
21 mars 2013
Comme tu as fait des backups régulièrement de ton installation WordPress, tu n'auras aucun mal à tout désinstaller et à tout réinstaller proprement :-) À mon avis, le hack est dû à un plugin pourri pas assez solide en terme de sécurité, que le hacker a craqué sans problème. Donc je commencerais par faire du ménage à ce niveau-là, et à n'installer que des plugins réputés, bien notés sur le WordPress Plugin Directory, et j'éviterais d'installer n'importe quoi. Ce qui m'étonne c'est que tu connaisses les initiales du hacker.
Pour le reste, Google est ton ami : il y a pleins de pistes à suivre pour réparer un WordPress cracké comme le tien.
Bon courage :-)
20 janvier 2014
Et pourquoi ne pas directement donner comme "false" les paramètres multisite ?
22 janvier 2014
Jamais testé, mais à vue de nez je dirais que ça ne nettoiera pas votre base de données (qui contiendra des tables et des données inutiles), et que ça ne résout pas non plus la problématique du rappatriement des anciens sites enfants.
7 février 2014
Bonjour Marie,
merci pour ton tuto c'est exactement ce dont j'avais besoin. Je suis cependant un peu confuse car je n'ai pas exactement les mêmes lignes que toi dans le wp-config.php. J'ai ceci:
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'www.monnomdedomaine.fr');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
De plus mes photos sont déjà dans le wp-content/uploads et non pas dans le wp-content/blog.dir/x
J'avais installé cela pour avoir une version anglaise de mon blog que je n'utilise plus. http://www.monnomdedomaine.fr/en
J'ai déjà supprimé ce sous domaine '/en' des sites du réseau de wordpress mais je voudrais revenir à une version simple de wordpress et avoir tout propre. N'ayant pas la ligne "define('WP_ALLOW_MULTISITE', true);" j'ai peur d'avoir quelque chose d'autre qu'un multisite. Je ne comprends que peu tout cela.
Je pense alors que seulement supprimer le code des fichiers 'wp-config.php' et 'htaccess' la page 'création de réseau' de wordpress. Qu'en penses-tu?
N'arrivant pas à installer mon blog en local, j'ai peur d'essayer des manipulations directement en ligne.
Merci pour ta réponse.
Margot
7 février 2014
Salut Margot !
Bien qu'il me soit totalement impossible de t'aider à débuguer ton site à l'aveugle, je peux néanmoins te donner quelques conseils :
wp-config.php, il faut commenter les lignes que j'ai indiquées dans mon billet. C'est ça qui te permettra de retrouver un Tableau de bord « non multisite « (donc exit la page de « Création de réseau », que tu n'auras jamais à supprimer toi-même…). S'il te manque la lignedefine('WP_ALLOW_MULTISITE', true);, ça me semble bizarre car c'est la ligne-clé qui permet d'activer le multisite.Mon billet avait pour objectif d'expliquer comment désactiver un WordPress multisite ET de nettoyer sa base de données suite à ça. Il ne suffit pas de toucher à wp-config.php…
Bon courage ! :)
18 février 2014
Merci Marie pour ton message et ton aide.
Je pense que j'avais mal installé le multisite. J'avais le menu 'admin site' et des "sous-sites" mais je pense avoir fait des erreurs lors de la mise en place. En supprimant le code du fichier wp-config tout est redevenu à une configuration simple. Je n'ai pas eu besoin de nettoyer la base de données car il n'y a pas les dossiers que tu indiques dans ton tuto. Je ne suis pas sûr de ce que j'ai bien pu mettre en place et ce que j'ai supprimé mais cela fonctionne.
Je vais m'attaquer à l'installation de wordpress en local maintenant.
Merci pour tes tutoriaux et tes réponses rapide.
Bonne continuation!
18 février 2014
Super, je suis contente que tout soit rentré dans l'ordre.
À bientôt ! :)
6 avril 2014
Bonjour Marie,
Merci beaucoup pour ce tuto très bien fait et très utile ! Je viens de faire la manip sans encombres grâce à sa lecture.
Juste 2 petites précisions :
- concernant les images, les miennes sont aujourd'hui dans des sous-répertoires de .../uploads, par année puis mois; peut-être les évolution de WP depuis la mise en ligne du tuto ?
- la plupart des extensions ont été désactivées par la manip, il faut penser à les réactiver.
Merci encore !
6 avril 2014
Salut Christophe !
Mmm non, je n'ai pas précisé qu'elles étaient rangées dans des sous-dossiers triés par année et par mois, simplement parce que c'est une option à activer quand on configure WordPress.
Avant toute opération « sensible » sur une installation WordPress, il faut toujours désactiver ses plugins avant de faire quoi que ce soit. Tu as raison, je ne l'ai pas précisé dans mon billet, j'aurais dû !
Merci pour ton commentaire :)
28 juillet 2014
Très efficace, merci beaucoup !
La suppression du contenu de wp-config.php m'a suffit dans mon cas.
Bonne continuation!
28 juillet 2014
^.^
10 octobre 2014
Bonjour Marie et merci pour toutes ces indications précieuses...
J'ai malheureusement fais les frais d'un apprentissage par l'erreur (sans sauvegarde complète...) et me retrouve coincé bien qu'ayant suivi scrupuleusement tes indications.
Alors, chez moi, les images étaient bien restées dans le bon repertoire (wp-content/uploads) et sont donc restées accessibles mais tous les liens des pages et autres posts semblent avoir été perdus.
J'ai bien essayé dans phpmyadmin de les modifier manuellement mais rien n'y fait, je tombe toujours sur le 404...
Aurais-tu une idée, même vague?
Merci encore en tout cas pour ces tutos en français !!
12 octobre 2014
Bonsoir Marco !
Il m'est absolument impossible de t'aider à débuguer ton site à distance. Si tu as désinstallé WP multisite, logiquement l'URL de tes médias doit avoir changé aussi. Il faut donc la changer dans le corps de tes articles et de tes pages. Mais c'est un peu délicat. Le plugin Search and Replace peut peut-être t'aider.
Quoi que tu entreprennes, je n'insisterai jamais assez : fais une sauvegarde complète de ton site (FTP + SQL).
Bon courage !
29 janvier 2015
Bonjour Marie, super ce tuto.
J'ai 3 sites en multisite et je veux les séparer.
J'ai toutefois un soucis sur "Comme je n'avais qu'un seul sous-site à transférer......: j'ai simplement vidé les tables principales, et les ai re-remplies avec le contenu des tables spécifiques de mon blog.
Est-ce possible de savoir comment procéder, car je ne suis pas un grand spécialiste de MySql.
Merci !
11 février 2016
Bonjour,
Toujours content de retrouver ces articles pratiques, vécus instructifs et leurs commentaires en retour !
C'est vrai qu'il vaut mieux faire une sauvegarde complète avant toute modif ou mise à jour...
Toutefois depuis la version 3.7 -sauf erreur- WordPress se met à jour tout seul comme un grand, sans rien demander et vous avertit -au mieux- quand c'est fait ; tant pis si vous avez un plugin incompatible avec la nouvelle version et si ça crash ! (C'est du vécu..)
On peut toutefois dévalider toutes ces MAJ automatiques de WordPress en rajoutant dans le fichier wp-config.php :
define( 'AUTOMATIC_UPDATER_DISABLED', true );Qui bloque toutes MAJ.
On peut affiner, car il y a différents niveaux, en consultant le codex, le bien nommé : Mises à Jour Automatiques en Coulisses !
Cdlt,