Задача:
1. клиент установил наше типовое решение Битроник
и
2. внес свои изменения в шаблон сайта и шаблоны компонентов
Но, ведь следующее обновление Типового решения затрет его труды!
Было бы здорово если при этом, система сразу предложила ему сохранить шаблон компонента под другим именем. Но для этого придется хранить все шаблоны компонент типового решения не в шаблоне сайта, а прямо в шаблонах компонентов пространства /bitrix/ — не кашерно.. Либо использовать в типовом решении только компоненты собственного производства, которые будут храниться в пространстве /yenisite/ вместе со своими шаблонами — жутко затратно (изобретение велосипедов, техническая поддержка возрастет на порядки..)
Похоже, что до нас эту задачу никто ранее не решал..
Вариант 0: вносить все правки каждому клиенту вручную.
Минусы:
- не реально..
Вариант 1: Потом, мы думали об автоматическом обновлении Шаблона сайта и всех входящих в него Шаблонов компонентов сразу при установке обновления.
Плюсы:
+ можно вносить правки непосредственно на уже существующем сайте
Минусы:
- сложнее написать скрипт обновления модуля и выпустить такое обновление, которое будет вносить правки пофайлово
- непонятно, как избежать вероятности затереть кастомизированные клиентские шаблоны
Вариант 2: Затем, мы решили обновлять Мастер создания сайта, который клиент, в дальнейшем, должен будет запустить сам, когда будет к этому готов.
Плюсы:
+ легко подготовить и выпустить такое обновление
Особенности:
! Для того чтобы исправить ошибки и получить новые возможности на уже развернутом сайте — клиент должен будет запустить обновленный мастер сам, предварительно подготовившись (скопировав имеющийся шаблон сайта, либо новый шаблон будет создаваться с индексом обновления, а клиент на него потом переключится.) Необходимо будет снабдить его соответствующей инструкцией по правильной установке обновлений.
! При этом мастер не будет повторно создавать демо-данные (инфоблоки, рассылки, опросы, форумы, папки и файлы в публичке итд). Но, должен будет распознать уже созданные, чтобы расставить верные ID объектов во вновь создаваемых файлах публичной части решения содержащих вызовы соответствующих компонент. Так, если уже создан инфоблок новостей и у него есть уже ID — нам надо этот ID подставить в вызов компонента того шаблона, который содержат файлы Шаблона сайта или публички. Для решения этой задачи все ID создаваемых нашим мастером объектов мы заменим на CODE,
! Все включаемые области (контакты, логотип, итд) необходимо вынести из шаблона в корневую папку, чтобы они не перезатирались.
Пока план такой..
У кого-нибудь есть мысли по этому поводу?
UPDATE: Спасибо, Гресс Антону за ценные идеи!
PS: Визредактор при каждом последующем редактировании поста удаляет одну букву в последнем теге -- забавно..
1. клиент установил наше типовое решение Битроник
и
2. внес свои изменения в шаблон сайта и шаблоны компонентов
Но, ведь следующее обновление Типового решения затрет его труды!
Было бы здорово если при этом, система сразу предложила ему сохранить шаблон компонента под другим именем. Но для этого придется хранить все шаблоны компонент типового решения не в шаблоне сайта, а прямо в шаблонах компонентов пространства /bitrix/ — не кашерно.. Либо использовать в типовом решении только компоненты собственного производства, которые будут храниться в пространстве /yenisite/ вместе со своими шаблонами — жутко затратно (изобретение велосипедов, техническая поддержка возрастет на порядки..)
Похоже, что до нас эту задачу никто ранее не решал..
Вариант 0: вносить все правки каждому клиенту вручную.
Минусы:
- не реально..
Вариант 1: Потом, мы думали об автоматическом обновлении Шаблона сайта и всех входящих в него Шаблонов компонентов сразу при установке обновления.
Плюсы:
+ можно вносить правки непосредственно на уже существующем сайте
Минусы:
- сложнее написать скрипт обновления модуля и выпустить такое обновление, которое будет вносить правки пофайлово
- непонятно, как избежать вероятности затереть кастомизированные клиентские шаблоны
Вариант 2: Затем, мы решили обновлять Мастер создания сайта, который клиент, в дальнейшем, должен будет запустить сам, когда будет к этому готов.
Плюсы:
+ легко подготовить и выпустить такое обновление
Особенности:
! Для того чтобы исправить ошибки и получить новые возможности на уже развернутом сайте — клиент должен будет запустить обновленный мастер сам, предварительно подготовившись (скопировав имеющийся шаблон сайта, либо новый шаблон будет создаваться с индексом обновления, а клиент на него потом переключится.) Необходимо будет снабдить его соответствующей инструкцией по правильной установке обновлений.
! При этом мастер не будет повторно создавать демо-данные (инфоблоки, рассылки, опросы, форумы, папки и файлы в публичке итд). Но, должен будет распознать уже созданные, чтобы расставить верные ID объектов во вновь создаваемых файлах публичной части решения содержащих вызовы соответствующих компонент. Так, если уже создан инфоблок новостей и у него есть уже ID — нам надо этот ID подставить в вызов компонента того шаблона, который содержат файлы Шаблона сайта или публички. Для решения этой задачи все ID создаваемых нашим мастером объектов мы заменим на CODE,
! Все включаемые области (контакты, логотип, итд) необходимо вынести из шаблона в корневую папку, чтобы они не перезатирались.
Пока план такой..
У кого-нибудь есть мысли по этому поводу?
UPDATE: Спасибо, Гресс Антону за ценные идеи!
PS: Визредактор при каждом последующем редактировании поста удаляет одну букву в последнем теге -- забавно..