Патч или Core Hack

Когда я работаю над проектом по обновлению системы, я делаю различие между системой клиента и новой установкой Magento. Я ищу основные хаки или дополнительные файлы, которые не являются частью стандартного Magento, чтобы удостовериться, что я ловлю любую дрянную, но критичную для бизнеса работу, выполненную предыдущим фрилансером, подрядчиком, консультантом или агентством.

Одна вещь, которая всегда ставит меня в тупик, это патчи. В течение многих лет Magento выпускала исправления «между версиями» - обычно для исправления проблем с безопасностью или изменения в API поставщика доставки / оплаты.

Проблема в том, что с точки зрения различий патчи неотличимы от основных хаков, особенно если вы не знаете, какие патчи (если они есть) были применены к системе.

Что приводит к моему вопросу.

Как вы различаете основной взломать и патч?

Патчи Magento, предоставляемые службой поддержки, будут добавлять к ним журнал app/etc/applied.patches.list. Я не знаю, когда и как долго патч-скрипты делали это. Патчи CE также, кажется, делают это.

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

Затем самое интересное - старший сотрудник нашей команды, который довольно долго работает с Magento, должен взглянуть на результаты, чтобы определить, может ли какой-либо из измененных файлов быть результатом исправления. Мы рассмотрели обновление нашей системы для проверки всех исправлений, о которых мы знаем / которые могут попасть в руки, и это может работать для CE, но в EE это еще более сложно, поскольку поддержка EE иногда выдает исправления напрямую. для клиентов, которые никогда не выпускаются иным образом или каталогизируются в согласованном порядке.

Итак, когда мы выполняем этот уровень проверки, мы полагаемся на прошлый опыт применения этих исправлений + здравый смысл (т. Е. Является ли это просто изменением конечной точки API? Если да, присутствует ли эта измененная конечная точка в обновленной версии? Если так, это был патч и его можно игнорировать).

Теоретически было бы просто применить все исправления, доступные на странице загрузки CE, и т. Д., К каждой применимой версии CE и проверить их (FYI, мы не используем diff для первого прохода - мы используем хеширование, в отчасти потому, что мы встроили эту технологию в инструмент, который может удаленно проверять сайт без необходимости сначала загружать его). Это исключило бы большинство исправлений, но все равно не помогло ни для каких исправлений CE или EE, которые не опубликованы в общедоступной области загрузки для CE или клиентской / защищенной области загрузки для EE. Это потребует от Magento согласованной политики, чтобы ВСЕ патчи были доступны ВСЕМ клиентам, и отправляли их туда, где мы могли бы их получить.

Так что я не думаю, что есть способ на 100% автоматизировать это, пока, к сожалению, не произойдут изменения в Magento.

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

Это на самом деле имеет два преимущества:

1. Нет больше ложных срабатываний, отображаемых в ваших отчетах.

2. Допустим, у вас есть сайт, на котором нет определенного патча. Вы можете сказать, что это проблема, потому что он будет отображаться как отсутствующий код в вашей разнице, хотя технически они ничего не пропускают по сравнению со свежей незапатченной загрузкой. Но на самом деле то, что у них отсутствует патч, на самом деле является проблемой, которая должна быть решена - поэтому прекрасно, что она появляется в вашем diff для вас, чтобы исправить ее вместе с обновлением.

Я не думаю, что изначально иметь Magento в репо-проекте - хорошая идея, если вы управляете более чем 2-3 клиентами. Поскольку всегда проще испортить прикладные системные исправления с помощью основных хаков.

На мой взгляд, лучший вариант - иметь зеркало репозитория композитора Magento с тегами версий, которые указывают на конкретную версию Magento с возможными официальными исправлениями.

Также было бы проще поддерживать ваши собственные патчи для файлов, такие как Mage_Core_Model_Config для высоконагруженных веб-сайтов и некоторых других, путем введения их установки через composer с номером версии, соответствующим вашей версии Magento.

Таким образом, в этом случае ваше обновление всех пользовательских проектов до исправленного кода Magento приведет только к изменению версии вашего файла композитора. Кроме того, хранение кода проекта отдельно от ядра заставит ваших разработчиков не взламывать ядро.

Что касается определения патча и хака, я бы предпочел назвать его так:

1. Изменение исходного файла ядра официальным файлом патча - это патч
2. Изменение исходного файла ядра вашей командой - это взлом.
3. Изменение в локальном скопированном файле ядра с целью исправления ошибки - это патч
4. Изменение в локальном скопированном файле ядра для предоставления новой функциональности - это взлом

Таким образом, переместив ядро ​​в отдельное хранилище, вы убедитесь, что у вас есть только исправленная версия в соответствии с пунктом 1. И вы можете легко установить свои собственные исправления через composer в локальный пул кода, чтобы у вас было все в соответствии с пунктом 3. В случае 2 и 4 вы можете создать ловушку git commit в репозитории проекта, чтобы запретить любую фиксацию кода в этом каталоге.

Я смотрю на файл примененных исправлений в этой /app/etc/папке и работаю задом наперед. Но, как я узнал из обновления, я могу просто удалить файл в версии, в которой есть пропатченный файл, и в следующий раз, когда он пропатчен, он чистый.

Что-нибудь от Magento я бы назвал патчем. Все остальное взломать.