Патч или Core Hack

14

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

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

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

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

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

Алан Сторм
источник

Ответы:

16

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

beeplogic
источник
Ухоженная! Я не знал этого. Знаете ли вы, является ли это частью фактического .patch - или поддержка делает это вручную? Или (возможно?) Оба? Просматривая некоторые старые файлы .patch и не видя каких-либо изменений в файле application.patches.list.
Алан Шторм
Self помог в этом последнем случае - патчи CE делают это автоматически (см .: magentocommerce.com/index.php/getmagento/ce_patches/… )
Alan Storm
2
Похоже (и @ joshua-s-warren, кажется, подтверждает), что не все файлы исправлений созданы одинаковыми. Если нам «повезет», в патч будет встроена эта функциональность. Вот пример того, в котором он есть: magentocommerce.com/index.php/getmagento/ce_patches/… В нем также перечислены только файлы, которые были изменены, а не изменения. вам нужно будет попытаться отследить патч, чтобы узнать, что изменилось, но даже тогда нет «гарантии», что он был тем же самым.
beeplogic
2
К сожалению, большинство патчей EE, которые мы получили, не имеют этой функциональности
Аллан МакГрегор,
4
Все патчи, распространяемые в виде файлов .sh, для билетов SUPEE должны иметь эту функцию (кроме старых). Удивленный @AllanMacGregor, вы этого не видите. У вас есть пример патча, который был применен (номер SUPEE), но не указан в списке?
Петр Каминский
7

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

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

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

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

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

Джошуа С Уоррен
источник
2
С github-репозиторием версий magento легко позволить git выполнять свою работу. Нет необходимости в хешировании. Просто добавьте удаленный, получите удаленный и git diff depot/master origin/master. Задача - это .gitignore. Другой вариант - клонировать версию в отдельный app/code/coreкаталог , а затем скопировать в нее каталог сайтов . git diff -wпотом скажу.
Мелвин
Мы сделали это таким образом, потому что мы часто тестируем это удаленно на серверах, которые не позволяют нам устанавливать программное обеспечение и, возможно, не имеют установленного git. В среде, где присутствует git, вы правы, вы можете использовать git diff.
Джошуа С Уоррен
Ах да, я понимаю вашу точку зрения. На самом деле я собираюсь подумать о том, как сделать что-то подобное в magerun.
Мелвин
4

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

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

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

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

kalenjordan
источник
4

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

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

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

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

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

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

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

Иван Чепурный
источник
3

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

jeremy.bass
источник
2

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

Джош Пеннингтон
источник
1
Договорились, но это как сказать что есть что по факту.
Алан Шторм
Я бы, вероятно, сделал сравнение вашего сравнения с базовой установкой, а затем произвел бы дополнительное сравнение с установкой с каждым патчем, примененным отдельно (или только с конечным результатом всех примененных патчей). Вероятно, это будет на несколько порядков больше работы, но это единственный способ, о котором я могу думать.
Джош Пеннингтон