Доброго времени суток уважаемые коллеги.
Давно пользуюсь данной 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 = опции замены.