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 tuto sur l’installation d’un WordPress multisite est l’article le plus lu, et le plus commenté de tout 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 ! :-)
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)
Patrick
27.07.12
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
Marie
27.07.12
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.
Patrick
27.07.12
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
jmlapam
28.07.12
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.
Patrick
28.07.12
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
Jean-Louis
2.09.12
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
Jean-Louis
4.09.12
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
Marie
9.09.12
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.
Fred
23.09.12
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…
Fred
23.09.12
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.
jmlapam
25.09.12
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.
Marie
28.09.12
@Fred : oui il faut bien suivre le tuto en entier.
@Jmlapam : merci pour l’info :)
ben jaafar
14.01.13
Bonsoir
J’adore votre header !! trop beau
Guillaume
15.01.13
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.
Mario
26.01.13
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
Marie
29.01.13
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 !
Guillaume
1.02.13
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.
Maude
28.02.13
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
Marie
3.03.13
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 ! :-)
Maude
6.03.13
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
alain
7.03.13
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’…
Roger Marcel
21.03.13
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!
Marie
21.03.13
@Maude : Je t’en prie ! :)
@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.
@Roger Marcel : 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 :-)