Когда я работаю над проектом по обновлению системы, я делаю различие между системой клиента и новой установкой Magento. Я ищу основные хаки или дополнительные файлы, которые не являются частью стандартного Magento, чтобы удостовериться, что я ловлю любую дрянную, но критичную для бизнеса работу, выполненную предыдущим фрилансером, подрядчиком, консультантом или агентством.
Одна вещь, которая всегда ставит меня в тупик, это патчи. В течение многих лет Magento выпускала исправления «между версиями» - обычно для исправления проблем с безопасностью или изменения в API поставщика доставки / оплаты.
Проблема в том, что с точки зрения различий патчи неотличимы от основных хаков, особенно если вы не знаете, какие патчи (если они есть) были применены к системе.
Что приводит к моему вопросу.
Как вы различаете основной взломать и патч?
источник
Это то, с чем я часто сталкиваюсь (и сейчас над этим работаю), и, к сожалению, пока это полностью ручной процесс - у нас есть автоматизированный процесс, который помечает каждый файл, который может быть изменен, как часть нашего первоначального автоматического аудита для новый клиент поддержки. Затем у нас есть кто-то, кто проверяет эти файлы и исключает любые очевидные ложные срабатывания (т. Е. Изменения пробелов).
Затем самое интересное - старший сотрудник нашей команды, который довольно долго работает с Magento, должен взглянуть на результаты, чтобы определить, может ли какой-либо из измененных файлов быть результатом исправления. Мы рассмотрели обновление нашей системы для проверки всех исправлений, о которых мы знаем / которые могут попасть в руки, и это может работать для CE, но в EE это еще более сложно, поскольку поддержка EE иногда выдает исправления напрямую. для клиентов, которые никогда не выпускаются иным образом или каталогизируются в согласованном порядке.
Итак, когда мы выполняем этот уровень проверки, мы полагаемся на прошлый опыт применения этих исправлений + здравый смысл (т. Е. Является ли это просто изменением конечной точки API? Если да, присутствует ли эта измененная конечная точка в обновленной версии? Если так, это был патч и его можно игнорировать).
Теоретически было бы просто применить все исправления, доступные на странице загрузки CE, и т. Д., К каждой применимой версии CE и проверить их (FYI, мы не используем diff для первого прохода - мы используем хеширование, в отчасти потому, что мы встроили эту технологию в инструмент, который может удаленно проверять сайт без необходимости сначала загружать его). Это исключило бы большинство исправлений, но все равно не помогло ни для каких исправлений CE или EE, которые не опубликованы в общедоступной области загрузки для CE или клиентской / защищенной области загрузки для EE. Это потребует от Magento согласованной политики, чтобы ВСЕ патчи были доступны ВСЕМ клиентам, и отправляли их туда, где мы могли бы их получить.
Так что я не думаю, что есть способ на 100% автоматизировать это, пока, к сожалению, не произойдут изменения в Magento.
источник
git diff depot/master origin/master
. Задача - это .gitignore. Другой вариант - клонировать версию в отдельныйapp/code/core
каталог , а затем скопировать в нее каталог сайтов .git diff -w
потом скажу.Один из способов, которым я подошел к этому, когда я делал много обновлений и пытался систематизировать процесс, заключался в том, чтобы на самом деле фиксировать патчи непосредственно в вашем репозитории основного кода, который вы используете для сравнения.
Это на самом деле имеет два преимущества:
Нет больше ложных срабатываний, отображаемых в ваших отчетах.
Допустим, у вас есть сайт, на котором нет определенного патча. Вы можете сказать, что это проблема, потому что он будет отображаться как отсутствующий код в вашей разнице, хотя технически они ничего не пропускают по сравнению со свежей незапатченной загрузкой. Но на самом деле то, что у них отсутствует патч, на самом деле является проблемой, которая должна быть решена - поэтому прекрасно, что она появляется в вашем diff для вас, чтобы исправить ее вместе с обновлением.
источник
Я не думаю, что изначально иметь Magento в репо-проекте - хорошая идея, если вы управляете более чем 2-3 клиентами. Поскольку всегда проще испортить прикладные системные исправления с помощью основных хаков.
На мой взгляд, лучший вариант - иметь зеркало репозитория композитора Magento с тегами версий, которые указывают на конкретную версию Magento с возможными официальными исправлениями.
Также было бы проще поддерживать ваши собственные патчи для файлов, такие как Mage_Core_Model_Config для высоконагруженных веб-сайтов и некоторых других, путем введения их установки через composer с номером версии, соответствующим вашей версии Magento.
Таким образом, в этом случае ваше обновление всех пользовательских проектов до исправленного кода Magento приведет только к изменению версии вашего файла композитора. Кроме того, хранение кода проекта отдельно от ядра заставит ваших разработчиков не взламывать ядро.
Что касается определения патча и хака, я бы предпочел назвать его так:
Таким образом, переместив ядро в отдельное хранилище, вы убедитесь, что у вас есть только исправленная версия в соответствии с пунктом 1. И вы можете легко установить свои собственные исправления через composer в локальный пул кода, чтобы у вас было все в соответствии с пунктом 3. В случае 2 и 4 вы можете создать ловушку git commit в репозитории проекта, чтобы запретить любую фиксацию кода в этом каталоге.
источник
Я смотрю на файл примененных исправлений в этой
/app/etc/
папке и работаю задом наперед. Но, как я узнал из обновления, я могу просто удалить файл в версии, в которой есть пропатченный файл, и в следующий раз, когда он пропатчен, он чистый.источник
Что-нибудь от Magento я бы назвал патчем. Все остальное взломать.
источник