Компонент ''Система патчей''

Ищу единомышленников.

Идея стоит выделки?

Для участия в голосовании необходима регистрация на сайте
#1 3 июня 2014 в 01:42

Доброго времени суток уважаемые коллеги.
Давно пользуюсь данной CMS как обычный рядовой пользователь. Еще со времен версии 1.х крутится в голове у меня одна идея, которую очень хочется реализовать, да не хватает знаний и времени. А с выходом 2.х, которая достойна всех похвал и которая показала себя как продукт о котором я только и мечтал, идея стала биться в голове все настойчивее и настойчивее.

Мои попытки поставить NetBeans IDE и просмотр видео уроков пока итогов не дали. Нет. Поправить пару строк в PHP мне не сложно. Но сами понимаете, этого для написания полноценного компонента очень и очень недостаточно. Так получилось, что в свое время я изучал Perl, а вот освоить PHP так и не заставил себя. А сейчас уже и годы не те, да и свободного времени для «хобби» практически не осталось. Работа, семья, дети и т.д.

Поэтому решил обратится к Вам, уважаемые коллеги, у кого есть желание, возможности и знания в программировании в данной CMS помочь в реализации данной идеи. Мне кажется, что данный компонент будет пользоваться большой популярностью. Похвастается написание ТЗ я тоже не могу, поэтому не судите строго. Если будут возникать вопросы / идеи / пожелания, я их с удовольствием выслушаю и постараюсь внести коррективы в описание.

Многие из Вас кто пользуются данной CMS не раз слышали и применяли так называемые “хуки” "хаки".
Для правильно восприятия в дальнейшем будем называть их патчами или "patch".
Это не большая правка кода файлов системы, для достижения того или иного эффекта, а иногда и исправления небольших ошибок, найденных в системе.

Так вот все, кто пользуются этими патчами, знают главную проблему – обновление релизов!

При обновлении на новый релиз, все «наработки» приходится применять заново. А это значить нужно помнить о всех файлах к которым они применяются, как применяются и главное зачем.
Не знаю, кто и как ведет у себя эту систему используемых патчей, но думаю занятия это не из легких и требующих достаточно времени.

Поэтому и хотелось бы иметь компонент, который бы вел учет всех "patch", помогал их устанавливать/удалять и вообще упростить процедуру применения патчей до «двух кликов».
Данный компонент предназначен только для администратора сайта, поэтому не каких frontend-ов.

Что это дает рядовому пользователю.
Систематизированный учет патчей. Возможность вкл\выкл того или иного "patch", для возможности выяснения «дурного» влияния данного патча на работоспособность системы в целом или отдельного компонента.
Упрощенный обмен патчами при помощи стандартизированных текстовых patch-файлов. Которые можно загрузить в компонент, выгрузить из компонента и поделится с сообществом.
Последовательное применение патчей после обновлении релиза системы, а также контроль возможности применения определенного патча на новом релизе.
Быстрый возврат системы в оригинальное состояние.

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


В панели управления в окне компонента выводится список всех используемых "patch", с возможностью их создания/клонирования/удаления, настройки и фильтрации.
В списке видно название патча, его краткое описание, автор, версия, категория применения, файл к которому он применяется, а также возможность его вкл/выкл.
Обязательным флагом в данном списке должен быть сигнал о том, что данный патч удачно применен или при применении данного патча произошла ошибка.
Под/Над списком патчей находятся кнопки применения патчей, после нажатия которых происходить применение выбранных патчей.

Что из себя представляет ручной ввод.
1. Поле для ввода пути к файлу, к которому будет применен патч.
2. Окно, в котором указываются строчки кода, КОТОРЫЕ необходимо изменить.
3. Окно, в котором указываются строчки кода НА КОТОРЫЕ необходимо изменить строчки из предыдущего окна.
4. Параметры замены. (Заменить все/Заменить 1-раз/ Заменить первый встретившийся искомый код /Заменить последний из встретившихся искомых кодов и т.д.)
5. Кнопка сохранить.
P.S. относительно пункта 4 «параметры замены», есть и другая идея этого пункта, но об этом я напишу отдельно.


Администратор либо вручную создает и вводит данные патча, либо подгружает специальный текстовый patch-файл. Загрузка и выгрузка patch-файлов должна быть как единичная, так с возможностью загрузки/выгрузки всех или выбранных патчей.
После нажатия кнопки «применить» происходить применение выбранных патчей.

После нажатия клавиши применить должно происходить следующее.
Происходит поиск файла, к которому применяется патч и проверка его оригинальности. Проверка на оригинальность основывается на поиск такого-же файла с расширением *.оriginal
Если имеется файл с расширением (*.original) то используем его. Если такого файла нет – то мы копируем искомый файл в *. original (например wiget.php -> wiget.php.original).
Все патчи (если их больше одного) применяются исключительно к коду находящемуся в *.original, тем самым мы исключаем применения патча на уже патченный файл, поэтому перед применением патча или набора патчей, каждый раз (при первом применении или при добавлении нового патча/набора патчей) должна произвестись перезапись изменяемого файла оригинальным файлом. (например wiget.php.original -> wiget.php).
Далее происходит поиск и замена строки кода, указанные в первом окне при создании патча на кода указанный во втором окне.
Если замена произведена без проблем сообщаем что все ок, постановкой соответствующего флага в списке напротив применяемого патча. Если же патч, по каким –либо причинам не смог применится (поменялся код в новом релизе или не правильно указан искомый код), ставится флаг об ошибке.
Что это дает при обновлении на новый релиз.
1. При помощи клавиши «восстановить оригинал» или «удалить все патчи» восстанавливаем оригинальные файлы обычным переименованием файлов *.original в их первозданное состояние.
2. Производим замену файлов на файлы из нового релиза.
3. Пытаемся применить патчи (причем можем это сделать как по одному, так и все скопом), при этом будет видно какие патчи применились, а какие нет, например, из-за изменения кода в новой версии файла, к которому применяется тот или иной патч.
4. Если при применения патча на новом релизе система перестает быть работоспособной, выключаем его и разбираемся уже детально о проблемах применения данного патча. Правим его как нам нужно и снова пытаемся применить.

Для аварийного восстановления системы, после неудачного применения того или иного патча, приведшего к падению системы и не возможности зайти в админку, для отменны неудачно примененного патча, нужен специальный адрес в системе, перейдя по которому, введя логин и пароль администратора, система восстановить оригинальные файлы (все? или последний измененный?).
Ну или ручками заходим, находим файл к которому применили патч и переименовываем его оригинальную версию с расширением *.original в первозданное наименование и снова пробуем зайти в админку для дальнейшей работы.

Как уже я писал в разделе «внешний вид ручного создания патча», 4 пункт «параметры замены» должен давать нам возможность выбора повторяющихся кусков кода, которые попадают под замену.
Конечно можно просто добавить дополнительные (сигнальные) и в тоже время уникальные строчки кода, располагающиеся выше или ниже искомой строки и которые отсутствуют в повторяющихся кусках искомого кода, но это может сильно увеличить объем изменяемого текста, а также увеличит возможность случайного «ломания» кода, путем неверного (неправильно скопированного) указания этих самых «сигнальных строк» в коде на который будет заменятся искомый код.
Так вот было бы не плохо если компонент перед применением патча сначала анализировал файл в которым производится замена кода и сигнализировал об этом.
Например, при анализе было обнаружено 4 места с искомым кодом, компонент показывает место где найден код с показом также нескольких «сигнальных строк» перед и после искомого кода, а также присвоенный номер по порядку куску найденного кода. После этого можно выбрать какой из найденных кусков кода нужно заменить, например, указав в опциях «Заменить 1,3,4 повторяющийся кусок кода», исключив применения патча во втором найденном повторяющемся кусе кода.

Name = названия патча
Description = описание
Version = версия
Date = дата создания
Author = автор данного патча
Find = Код который необходимо заменить
Replace = Код НА который нужно поменять код из секции выше
Option = опции замены.
#2 3 июня 2014 в 09:33
Не хочу показаться невежливым, просто хочу сделать небольшое дополнение.

Английское hook (читается "хук") переводится как "ловушка". Хуки широко применяются в iCMS как точка подключения плагина, который этот хук перехватывает и изменяет. Синоним этого термина — эвент ( англ. "event" — событие) широко применяется Fuze в описании плагинов. Подробнее об этом можно прочесть в этой статье.

Вы пишите, полагаю, о хаках (англ "hack" — рубить, кромсать, курочить). Этот термин подразумевает внесение изменения в код движка. Изменение вносятся в файлы iCMS с целью получения дополнительного функционала. Хаки применяются тогда, когда дополнительный функционал не удается оформить в виде хука и соответствующего ему плагина — например, если изменению подвергается не отдельная переменная или массив, а значительный фрагмент исходного текста.

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

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

Спасибо за идею. До сих пор я все написанные мной по заказу хаки подробно описывал в небольшом текстовом файлике, который оставлял в корне сайта — на тот случай, если апгрейд будет делать другой человек. Прочитав мой файлик, он сразу определится, какие файлы движка ему надо смерживать.
#3 3 июня 2014 в 10:29
Спасибо за поправку. Мне самому при написании все эти "хуки" поднадоели. Для меня юниксойда — всетаки привычней слово patch. И приятней на слух да и правильней это. Писалось вечером, поэтому перепутал хак с хуком. Извените. Счас поправлю текст. А модераторов, если им не сложно, исправить тему на Компонент "Система патчей" (убрать "хуков")
#4 3 июня 2014 в 11:47
В движке форума SMF все дополнения устанавливаются заменой куска кода на другой или дописыванием нужного кода за какой либо строкой. Движок просит лишь один раз настроить доступ по фтп и далее сам открывает нужный файл, ищет заданную строку со значениями и либо заменяет, либо дописывает за/перед ней. Теоретически нечто подобное вроде бы планируется в двойке? Во всяком случае доступ по фтп для обновления двойка уже запрашивает.

Можно такую систему применить и здесь. Тогда можно в компоненте вбивать в каком файле какую строку заменить на что и уже после обновления компонент будет эти изменения воспроизводит. Единственная проблема, это когда такая строка по которой будет вестись поиск будет не совпадать с эталонной ( будет изменена при обновлении), но это решается ручным корректированием.
#5 3 июня 2014 в 12:01

Во всяком случае доступ по фтп для обновления двойка уже запрашивает.

picaboo
Именно эта возможность в двойке и окончательно "добила" меня на написание данной темы.
Хотя есть и другая идея, но тут нужно полное согласие и помощь разработчиков.
В двойке есть возможность "схолпывать" файлы стилей и явовских модулей.
Почему бы не использовать данную возможность?
Предположим после применения патча — патченный файл формируется в определенной папке на сервере, в той же папке cache, хотя правильней всетаки было бы в свою папку — например patchs. И тогда система при обнаружении там патченного файла — брала бы его а, не оригинальный.
Но мне показалось это слишком замороченно и опять таки необходимы правки в самой системе для использования данной возможности.
А при использовании обычного копирования файла в *.original все это на много упрощается. Компонент перестает быть зависим от системы, при большом желании народ думаю её сможет и под 1.x переделать.
Поэтому лучше использовать возможности модуля PHP (ftp) и использовать его по принципу организации обновления в двойке.
#6 3 июня 2014 в 12:08

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

picaboo
Я об этом моменте писал. При наличии сигнального флага применен/ошибка патча — можно видеть какие патчи применились без проблем, а с какими нужно поработать и подкоректировать.
#7 3 июня 2014 в 12:19
ну там так и работает. когда двиг сам не может поменять строку, он выводит окно где пишет что он должен сделать и в какой строке и почему не получилось. руками сам эту правку делаешь и все.

кстати очень удобно. так не только плагины работающие на эвентах можно исползовать, но и полноценные хаки без правки кучи кода в ручную
#8 6 июня 2014 в 20:36
Грустно. :(
#9 6 июня 2014 в 21:37
По-моему в опенкарте нечто подобное реализовано…
#10 7 июня 2014 в 06:43
Скорпион, система не должна дорабатываться хаками. Для этого есть контроллеры и хуки. Если их не хватает — значит надо обновлять версию "из коробки" так, чтобы хватало. А вы хотите компонент/контроллер, который будет считать "костыли" вместо того, чтобы доработать ядро…

Конечно, он имеет право на существование, но я считаю что разумнее перераспределить время на его разработку в сторону доведения "коробки icms 2" до нужного вида. Например, если вас не устраивает виджет контента (меня вот не устраивает) — я просто делаю новый виджет с нужным функционалом, а старый не трогаю — это касается и всего остального функционала.
#11 7 июня 2014 в 08:47
вот если бы новые доработки (хуки, котроллеры) также устанавливались через админку, не через фтп и встраивание нового кода
#12 7 июня 2014 в 10:00
SJen, так то оно может быть и так, но писать новый контролер для того чтобы поменять пару строк в коде… хм… думаю это тоже не особо верное решение.
#13 7 июня 2014 в 20:18

вот если бы новые доработки (хуки, котроллеры) также устанавливались через админку, не через фтп и встраивание нового кода

yury
Так они так и ставятся) В админке грузится инсталятор (архив со всеми файлами) и в админке же все ставится как надо — со всеми запросами и тд. R2 в блогах выкладывал видео про создание такого инсталятора.

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

Идея в том, чтобы не менять пару строк в коде, а писать свой контролер расширяющий возможности уже существующего через систему хуков (или "плагинов" в терминах первой ветки).
#14 20 июня 2014 в 16:04
В связи с тем что местных Гуру сабж не заинтересовал, да и "бюджет" на создания компонента который я могу выделить из семейного бюджета слишком мал, чтобы делать заказ его у спецов — буду пробовать кодить сам (с моим ломанным английским facepalm).
Если конечно уважаемая администрация не будет против неизбежного флейма по данному вопросу в данной теме.
Принимается любая помощь и советы в написании данного дополнения.
Только пожалуйста, давайте все язвительные замечания, по типу "какой нафиг из тебя программист" и т.д будете оставлять при себе.
Да — в PHP я нуб. Но как говорится — учиться не когда не поздно. Поэтому, когда будет появляться свободная минутка, буду пробовать свои силы в этом нелегком деле и вести тут типа отчета.
#15 20 июня 2014 в 16:10
Возможно я начал не с того, c чего следовало бы начать, но так уж получилось что начал я с написания "функции замены кода".
Итог этой "головоломки" — тут.
Пока отложу выстраданный код и хочу заняться созданием необходимых баз данных в mysql
Вы не можете отвечать в этой теме.
Войдите или зарегистрируйтесь, чтобы писать на форуме.
Используя этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.