Local simplifie le développement WordPress sur un Mac
Local est un logiciel chargé de simplifier le développement en local de sites WordPress. Cet utilitaire était vendu sous le nom de Pressmatic, mais il est gratuit depuis son achat par Flywheel, un hébergeur spécialisé dans les sites WordPress. Une formule payante est prévue à terme, pour le moment vous pouvez l’utiliser gratuitement sans limites.
L’idée de Local, c’est de créer un environnement isolé sur votre Mac et très similaire à celui que vous aurez en hébergeant un site. Le logiciel exploite VirtualBox pour créer des machines virtuelles avec Docker, l’outil de virtualisation qui est très couramment utilisé désormais par les hébergeurs. Chaque machine est configurée avec Apache ou NGINX, PHP, MySQL et quelques outils indispensables au bon fonctionnement de WordPress.
Vous pourriez installer tout cela vous même, mais Local simplifie l’installation et permet de créer plusieurs sites en parallèle en quelques clics. Vous pouvez définir à chaque fois la version de PHP et de MySQL à utiliser et le logiciel génère systématiquement un nom de domaine en .dev pour y accéder en local avec un navigateur. Vous pourrez ensuite créer le site avec thème et modules et quand vous serez satisfaits, le logiciel permet d’exporter le résultat. Dans l’archive, vous retrouverez tous les fichiers nécessaires au site, y compris la configuration du serveur.
À condition de configurer le serveur de la même façon que Local, vous pourrez ensuite facilement publier le site et obtenir une version prête à l’emploi. L’objectif de Flywheel, c’est de proposer une solution pour publier un site en local sur ses serveurs en quelques clics, mais ce n’est pas encore le cas avec la version actuelle. Parmi les projets du nouveau propriétaire, la possibilité de créer une copie locale de n’importe quel site en ligne, à la fois pour le sauvegarder et pour le modifier sans toucher au serveur.
Local est réservé à macOS pour le moment et OS X 10.10 est nécessaire au minimum. Une version Windows est également en préparation. L’interface n’est pas traduite en français.
Intéressant ! :)
Merci pour la découverte MacG. ;)
Autre environnement pratique en local
Valet le client wordpress en ligne de commande (WP_cli), le tout installe via brew. Cela crée également un site en .dev
Mais je considère plus cela comme un environnement de test
La partie compliquée (un article détaillé sur le passage du local vers le serveur avec un hébergement ovh ? ) est d'essayer de "transférer" cela chez un hébergeur et que cela corresponde au bon nom de domaine
@ deltiox : c'est vrai que Valet est pas mal du tout aussi ! J'imagine que Local conviendra à tous ceux qui préfèrent les interfaces plutôt que le terminal…
Je suis d'accord, le transfert est un peu galère. C'est pour ça que leur solution est pas bête quand ils proposeront de publier un site conçu en local sur leurs serveurs. Bon par contre, niveau tarifs, on est loin d'OVH…
Salut,
Partie compliqué ? Non pas du tout. Migrer un site WordPress est fort heureusement simple, et pas besoin de correspondre forcément au nom de domaine ;) .
Tu peux faire la manipulation avec l'outil SRDB (tuto ici par exemple : https://www.wpserveur.net/changer-vos-liens-facilement-avec-srdb/).
Si tu galères trop, vient sur le Slack WPFR ;) . On te donnera un coup de main !
@fuitedeau :
Ben ce serait pas de refus
Parce que si je génère en local le site
Toto.dev
Et que je veux ensuite mettre cela à la place d'un site hébergé disons chez OVH (ou ailleurs) avec une instance de Wordpress (instance 1 click créée automatiquement par l'hébergeur) et sa base SQL déjà créées et que cet hébergement est déjà lié à un DNS (disons youpi.fr), ben je trouve cela galère...au point de ne meme pas tenter
Simple ?!
Cela fait plusieurs fois que j'essaye de migrer mon site distant vers du local pour le faire tourner avec Mamp, je change les adresses de la BDD, mais à chaque fois mes pages échoue, sauf quand j'en crée une nouvelles.
Pourquoi ???? Jamais trouvé.
Bah c'est tout bête. Wordpress est tellement pourri qu'il sauvegarde en dur un peu partout dans la base de données le chemin du répertoire sur le serveur ainsi que les URL. Et n'allez pas les remplacer à la main, car les données sont sérialisées.
Donc l'astuce est de ne jamais exporter la base de données telle quelle, mais plutôt d'utiliser l'extension gratuite wp migrate. Ça donne un fichier sql qu'on importe sur le nouvel hébergeur. Quant aux fichiers, on les transfert tels quels. Pas de quoi fouetter un chat donc.
Sinon, l'autre solution est d'utiliser un vrai CMS.
Ah oui, tiens, ça existe toujours...
Avec une mise à jour tout les 4 ans...
2008 - 2012 -2016...
Avec toujours aussi peu de plugin et de doc.
J'ai tellement souffert à cause de cette daube.
Au contraire, Spip a moins besoin de mises à jour car ça marche :-) peut pas en dire autant de WP. (j'ai plus d'une 100aine de Spip et une 100aine de WP à mon actif, et une 10aine de Drupal).
Quant aux plugins ahah ... Exemple: Il y a au moins une 20aines de plugins sérieux d'agenda chez WP, un seul chez Spip. Ok. Sauf que le seul de Spip, développé en commun et longuement amélioré depuis longtemps fait tout mieux que n'importe lequel de WP. Cerise sur le gâteau, il est gratuit et vraiment opensource lui. Et on n'a pas à perdre un jour de travail pour trouver le bon.
Le pbm de Spip c'est que les gens arrivent en disant "je veux un Wordpress", sans même savoir pourquoi ils veulent un site, car oui, les américains sont nettement plus forts en terme de com et de dollars, WP rapporte de l'argent aux contributeurs, pas Spip. Mais je prend Spip avant WP dès que je peux, ça c'est sûr.
Et oui un Spip est considérablement plus facile à changer de nom, d'hébergeur, ça aussi c'est sûr. Spip ne stocke que des liens relatifs, pas le nom de domaine voire pire le chemin absolu comme le fait WP. Néanmoins, changer un WP de nom est quand même facile avec les bons outils, j'en ai fait un pas plus tard qu'il y a 10 mn :-) Et non, juste modifier le chemin ou l'url dans le dump mySQL n'est pas suffisant, WP stocke des données sérialisées que l'on casse en faisant ça (la donnée enregistre aussi sa longueur, donc si l'url est plus ou moins longue, c'est cassé).
@pierrot99 :
Quels outils du coup ?
Allez allez des conseils :-)
Par ex le plugin MigrateDB marche très bien (en version gratuite) et permet d'exporter une base en modifiant tout ce que l'on souhaite (url, chemins absolus, etc ... avec des regexp si nécessaires pour des modifications complexes) et en respectant les données sérialisées (souvent utilisées par des plugins) ... il produit un dump qu'il suffit de réimporter avec phpmyadmin dans la base de destination.
Pour les riches, la version payante fait tout ça quasi automatiquement avec push des fichiers media, des thèmes etc ...
Curieusement les problèmes que tu décris ne semblent pas affecter beaucoup les dizaine de millions de sites wordpress.
C'est juste une question de manière de faire.
Il y a des choses à ne pas faire avec wordpress comme il y a des choses à ne pas faire avec spip.
Vous attendez de wordpress qu'il fonctionne comme spip ? Et bien restez donc sous spip alors.
Mais une chose est sûre.
Parier sur un outil si peu utilisé, si peu documenté et si peu mis à jour depuis maintenant bientôt 10 ans , c'est suicidaire.
Ca n'enlève rien au caractère plutôt rigoureux de sa conception, mais il a les défauts de ses qualités. un cms plutôt pas mal pour faire des sites il y a 15 ans, mais avec les contraintes actuelles de webdesign et responsive, ce n'est une solution ni productive ni viable.
Mais bon des nostalgiques des époques révolues, il y en aura toujours..
Il y a bien des gens qui bricole encore sur Amiga..
C'était une super machine, mais il y a un moment où il faut savoir tourner la page.
@macinoe :
Je ne trouve pas très pertinent de comparer les deux, ce sont deux CMS bien différents
Le grand avantage de wordpress, c'est qu'il existe des templates toutes prêtes redoutablement complexes et riches, responsives, etc, qui permettent de monter un site très simplement en quelques minutes et qui va afficher des diaporamas, des vidéos, des pop-in, des menus et sous menus, etc
L'autre avantage c'est sa prise en main facile niveau création de contenu qui lui permet d'être mis dans les mains de contributeurs "lambda" qui s'en sortiront avec très peu de formation
L'avantage de SPIP c'est que pour peu que l'on maitrise la plateforme, les boucles, les codes, etc, on peut a peu près tout faire sur mesure pour un client, mais il y a plus de travail concernant le front, le responsive, etc
Une fois le site monté, l'interface d'administration et la création de contenu est plus compliquée et nécessite plus de formation, donc des clients qui risquent d'appeler plus souvent
Bref, si un client demande du sur-mesure avec des choses très précises et très spécifiques, SPIP est pas trop mal, si un client demande un truc simple et pas cher et rapide, wordpress est génial
avec les custom post ( de nombreux plugin permettent même d'en ajouter en quelques clics)
Tu peux modeliser tout ce que tu veux sous wordpress.
C'est une façon différente de penser c'est tout.
Pourtant je viens du monde de la programmation objet et des modélisations de données.
Mais en presque 10 ans de pratique de wordpress et sans doute plus d'une centaine de site réalisés, je n'ai jamais été obligé de bricoler pour un problème de modélisation de données, jamais.
Et donc ?
Et donc WP ce n'est pas que pour les trucs simples et pas cher comme tu l'affirmes.
La modélisation des données par custom post, les champs personnalisé et la simplicité d'écriture des plugin permettent de vraiment tout faire. Vraiment tout.
Je le précise parce que pour beaucoup de gens ont une idée de WP restée 10 ans en arrière, pour eux c'est juste un moteur de blog.
Commentaire vraiment typique des utilisateurs d'un produit (WP) qui ne connaissent pas vraiment un autre produit (Spip).
Parler des contraintes de webdesign et de responsive alors que ça n'a rien à voir (ça c'est du HTML et des CSS et du framework js et du framework css) ... tous les sites spip que l'on fait sont responsive, adaptive, bootstrap, et tout ce que l'on souhaite, que ce soit en WP ou en Spip. Le but d'un CMS c'est la séparation du contenu et de la forme, certains semblent l'oublier.
Et je ne vois pas de quels problèmes je parle, comme je le dis je fais autant de sites WP que de sites Spip et je n'ai pas de problèmes avec l'un ou l'autre.
C'est bien la majorité des gens dans ce fil qui ont soulevé le souci du transfert des sites WP, pas moi, moi j'ai même donné une piste pour ceux qui auraient du mal. Ce que je constate c'est qu'en fait 80% des gens développent directement en ligne pour éviter ce problème de transfert, ça c'est une pratique de dev qui est très moyenne (je ne parle pas des vrais pros qui savent faire, je parle de la majorité des bidouilleurs qui achètent un thème).
Spip est au contraire bien documenté, par contre WP, si tu parles pas anglais, difficile d'avoir des réponses intéressantes, en particulier sur les plugins, 99% du support dans ce domaine est en anglais (perso je m'en fous, je suis bilingue, vécu 5 ans aux US à une époque ou le CMS en vogue était Movable Type, donc des CMS j'en ai vu passer et ce qui est triste, comme V2000 vs VHS, c'est pas toujours la meilleure techno qui survit).
Et moi ce que je pense c'est que parier sur WP c'est se tirer une balle dans le pied: de plus en plus de gens font eux-mêmes, bientôt on n'aura plus besoin de nous.... sans parler du jour ou WP deviendra sur abonnement par ex, ce jour on rigolera bien :-)
@Pierrot : peut être je me suis mal exprimé, mais je ne dis pas autre chose que ce que tu dis (et j'ai monté des sites en SPIP et en WP)
Ce que je dit, et de manière très simple, c'est que Wordpress permet de monter un truc complet, nickel, front (avec une bonne template) et back (WP) en quelques clics, et le front est tout prêt dans la template, tout est en place, tout est géré
ça c'est la bonne nouvelle, la mauvaise, c'est que si tu veux du sur mesure, faut faire mumuse avec la template et ses limitations, et parfois très compliqué, et parfois c'est juste pas possible
Spip, à contrario, c'est que le back, il faut monter tout le front soi-même, et ça peut être un très gros travail, mais avec l'avantage que l'on fait ce qu'on veut, comme on veut, du sur-mesure à 100%
C'est ça pour moi la grande différence entre les deux, et le fait qu'il est difficile de les comparer tant les usages et les possibilités de l'un et l'autre sont éloignés.
@pocketalex
Je ne sais pas pour quoi les réponses sont présentées comme ça (la tienne s'est insérée avant la mienne) mais ma réponse était bien à @macinoe, j'aurai dû le préciser (mais quand je l'ai rédigée, je ne voyais pas ton texte).
Mais bref oui, on est d'accord :-)
"Commentaire vraiment typique des utilisateurs d'un produit (WP) qui ne connaissent pas vraiment un autre produit (Spip)."
Pas de pot, je gère environ 200 sites dont une grosse centaine sous spip, quelques uns sous magento, drupal, prestashop et environ 80 sous wordpress.
De part ce lourd héritage, j'ai été amené à faire beaucoup d'évolutions sous spip.
J'ai bien été obligé de m'y mettre à sa structure débile en rubrique, ses boucles et leur syntaxe mal foutues..
Je déteste. C'est un cms ultra contraignant qui oblige à penser les choses d'une manière hyper formatée.
Je comprend que ceux qui s'y sont consacré entierement pendant des années ont le plus grand mal à faire autrement..
J'imagine que ça demande autant de violence pour un spipien de se mettre à autre chose que pour un non spipien à se mettre à spip.
La différence c'est que spip n'a aucun avenir.
Quel est le rapport en CMS et responsive design ? Je cherche....
@AirForceTwo : Aucun rapport en réalité, mais dans les faits Wordpress est un outil de blogging et pas un CMS de site, et pourtant si il est aujourd'hui bien plus utilisé pour monter des sites que des blogs
Avec Wordpress, tu as un pack complet CMS + Front, soit avec les templates fournies, soit en achetant des templates toutes prêtes (parfois très puissantes et très complètes), donc avec cet outil, on lie un peu les deux, c'est tout
Avec la limitation que tu feras pas beaucoup plus que ce que propose la template, alors que SPIP, c'est un CMS back et en front tu fais ce que tu veux, du truc le plus basique au minisite d'expérience interactive le plus délirant
@AirForceTwo
A priori aucun, @macinoe disait que spip ne pouvait pas être responsive ... je lui répondais que le but d'un CMS était justement de séparer le contenu de sa présentation et que donc ce qu'il disait ne pouvait résulter que d'une méconnaissance complète de Spip et/ou des CMS en général.
Je n'ai jamais dit ça.
Je dis que ça demande énormément de travail sous spip de faire du responsive pour la simple raison que les outils disponible pour le faire sont quasi inexistant et qu'il faut tout ecrire.
Teste des plugins comme fusion core et des hyper themes comme avada et on en reparle.
Sous spip tu te retrouves avec tes silex à devoir réinventer la roue, ça n'a rien à voir.
Et puis excuses moi mais les systèmes de blocs responsive ont mis à mal le principe de séparation des données et de la présentation.
Une page responsive ne peut pas se résumer à du contenu, il y a aussi le comportement des blocs qui la composent.
Un spipien va concevoir ce genre de page en découpant chaque bloc comme une rubrique ou un article et faire une modélisation usine à gaz totalement aberrante et qui n'a aucun sens fonctionnel.
C'est en ce sens que spip est totalement inadapté au responsive. Parce qu'une page responsive, ce n'est justement plus seulement du contenu que l'on doit afficher dans un squelette. La façon de penser spip appartient au passé.
Je vais faire une dernière réponse, tout ce que vous dites me prouve juste que vous ne connaissez pas vraiment spip et que donc la discussion n'apportera rien de plus. En plus l'attitude "c'est de la daube" ou "appartient au passé" ne relève que de l'étroitesse d'esprit, perso j'aime autant spip que WP que Drupal que Thelia que tout CMS qui présente un intérêt pour mon client, mon critère de choix n'est pas sur l'outil qui n'est que de la bidouille informaticienne mais sur le but et l'usage. Bonne continuation dans un monde merveilleux ou tout le monde fera du WP (jusqu'à ce que des nouveaux vous disent que WP est de la daube et qu'il appartient au passé, mdr).
Je ne dis pas que c'est la daube, je dis que c'était sans doute pertinent il y a encore 10 ans, mais que maintenant c'est une voie de garage.
Spip n'est plus utilisé que par quelques jusqu'au boutiste qui ne veulent pas admettre que c'est fini depuis longtemps et dans les faits c'était un cms franco-français qui n'a jamais été très utilisé.
Désolé que mon discours vous semble agressif, mais ce n'est que la vérité.
Mais je peux concevoir qu"elle est parfois dure à entendre. Surtout quand on a investi beaucoup de temps et d'énergie.
A titre personnel, il est vrai que je suis réfractaire à la philosophie générale de spip, mais ce n'est que mon avis et ça n'a pas de rapport avec le constat précédent.
Enfin, si, le rapport que ça peut avoir c'est qu'à l'époque où j'ai été contraint de travailler sous spip, son avenir était déjà scellé et la motivation ne pouvait pas être la même qu'avec un cms bénéficiant d'un avenir. D'où un avis sans doute influencé par cet état de fait et qui ne rend peut-être pas entièrement justice à l'outil.
Et il est parfaitement évident que l'heure de WP sonnera aussi et que ce serait une faute professionnelle de ne pas s'y préparer et de ne pas anticiper l'avenir.
@MickaëlBazoge
Spi...quoi ? ;)
Intéressant ! L'idéal serait de pouvoir avoir une version en local du site et de la mettre à jour (uploader) à chaque changement.
J'ai utilisé MAMP et je n'ai pas trouvé ça très compliqué sachant que je ne suis pas un expert.
Quelqu'un à un avis/comparaison sur Bitnami que j'utilise personnellement ?
le plus simple en local c'est d'utiliser MAMP (mac) WAMP (windows)
Hello,
Comme les autre je ne comprend pas la plus value de mamp ou autre ?
Pardon la plus value par rapport a mamp
Par rapport à MAMP, l'outil gère automatiquement le fichiers /etc/hosts et les vhosts Apache/Nginx pour ajouter des noms de domaines en .dev, c'est toujours 1 minute de gagnée et ça évite d'oublier de le supprimer quand on a terminé un projet ;)
Après c'est limité à du WordPress à priori, contrairement à MAMP et co.
On ne va pas se plaindre d'avoir autant de choix pour créer un environnement de dev local quand même ;)
mais faites une VM linux et mettez vous dans les même conditions (autant que possible os/bdd/nglnx ou apache, et réseau virtualisé) que votre futur hébergement.
Je ne connais pas WordPress et fais tous les sites avec Joomla. Installation en local avec Mamp, sauvegarde et déploiement avec Akeeba Backup. Vu que ça migre le site et les bases de données, je n'ai jamais eu de souci pour déplacer un site chez un hébergeur.
@freestef : joomla c'est génial mais c'est bien plus complexe que wordpress (et bien moins limité aussi)
Perso pour migrer un site WP local sur un serveur OVH j'utilise un script php qui s'appel searchandreplacedb2 qui permet de changer un terme dans toute la BDD.
Je change donc localhost par monsite.fr dans toutes les tables de ma base, je modifie le fichier wp-config et tout roule.
Et Mamp reste l'environnement le plus simple je trouve.