web-dev-qa-db-fra.com

Problèmes de déploiement de Wordpress avec Git

Je suis un nouveau venu dans wordpress, venant du monde python/Django où il existe des normes assez bien établies pour les workflows de développement et le déploiement de sites. J'essaie donc de trouver des conseils sur la façon de gérer un déploiement.

Pour en savoir plus sur ce que j'essaie de faire: je suis en charge d'un déploiement wordpress de commerce électronique hébergé sur Digital Ocean. Le site est en ligne et, même si, à long terme, nous allons probablement migrer vers une plate-forme différente, il s'agit donc d'une solution quelque peu temporaire permettant de personnaliser certaines thématiques installées et de les déployer facilement vers Digital Ocean tout en conservant le contenu (version ) le contrôle.

J'avais initialement essayé de déployer WP sur heroku avec un port pour utiliser MySQL avec le repo de de Mhoofman . Le problème que j'ai rencontré là-bas était que l'extension WP Read Only cassait des choses telles que l'importateur et les vignettes, et il semble que ce n'est plus vraiment en développement. Ce serait autrement ma solution préférée.

Ma dernière tentative a été d'essayer la méthode d'Efeqdev pour configurer WordPress en tant que sous-module. Après avoir rencontré des problèmes concernant les fichiers statiques dans MAMP sous OS X, je l’ai enfin fait fonctionner.

Maintenant, j'obtiens ces problèmes avec les plugins installés:

Strict Standards: Redefining already defined constructor for class WXR_Parser_Regex in [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php on line 408

Strict Standards: Declaration of WP_Import::bump_request_timeout() should be compatible with WP_Importer::bump_request_timeout($val) in [...]/project-wordpress/wp-content/plugins/wordpress-importer/wordpress-importer.php on line 38

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php:408) in [...]/project-wordpress/wp-content/plugins/ninja-forms/ninja-forms.php on line 638

Warning: Cannot modify header information - headers already sent by (output started at [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php:408) in [...]/project-wordpress/wordpress/wp-includes/option.php on line 750

Warning: Cannot modify header information - headers already sent by (output started at [...]/project-wordpress/wp-content/plugins/wordpress-importer/parsers.php:408) in [...]/project-wordpress/wordpress/wp-includes/option.php on line 751

Bien sûr, une fois que j'ai fait tout le travail et lu les commentaires sur le post, il semble qu'ils soient passés au déploiement en utilisant Bedrock . Mon hésitation à utiliser Bedrock est qu’il semble que Composer gérera les plugins pour moi et risque d’effacer toutes les personnalisations que je leur aurais apportées. Comme je le disais, je ne connais pas très bien PHP/Wordpress, donc si je me trompe à ce sujet et que cela semble être une option plus saine, veuillez me le faire savoir.

Il semble que se déplacer dans des parties de WP présente un grand potentiel de dégradation. Serait-il plus logique de conserver le sous-répertoire wp-content dans un sous-module git et tout le reste de manière standard? Je ne suis pas tout à fait sûr de savoir comment gérer les éléments dans le dossier de téléchargement, ce n'est pas une bonne idée de les conserver dans le git, ils sont modifiés sur le serveur lorsque de nouvelles images sont téléchargées et nous utilisons cloudflare pour la distribution multimédia.

pluginsgitdeployment
1
Andres

J'engage tout WordPress parce que je considère que c'est une grosse boule de code qui concerne un site, cela signifie que les mises à jour des fichiers WordPress principaux, des plugins et des thèmes font tous partie de l'historique des commit.

Je n'utilise pas de sous-modules ou d'autres configurations de révision imbriquées étranges. Si vous avez une structure compliquée d'inclure plusieurs pensions, je suggère de les séparer et d'utiliser simplement composer ou un autre outil pour mettre à jour votre pension principale avec des fichiers et non des historiques d'application distincts.

Ce que je fais git ignorer ce qui est WP spécifique:

  • Tous les fichiers cache ou temporaires (par exemple, objectcache/, pgcache/, etc.)
  • /wp-content/uploads/
  • Répertoires de sauvegarde, journaux, sitemaps
  • Configs (wp-config.php, .htaccess, toutes les configurations de cache, etc.)

Tous les sites ne sont pas identiques, je commets parfois wp-config.php avec un code multi-environnement, ou parfois je commets /wp-content/uploads/ parce que cela a du sens.

De plus, certains plugins et thèmes téléchargent des fichiers multimédias à d’autres emplacements, ce qui est ennuyeux. Par conséquent, j’ignore parfois les types de fichiers.

Quelques notes d'opinion:

Je ne comprends pas pourquoi les gens ne commettent pas tous les WP du référentiel, vous avez beaucoup moins de responsabilités lorsque vous avez WP des changements dans votre historique pour les mises à jour (attention aux mises à jour automatiques ).

Prenez le temps de bien configurer et de tester les choses fonctionnera beaucoup mieux si vous avez un bon flux de travail, contrairement à ce qui se passe si vous essayez de le changer plus tard.

J'admets que commettre plus, c'est mieux, parce que c'est chiant de faire demi-tour à la recherche de quelque chose pour se rendre compte que ce n'est pas là. Mais il est également difficile de commettre des choses que vous ne voulez pas, alors restez simple réduit les scénarios cerveau-bureau .

Voici un exemple de .gitignore je commence par: https://Gist.github.com/wycks/574052a64eee9307b06c

4
Wyck