Local simplifie le développement WordPress sur un Mac

Nicolas Furno |

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.

Local permet de créer plusieurs sites WordPress très simplement. Ici, les paramètres associés à un nouveau site. Cliquer pour agrandir

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.

Une fois le site créé, Local permet d’en modifier les paramètres via son interface et le logiciel affiche aussi des raccourcis vers le sites et son administration. Cliquer pour agrandir

À 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.

avatar LolYangccool | 

Intéressant ! :)
Merci pour la découverte MacG. ;)

avatar deltiox | 

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

avatar Nicolas Furno | 

@ 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…

avatar fuitedeau | 

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 !

avatar deltiox | 

@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

avatar Vladimok | 

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é.

avatar AirForceTwo | 

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.

avatar Mickaël Bazoge | 
Je vois que Spip est toujours snobé par monsieur Furno.
avatar macinoe | 

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.

avatar pierrot99 | 

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é).

avatar deltiox | 

@pierrot99 :
Quels outils du coup ?
Allez allez des conseils :-)

avatar pierrot99 | 

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 ...

avatar macinoe | 

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.

avatar pocketalex | 

@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

avatar macinoe | 

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.

avatar pocketalex | 

Et donc ?

avatar macinoe | 

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.

avatar pierrot99 | 

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 :-)

avatar pocketalex | 

@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.

avatar pierrot99 | 

@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 :-)

avatar macinoe | 

"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.

avatar AirForceTwo | 

Quel est le rapport en CMS et responsive design ? Je cherche....

avatar pocketalex | 

@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

avatar pierrot99 | 

@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.

avatar macinoe | 

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é.

Pages

CONNEXION UTILISATEUR