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 для распространения мультимедиа.

Author: Andres, 2014-11-04

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

 4
Author: Wyck, 2014-11-05 16:04:10