Bosser en local avec Wamp (update 2013 !)

  • Statut : non résolu
15 sujets de 1 à 15 (sur un total de 19)
  • Auteur
    Messages
  • #532215
    Comme une image
    Participant
    Maître WordPress
    2493 contributions

    Bonjour à tous,

    Pour différentes raisons (1/ mon PC a crashé 2/ j’ai dû m’occuper d’un site dont l’URL à changer 3/ je songe à donner un coup de frais à mon blog), j’ai ressorti du placard ma blouse et ma boîte à outils pour pouvoir tranquillement travailler sur le design de mes sites en local (indispensable si on veut faire les choses proprement) sur une installation Wamp 2 toute fraîche.

    NB : Les fichiers, programmes, … utilisés ici appartiennent au monde Windows. Vous trouverez sans peine les équivalents pour MacOS ou Linux, mais n’étant pas spécialiste, je préfère rester silencieux ici.

    Je ne rentrerai pas dans les détails du pourquoi ni du comment, vous trouverez sur la toile quelques tutos assez bien foutus. Mais il y a quelques “tweaks” pas forcément clairement expliqués que j’ai envie de partager avec vous.

    Avec une seule instance de Wamp, on peut bien sûr travailler sur plusieurs sites différents en local.
    * Il faut créer autant de base de données que nécessaire
    * Il faut configurer les différentes URL dans votre fichier hosts (j’y reviendrai) et dans votre fichier http-vhosts.conf

    Mon fichier ressemble à ça :


    DocumentRoot “d:/sites”
    ServerName localhost


    ServerAdmin webmaster@monsiteweb.fr
    DocumentRoot “d:sites/_gandi/vhosts/www.monsiteweb.fr/htdocs”
    ServerName http://www.site_en_local.fr
    ErrorLog “logs/site1.localhost-error.log”
    CustomLog “logs/site1.localhost-access.log” common


    ServerAdmin webmaster@deuxiemesite.fr
    DocumentRoot “d:/sites/_site2@online/www”
    ServerName http://www.site2_local.fr
    ErrorLog “logs/site2.localhost-error.log”
    CustomLog “logs/site2.localhost-access.log” common

    etc.

    ASTUCE 1 : faites en sorte que votre URL en local fasse la même longueur (même nombre de caractères) que l’URL réelle (j’y reviens plus tard)

    ASTUCE 2 : calez votre arborescence de fichiers en local au plus près de votre arborescence chez votre hébergeur (dans mon exemple : GANDI et ONLINE), ça simplifiera les synchronisations FTP (j’utilise filezilla)

    ASTUCE 3 : Soyez jusqu’au-boutiste ! Votre fichier wp-config.php doit être identique aussi… Ça veut dire qu’il vous faudra parfois ajouter dans votre fichiers hosts le nom de votre serveur MySQL quand ce n’est pas localhost.

    Exemple : sur OVH, il est probable que vous ayez un fichier wp-config.php de ce genre :

    define(‘DB_NAME’, ‘site1’);
    define(‘DB_USER’, ‘site1’);
    define(‘DB_PASSWORD’, ‘mOt2pAssE’);
    define(‘DB_HOST’, ‘mysql51-101.perso’);

    Du coup, dans votre fichier hosts vous allez mettre ceci :
    127.0.0.1 localhost http://www.site_en_local.fr mysql51-101.perso http://www.site2_local.fr (autres adresses locales…)

    NB : sur windows, le fichier se trouve généralement ici : C:WindowsSystem32driversetchosts
    NB : certains antivirus bloquent l’accès en modification à ce fichier. Si c’est le cas, désactivez-le le temps de l’opération

    Bien évidemment, quand vous créerez votre base MySQL en local, vous utiliserez le même nom d’utilisateur, avec le même mot de passe.

    2/ La meilleure façon pour mettre à jour une base de données entre un site en local et un site réel, c’est l’import/export SQL
    La méthode est la suivante :
    a) j’exporte la base depuis PhpMyAdmin sur le premier site (je prends soin de cocher la case “Ajouter un énoncé DROP TABLE…”)
    b) Je prends mon bon éditeur de texte (Notepad++)
    c) Je remplace globalement http://www.monsitereel.fr par http://www.monsitelocal.fr (ou inversement, selon le cas) sans me poser de question
    d) Je compresse au format .gz (indispensable surtout quand on commence à avoir un gros historique)
    e) j’importe le résultat sur l’autre site

    Jusqu’à présent, tout ça marchait du feu de dieu jusqu’à ce que je tombe sur un thème qui sauvegardait tous ses réglages en base de données et que je perde tout après l’opération.
    Que s’était-il passé ?! Eh bien le problème venait du fait que le nom de domaine n’était pas de la même longueur, et avec la sérialisation des données utilisée par WP, comme la longueur est indiquée, ça ne fonctionnait plus. C’est là que j’ai découvert un script démentiel qui m’a corrigé ça d’un coup de baguette magique :
    Database search and replace script in PHP

    Pour m’éviter cette opération, je prends soin désormais de travailler avec des URL de même longueur (NB : les méthodes basées sur le simple remplacement de deux options en base, c’est de la m…, utilisez la méthode Notepad++ !). Mais si vous n’avez pas le choix et que vous devez changer de nom de domaine, ce script est d’une efficacité redoutable.

    Une fois que toutes ces opérations sont faites, tout devrait marcher comme sur des roulettes sauf que
    LA PAGE DE UNE DE MON SITE S’AFFICHE BIEN MAIS TOUS LES ARTICLES TOMBENT EN 404

    Suivez bien ces 3 étapes :
    1/ Sauvegardez la structure de vos permaliens depuis l’admin (pour regénérer le fichier .htaccess)
    2/ Vérifiez que le module Apache mod_rewrite est bien activé (par défaut : non !)
    Menu Wamp / Apache / Apache modules / …
    3/ Vérifiez que vous avez bien dans le fichier httpd.conf (menu Wamp / Apache / httpd.conf)

    AllowOverride All
    Require all granted

    Par défaut, j’avais AllowOverride None

    Amusez-vous bien !

    #929703
    Comme une image
    Participant
    Maître WordPress
    2493 contributions

    Tiens, je viens de tomber sur une page qui détaille l’utilisation du script magique ! C’est chez Grégoire Noyelle

    #929704
    Flobogo
    Modérateur
    Maître WordPress
    15608 contributions

    Bonjour,

    Je travaille en local avec WAMP, j’ai plusieurs dossiers représentants des sites différents (l’un est la copie exacte de mon site, l’autre un site de test pour thèmes ou plugins, et le 3ème est un projet de nouveau site)
    Pourtant, je ne comprends rien à votre histoire de “fichier hosts” et “fichier http-vhosts.conf” : je n’ai rien qui ressemble à ça dans mon install’ :rolleyes:

    Sinon, il y a aussi le tuto de Luciole135 pour installer un site local et/ou utiliser le script search and replace db

    #929705
    Franck (fge)
    Modérateur
    Maître WordPress
    9583 contributions

    Pourtant, je ne comprends rien à votre histoire de “fichier hosts” et “fichier http-vhosts.conf” : je n’ai rien qui ressemble à ça dans mon install’

    Cela n’a rien d’obligatoire, cela permet de créer des serveurs virtuels dans Apache. De cette manière, au lieu d’avoir des sites sur son PC en http://localhost/Repertoire1 & http://localhost/Repertoire2 on peut y accéder directement avec une adresse comme http://www.monsitelocal1.fr & http://www.monsitelocal2.fr.

    #929706
    Flobogo
    Modérateur
    Maître WordPress
    15608 contributions

    OK, je comprends (enfin, je comprends le principe, pas comment faire) … et du coup, je comprends l’utilité si cela permet d’avoir le même nombre de lettres que le futur NDD pour éviter le problème des données sérialisées 🙂

    Mais bon, avec le script “search and replace db” il est (assez) facile de remplacer le nom du site local par celui du site en ligne, ou un nom de site A par un nom de site B, même de longueur différente … perso, ça me paraît plus accessible 😋

    #929707
    Comme une image
    Participant
    Maître WordPress
    2493 contributions

    Merci fge pour tes précisions ! Effectivement, l’intérêt majeur, c’est d’avoir une dans son navigateur une URL qui ressemble à celle d’un site publié… mais qui reste locale. C’est quand même plus joli.

    Je précise au passage qu’étant informaticien, je n’ai pas peur de retrousser mes manches pour aller regarder d’un peu plus prêt comment tourne la machine (toute la différence entre un ordinateur et une voiture pour moi :D) et que c’est à chacun de choisir le niveau de complexité/technicité qui lui convient. Déjà, travailler en local avec Wamp fait montre d’un excellent esprit !

    Le tuto de luciole135 est très bien, merci de l’avoir signalé ! Je sais qu’il y a pas mal de tuto sur la toile et mon propos n’était pas de les remplacer (loin de là) mais d’apporter quelques compléments.
    Le script de changement de nom dont parle luciole est le même que celui dont je parle. Mais c’est justement pour éviter d’avoir à y recourir (autant limiter les étapes) que je propose une astuce avec des domaines “iso-longueur”.
    De même que je donne une astuce pour éviter d’avoir à modifier wp-config.php.

    Bref, l’objectif est d’être le plus paresseux possible !!!

    #929708
    Franck (fge)
    Modérateur
    Maître WordPress
    9583 contributions

    Effectivement, l’intérêt majeur, c’est d’avoir une dans son navigateur une URL qui ressemble à celle d’un site publié… mais qui reste locale. C’est quand même plus joli.

    C’est vrai mais c’est un peu plus complexe à mettre en place (cela m’est arrivé de le faire mais en utilisant .loc comme “Top Level Domain” pour éviter les confusions avec le .com en ligne) pour qui n’est pas familier avec le fonctionnement des serveurs Apache.

    Par contre je n’ai jamais essayé d’aligner les fichiers de configuration. Je suis en revanche un peu surpris que tu n’aies pas besoin de changer de nom du serveur dans la configuration MySQL. Où c’est un oubli dans la procédure ?

    Je précise au passage qu’étant informaticien, je n’ai pas peur de retrousser mes manches pour aller regarder d’un peu plus prêt comment tourne la machine (toute la différence entre un ordinateur et une voiture pour moi big_smile)

    Je me sens moins seul 😆

    #929709
    Comme une image
    Participant
    Maître WordPress
    2493 contributions

    L’astuce du .loc est intéressante, moi j’ai opté pour la modification des premières lettres de l’URL à cause de la mémoire de la barre de navigation du navigateur…

    Dans wp-config, il y a 3 informations pour atteindre la base :
    1/ son adresse sur le réseau (souvent localhost, car le serveur MySQL est souvent sur la même machine que le serveur Apache)
    2/ le nom de la base
    3/ le login/password pour se connecter
    La modification du fichier hosts permet d’agir sur le point 1 et ça suffit (mySQL ne gère pas de “nom de serveur” à ma connaissance). Les points 2 et 3 s’adressent sur le serveur MySQL en créant la base pour accueillir les données du blog.

    #929710
    chezmat
    Participant
    Chevalier WordPress
    183 contributions

    Wamp, c’est bien avant de mettre le site en ligne, mais une fois en ligne, je pense qu’il est plus propre d’avoir également un site de test en passant par un sous-domaine. Cela nécessite d’avoir suffisamment d’espace disque en ligne et de pouvoir disposer d’une seconde base SQL.
    J’ai fait un tutoriel à ce propos :
    http://chezmat.fr/monter-site-de-test-wordpress/
    Et je vais prochainement un publier un second un peu plus light qui permet de se monter un site de test en une heure max!

    #929711
    Comme une image
    Participant
    Maître WordPress
    2493 contributions

    Intéressant ! Je comprends bien la notion de « pré-prod » (je bosse dans l’info 😉 et effectivement, une version Wamp locale tient plus d’environnement « d’intégration ».
    Je vois aussi l’avantage : être bien sûr que tout fonctionne de manière “ISO”. J’ai pu faire l’expérience à plusieurs reprises de différences dues aux modules activés ou pas d’Apache ou de Php. Néanmoins, à chaque fois, j’ai pu réaligner mon environnement local avec la « prod ».

    Je signale au passage qu’un des grands avantages de Wamp, c’est que je peux bosser tranquille même sans connexion réseau (par exemple, dans le train).

    Quelques remarques avec un environnement en prod :
    1/ faire bien attention à ne pas être indexé par les moteurs de recherche
    2/ risque (modéré) que d’autres yeux y accèdent (un risque qui peut aussi être un avantage en cas de travail collaboratif, ce que ne permet pas une copie locale) – qui peut être tempéré par des extensions (mais dans ce cas, on n’est plus exactement ISO) ou un filtrage d’IP.

    Tout cela est probablement pris en compte dans ton tutoriel mais je ne me suis pas inscrit pour le lire !

    #929712
    Lumiere de Lune
    Participant
    Maître WordPress
    19385 contributions
    chezmat wrote:
    Wamp, c’est bien avant de mettre le site en ligne, mais une fois en ligne, je pense qu’il est plus propre d’avoir également un site de test en passant par un sous-domaine.

    Je ne suis pas vraiment d’accord. Le transfert des informations / paramétrages / réglages nécessite de toute façon une correction de la base de données. Le travail est beaucoup plus rapide en local qu’en uploadant sans cesse les modifs.
    Que après un gros dev on fasse un site de “recette” en ligne, oui c’est une bonne idée, mais pour le dev de fonctionnalités supplémentaires, les modifs de theme, je les fais toujours en local.

    #929713
    Comme une image
    Participant
    Maître WordPress
    2493 contributions

    Je crois que c’est ce qu’il préconise aussi :
    1/ en local : on développe
    2/ en pré-prod : on teste que tout marche toujours bien
    3/ on met en ligne en prod.

    L’étape 2 qu’il propose est un peu “luxueuse” a mon sens mais peut valoir la peine
    1/ en cas de travail collaboratif
    2/ en cas de haute criticité sur la disponibilité du site de production (sur un blog perso, on peut se permettre d’avoir le site en rideau quelques heures voire quelques jours, sur un site pro c’est gênant !)

    #929714
    chezmat
    Participant
    Chevalier WordPress
    183 contributions

    [Edit modération : inutile de citer le message en entier]

    Tu peux accéder à mon tutoriel sans être inscrit (l’inscription est pour le format pdf).
    L’accès de ma préprod est bloqué et réservé aux seuls admin via un un plugin, donc pas de soucis au niveau de l’indexation..
    Je suis d’accord que le fait d’avoir besoin d’une connexion un net peu être vu comme un frein.. Tout dépend des usages que l’on en a!

    #929715
    Comme une image
    Participant
    Maître WordPress
    2493 contributions

    Je connais les extensions du type “Opening soon” mais sur mon site, par exemple, j’ai besoin de tester l’interface quand on arrive sans identification, justement (à cause de billets privés / publics) donc je suis bien plus confortable en local.

    Enfin, tout ça pour dire que ton alternative est intéressante mais qu’elle n’est pas universelle (mais je crois qu’on est d’accord là-dessus !)

    #929716
    chezmat
    Participant
    Chevalier WordPress
    183 contributions

    J’ai choisi de bloquer l’accès ainsi, mais il y a bien d’autres moyens!
    Je n’ai effectivement pas la prétention de dire que ma solution est universelle, simplement qu’elle répond à mon besoin (et peut être à d’autres!).
    L’idée encore une fois étant de créer ce site de test après la mise en ligne de manière à pouvoir tester des modifs mineures sans toucher au site de “prod” genre une modification de code ou de paramétrage, voire un nouveau thème.

15 sujets de 1 à 15 (sur un total de 19)
  • Le forum ‘Dépôts pour les extensions, trucs, astuces’ est fermé à de nouveaux sujets et réponses.