Ruslan Brest, rb.labtodo.com
Backend web-developer: CodeIgniter, PHP, MySQL, OpenCart, PrestaShop, MaxSite CMS

SafePatch -- альтернатива vQmod

22 апреля 2013 г. Ruslan Brest Просмотров: 5243 RSS 7
Интересное в сети » Web development » E-commerce » OpenCart
, ,

Идея патчей и vQmod совершенно одинаковая. И в одном, и другом случае файл с изменениями накладывается на некую известную основу. И если эта основа изменилась -- и патч, и vQmod могут "поломаться": не смогут внести изменения, если не найдут точного соответствия, необходимого для внесения правок.

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

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

К тому же vQmod - рантайм решение. То есть работает при каждом запросе к серверу. Конечно, многое решается кешированием. Но я из тех разработчиков, которые не совсем понимают, зачем нужно вводить лишнее звено, если то же самое делается без дополнительных костылей (а технологии внесения и убирания этих изменений существуют уже лет 40 и протестированы не одним поколением программистов -- я говорю об утилитах `patch` и `diff`).

Причём убрать изменения так же просто, как и наложить патч.

Применить изменения к коду: git apply fix-some-problem.diff или patch -p1 fix.diff

Убрать изменения: git apply -R fix-some-problem.diff или patch -R fix.diff

И где здесь сложная часть? Это ничуть не сложнее удаления VQmod файла. При использовании vQmod надо управляться с набором XML файлов. При использовании стандартного подхода -- с набором DIFF файлов. Невелика разница. А преимущества серьёзные.

И вот совсем недавно, в поисках PHP-реализации утилиты `patch` или автоматического конвертера DIFF в vQmod XML, я наткнулся на замечательный вариант: утилиту SafePatch.

http://code.google.com/p/safepatch/

UPD: в связи с закрытием Google Code проект переместился на Github: progerxp/safepatch.

Если кратко и своими словами -- это "менеджер пакетов" (расширений). Но в отличие от vQmod (runtime) он эти изменения вносит непосредственно в исходный код (как и `patch`). При этом понимает формат VQmod и может использовать эти файлы тоже.

Так что те, кто интересуется вопросом - встречайте. По-моему, хороший инструмент. Это не совсем то, что я искал, но отличное готовое решение проблемы.

See also:

twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru ya.ru digg.com friendfeed.com liveinternet.ru livejournal.ru yandex.ru del.icio.us
Более 1000 готовых шаблонов Opencart для интернет-магазинов
Комментариев: 7
  1. Технологии внесения и убирания изменений ничуть не спасают от ада совместимости опенкарта или других продуктов, где не спроектирована изначально нормальная расширяемость. Мне ещё не доводилось обновлять проекты на ос, но судя по тому, как намучался просто делая их, обновлять не следует ни при каких обстоятельствах.

  2. 2013-04-23 в 05:50:45 | Ruslan Brest

    Вадим, не понял, что имеется в виду. Вы предлагаете вообще никаких изменений не вносить? Или наоборот, модифицировать вовсю, но никогда не обновлять базовую версию?

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

  3. Я ничего не предлагаю. Бесполезно-поздно. Просто у других движков есть механизмы хуков, автозагрузки, наследования и т.д.. У того же макссайта, на котором данный сайт, плагины между версиями ломались считанные разы и не все сразу, а отдельные представители и почти случайно. А в основном можно пользоваться плагинами, написанными несколько лет назад.

  4. 2013-04-23 в 16:30:20 | Ruslan Brest
    Я ничего не предлагаю. Бесполезно-поздно.

    Пардон, но до меня всё равно не доходит. В чём суть предложения "как сделать жизнь с Опенкарт лучше"? Здесь и сейчас. С тем, что есть. Ничего вообще не делать и не пользоваться этим движком? Сидеть и ждать, пока всё произойдёт или кто-то добавит туда хуки или напишет другой Опенкарт, идеальный и чудесный? Или может есть какие-то альтернативы разной степени идеальности? Magento и Prestashop не устраивают.

    Суть сказанного, которая до меня доходит -- "всё плохо и кто-то там виноват". Ладно, допустим. Ну и что? Какие-то конкретные предложения есть? Потому что от простой констатации факта, что автор Опенкарта агрессивный ламер, а внутри там полножопие - ничего же вообще не изменится. Это неконструктивно. Предложите какой-нибудь более удачный вариант решения проблемы - это будет полезней и гораздо интересней.

  5. Если в такой постановке вопроса, то да, OC - неизбежное зло и пользоваться им так или иначе придётся. Хотя чем именно не устраивают престо и мадженто? Потому что это у меня кандидаты на исследование, возможно более подходящие мне.

    А если говорить о сравнении SafePatch и vQmod, я предпочту vQmod, потому что у меня на поддержке и доделке сколько-то проектов на разных движках, и пусть я пользуюсь svn\git, но там, где в исходники вносятся изменения, обновление в любом случае превращается в кропотливую ручную работу. Проверить, чтобы все патчи были совместимы с новой версией, проверить, ничего ли не забыл, не внёс ли чего-то лишнего и так далее. Тогда как сторонние плагины если что, одним движением отключаются. Так и здесь, если что, надо всего лишь убрать одну xml’ку, либо работать с кодом, который в любом случае сосредоточен в нескольких файлах, не трогающих движок.

    Вот, кстати, наблюдаю мучения, да: http://rb.labtodo.com/page/better-search-in-opencart-v15-search-description-by-default#comment-120

  6. 2013-04-27 в 02:35:51 | Ruslan Brest

    Не вижу я никакой разницы описанного сценария кропотливой проверки при использовании VQmod и SafePatch. Возможно, вы просто не смотрели, что он из себя представляет. Вся разница там лишь в том, куда вносятся изменения. VQmod хранит их сбоку, в кеше, а SafePatch - такой же менеджер пакетов, но хранит изменения "по месту использования". И включаются-отключаются они столь же незатейливо и одним движением. Не говоря уже о том, что используются те же самые VQmod XML, если они уже есть.

    По части диффов - ну да, всё упирается лишь в отсутствие более-менее автоматизированного "менеджера пакетов" с юзер-френдли лицом. Хотя что мешает хранить подборку diff-ов точно так же, как подборку vqmod-ов, и применять/убирать их пачкой (простым скриптом с циклом из 1-3 строчек) или по-одному? По-моему, принцип абсолютно тот же. Проблема в организации. То есть конкретно взятой голове. Я предпочту работать с исходниками, в которых сразу написано то, что выполняется, и нет накладных рантайм-расходов. Чтобы и с мелими, и большими клиентами технология была одна и отлаженная.

    Вот, кстати, наблюдаю мучения, да: http://rb.labtodo.com/page/better-search-in-opencart-v15-search-description-by-default#comment-120

    Это вы не то наблюдаете. Тогда они пользовались свн-ом и поэтому слияние со своими правками превращалось в большую занозу в заднице. Приходилось много усилий прикладывать: вручную следить за "закладками" (что синхронизировано, а что нет), брать диффы оттуда, накладывать патчи сюда... Сейчас я 99% этой лишней работы не делаю: всё автоматически происходит. Я даже не помню, когда последний раз занимался разрешением конфликтов. Которые, если и возникают, то крошечные.

    Они, конечно, до сих пор не научились пользоваться `git tag` для отметки версий и ветками, но это уже терпимые мелочи. С наличием нативного репозитория на гитхабе всё упростилось на пару порядков. Раньше тоже вытягивал их репо себе в гит, но,во-первых, не сразу до этого додумался, а во-вторых, часть операций всё равно приходилось вручную делать. Так что всех проблем это не решало.

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

  7. спасибо за статью

Оставьте комментарий!

Используйте нормальные имена. Ваш комментарий будет опубликован после проверки.

Имя и сайт используются только при регистрации

Если вы уже зарегистрированы как комментатор или хотите зарегистрироваться, укажите пароль и свой действующий email. При регистрации на указанный адрес придет письмо с кодом активации и ссылкой на ваш персональный аккаунт, где вы сможете изменить свои данные, включая адрес сайта, ник, описание, контакты и т.д., а также подписку на новые комментарии.

Авторизация  Facebook. MaxSiteAuth. Loginza

(обязательно)