Wordpress с проблемами развертывания Git
Я новичок в wordpress, пришел из мира python/django, где существуют довольно устоявшиеся стандарты для рабочих процессов разработки и развертывания сайтов, поэтому я пытаюсь найти некоторые рекомендации по управлению развертыванием.
Для получения некоторой информации о том, что я пытаюсь сделать: я беру на себя развертывание wordpress для электронной коммерции, размещенное на Digital Ocean. Сайт работает, и хотя в долгосрочной перспективе мы, скорее всего, перейдем на другую платформу, так что это несколько временное решение, позволяющее вносить некоторые изменения в установленные темы и легко развертываться в цифровом океане, сохраняя при этом контроль над (версией).
Я изначально пытался развернуть WP в heroku с портом для использования MySQL репозитория Mhoofman. Проблема, с которой я столкнулся, заключалась в том, что расширение WP Только для чтения нарушало такие вещи, как импортер и миниатюры, и, похоже, оно больше не разрабатывается. В противном случае это было бы моим предпочтением решение.
Моей последней попыткой было опробовать метод Efeqdev настройка wordpress в качестве подмодуля. После того, как я столкнулся с проблемами, связанными со статическими файлами в MAMP в OS X, я, наконец, заработал.
Теперь у меня возникают следующие проблемы с установленными плагинами:
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
Конечно, как только я выполнил всю работу и прочитал комментарии к сообщению, похоже, что они перешли к развертыванию с использованием Основы. Мои сомнения по поводу использования Коренных пород заключаются в том, что это похоже, что Composer будет управлять плагинами для меня и может стереть любые настройки, которые я, возможно, внес в них. Как я уже сказал, я не очень хорошо знаком с PHP/Wordpress, поэтому, если я ошибаюсь в этом, и это кажется более разумным вариантом, пожалуйста, дайте мне знать.
Похоже, что перемещение по частям WP имеет большой потенциал для того, чтобы что-то сломалось. Было бы разумнее сохранить подкаталог wp-content в подмодуле git и все остальное стандартным способом? Не совсем уверен, как поступить с материалами в папке "Загрузки" не рекомендуется хранить их в git, они изменяются на сервере при загрузке новых изображений, и мы используем cloudflare для распространения мультимедиа.
1 answers
Я фиксирую весь WordPress, потому что считаю его одним большим куском кода, относящимся к одному сайту, это означает, что обновления основных файлов WordPress, плагинов и тем являются частью истории фиксации.
Я не использую подмодули или какие-либо другие странные настройки вложенных версий. Если у вас сложная структура, включающая несколько репозиториев, я предлагаю хранить их отдельно и просто использовать composer или другой инструмент для обновления основного репозитория файлами, а не отдельным приложением истории.
Что я делаю, чтобы игнорировать, что специфично для WP:
- Любые файлы кэша или временные файлы (например
objectcache/
,pgcache/
, и т.д.) /wp-content/uploads/
- Каталоги резервных копий, журналы, карты сайтов
- Конфигурации (
wp-config.php
,.htaccess
, любые конфигурации кэша и т.д.)
Не все сайты одинаковы, я иногда фиксирую wp-config.php
с помощью кода с несколькими средами, или иногда я буду фиксировать /wp-content/uploads/
, потому что это имеет смысл.
Также некоторые плагины и темы загружают медиафайлы в другие местоположения, что раздражает, поэтому иногда я полностью игнорирую типы файлов.
Некоторые самоуверенные заметки:
Я не понимаю, почему люди не фиксируют все WP в репозитории, у вас гораздо меньше ответственности, когда в вашей истории есть изменения WP для обновлений (будьте осторожны с автоматическими обновлениями).
Потратьте время на правильную настройку и тестирование, материал будет работать намного плавнее при хорошем рабочем процессе, в отличие от того, что произойдет, если вы попытаетесь изменить его позже вкл.
Я придерживаюсь позиции, что чем больше, тем лучше, потому что отстойно оборачиваться в поисках чего-то только для того, чтобы понять, что этого там нет. Но также отстойно совершать то, чего вы не хотите, поэтому упрощение уменьшает количество сценариев, связанных с работой мозга.
Вот пример.gitignore, с которого я начинаю: https://gist.github.com/wycks/574052a64eee9307b06c