Патч от Magento SUPEE-6788 не работает с Git/Github

Question

После того как я успешно установил патч SUPEE-6788 на свой локальный хост и нажал изменения в разработке, я заметил несколько проблем в моей среде dev, которые я не видел на своем Localhost.

Первая проблема, которую я обнаружил, заключалась в том, что ни один из моих блоков контактных форм не появлялся.

Затем я заметил, что он не ограничивается контактной формой, это было где угодно, у которого была форма (через страницу CMS).

После копания немного глубже (трассировка стека исключений), я узнал, что мне не хватает таблицы, которая не существовала до того, как она была вызвана «permission_block».

После немного более глубокой обработки я узнал, что в патче было много обновлений базы данных, которые не запускались при продвижении к разработке (через скрипт обновления). Если посмотреть на патч напрямую, я вижу, что сценарии обновления были фактически обновлены и что файлы конфигурации отображали эти обновления (номер версии и все). Но по какой-то причине они не побежали.

Теперь у меня осталась дилемма. Я не уверен, какие обновления произошли и какие обновления нет (в среде разработки).

Являются ли дополнения SUPEE выпусками Magento не предназначенными для использования в сочетании с Git/Github?

Нужно ли применять патч отдельно для каждой сборки вместо того, чтобы нажимать на сборку после исправления?

Answer 1

ли SUPEE патчи Magento релизы не предназначены для использования в сочетании с Git/Github

Там нет ничего в SUPEE патчей, которые могли бы помешать вам использовать Git/GitHub для управления хранилищем.

Сказанное - ваш вопрос не вполне имеет смысл, и я думаю, что это может быть из-за непонимания относительно того, как эти обновления базы данных применяются.

Magento Setup Resource scripts Разрешить разработчику модуля обновлять базу данных.Всякий раз, когда Magento загружает некэшированный запрос на HTTP, он будет

1. Проверьте версию всех заявленных модулей в app/etc/(code|community|local)

2. Сравните эту версию с версией, хранящейся в core_resource таблицы

3. Если в файловой системе установлена ​​более новая версия, запустите соответствующие сценарии ресурса установки в папке sql/

4. Update core_resource для указания версии установлен

Основываясь на ваш вопрос, это звучит как один из следующих произошло

1. Вы загрузили обновленные файлы из источника, но никогда не очищается кэш в производстве , а сценарии ресурса настройки никогда не выполнялись

2. Вы загрузили обновленные файлы, очистили кеш, но что-то о вашей производственной системе помешало сценариям от полностью работает. Поскольку у MySQL нет транзакционных обновлений для всех команд изменения структуры, сценарий ресурса установки может не выполняться полностью, но все же обновлять таблицу core_resource с той же версией.

Я хотел бы начать путем сравнения версии расширения в core_resource с версиями на файловой системе (в config.xml)

Кроме того, вы можете использовать sys:setup:incremental команду, это часть программы n98-magerun вручную применять обновления без очистки кеша. Это также может помочь вам диагностировать, какие из возможных проблем могут вызвать проблемы.

Наконец, поскольку у вас есть рабочая версия разработки, в качестве последнего средства вы можете использовать mysqldump, чтобы выгрузить структуру каждой базы данных, а затем сравнить с инструментом визуального разграничения (например, WinMerge), чтобы определить, какие таблицы/строки отсутствуют , Вам нужно применить к этому немного ума (так как у разработчика также могут быть другие ненужные вещи)