p.s. Callback это да... Безотносительно редактора - может сделать для колбек функций своего рода черный список запрещенных для вызова. во-первых их (пока) не так много используется, во-вторых можно проверку сделать отключаемой.

Если короче и без лирических отступлений: все хостинги разные, очень разные. Где-то редактор шаблонов заработает сразу, где-то придётся поменять права на все tpl-файлы (причём на многих хостингах). В любом случае, а особенно когда юзер php относится к категории others, это повышает риск взлома.

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

Added 1 minutes later:

P.S.: не забывайте, что с появлением callback-функций в шаблонах теперь можно практически любые PHP-функции вызывать.

Сначала нужно реализовать некий API для управления файлами движка по (s)ftp, как это сделано в том же WP. Иначе это будет катастрофа безопасности.

Сейчас работаю на Битриксе, так там редактор выполнен безо всякого АПИ: открываешь файл, меняешь содержимое, сохраняешь ПХП-скриптом. Доступ к системным файлам, без которых сайт не заведётся — закрыт. Очень удобно, когда нужно внести правки на боевой сайт. Каких-либо проблем с безопасностью замечено не было.

Что-то я запутался.

Присоединяюсь, Trustmaster :-)

- если PHP имеет право на запись «644» файлов - то это равносильно «777» и система подвержена риску (и не важно есть ли редактор или нет)

- если PHP не имеет прав на запись «644» файлов (или файлы 444) - то все Ок. (тогда опять же не важно есть ли редактор или нет, т.к. он не сможет работать.)

В обоих случаях получается, что редактор как бы и не причем?

(Или речь о том, что люди не разбираясь ставят 777? Как мне кажется такие люди скорее всего даже и не смотрят на то какие права на файлы стоят изначально. И вообще мало заботятся о безопасности.
К стати про то, какиа права должны стоять на все файлы в Install.txt нет ни слова - там только про «644» для config.php)

К тому же доступ на редактирование шаблонов будет только у админа.

Да и причем здесь «777». Файл сохраняет системный скрипт. Соответственно у него права «владельца».
На файлах стоит «644» - и все отлично сохраняется. Проверил сейчас на вордпрессе: 

Если серьёзно:

• Народ жаждет либо полного автоматизма, либо WYSIWYG. Ace лишь избавит нас от лишней возможности использовать "любимый редактор" + ftp/git. И, конечно, это не автоматизация.
• Сначала нужно реализовать некий API для управления файлами движка по (s)ftp, как это сделано в том же WP. Иначе это будет катастрофа безопасности.

Была мысль вставлять во все шаблоны специальные якоря, к которым привязываются новые теги. Например, {{MENU}}, {{SIDEBAR}}, {{BLOCK}} и так далее. То есть своего рода хуки в TPL-файлах. Останавливает следующее:

Да, это тоже первое, что пришло в голову, но поразмысли в быстро отказался.  

Относительно привязки к тегам, озвученной в первом посте:

• Шаблоны засоряются меньше, но различие в присутствующих тегах сохраняется.
• По стилизации руки у дизайнеров связаны, поскольку новый контент просто приклеивается к тегу. Многие плагины будут отображаться криво.
• Не самый простой код встраивания в PHP-файле.
• Потери производительности.

Да, как я и писал выше подойдет только для некоторого количества простых виджет-стайл плагинов, типа лайки, шаринг, коммментарии и т.п.

#35865 Nik Samokhvalov:

Macik, а как твое решение обеспечит настройку порядка вывода сразу нескольких плагинов в одном обработанном теге?

В общем случае никак. Можно «докручивать» меняя значения «Order» для конкретного плагина, но это тоже дополнительные телодвижения. 

Что касается противников - по моей задумке (которая реализована в «Social share») режим «автовставки» можно глобально (для всех шаблонов плагина) отключить. К тому же, живой тег в шаблоне имеет приоритет и если он там есть (читай пользователь его туда вставил) - будет использоваться он (автоматическая вставка отключается). 

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

P. S. Только про секретарш опять не начинайте… :-)

Да. Такой подход реализован например в Вордпресе (только опять не начинайте… :))) ).  Причем вызывать его можно даже со страницы информации о плагине, где есть таблица хуков плагина и используеых шаблонов. И дойдут руки реализую…

…для этого как мне кажется хорошо подойдет редактор кода ACE. Кроме приятного оформления и схем расцветки, там есть вполне полноценный API (code folding, line wraps, поиск и замена, веделение фрагментов и получение выделенного текста) - в общем мне очень понравился.

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

P. S. Только про секретарш опять не начинайте… :-)

Какая именно и почему?

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

А вопрос:

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

Понятно, что если tpl файл лежит в теме, править надо его, а перепутать плагин с модулем сложновато будет, ИМХО.

Лично мне не нравится идея

Какая именно и почему?

• Засорение шаблонов конструкциями, которые ничего не отображают.
• Сайты разные, набор таких хуков будет различаться в любом случае. А многие просто забудут их добавить в шаблон.
• Возможности по стилизации ограничены, некоторые плагины будут отображаться криво.
• Потери производительности.

Относительно привязки к тегам, озвученной в первом посте:

• Шаблоны засоряются меньше, но различие в присутствующих тегах сохраняется.
• По стилизации руки у дизайнеров связаны, поскольку новый контент просто приклеивается к тегу. Многие плагины будут отображаться криво.
• Не самый простой код встраивания в PHP-файле.
• Потери производительности.

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

Реализуется это достаточно просто.

Многие Теги вставляются в стандартные для данного плагина места - виджет «like» в  конец страницы, виджет «userwall» на страницу профиля пользователя и т.п.

Мы можем не заставлять пользователя делать это в ручную, а автоматизировать процесс путем переопределения (дополнения) уже стандартных присутствующих в системе и обработанных тегов.

На примере плагина «social_share» простой код: 

// проверяем включен ли режим автоматической вставки (по умолчанию включен)	
// и на отсутствие тегов плагина в шаблоне 
if ($socs_cfg['auto_insert'] && !(method_exists('XTemplate','hasTag') && $t->hasTag('SOCIAL_SHARE'))) {
	$t->vars['PAGE_TEXT'] .= $code; // автоматически вставляем виджет в конец страницы
} else { 
	$t->assign('SOCIAL_SHARE',$code); // обрабатываем тэги шаблона (виджет будет ставлен только при наличии тега)
}

Думаю код нагляден и понятен. И плагин начинает работать сразу после установки (без каких-либо дополнительных телодвижений) как, например, в Вордпресс. Это еще один шаг к юзабилити и «широким массам» пользователей.

Естественно не для каждого плагина и шаблона этот метод можно применить, но большинство дополнений в стиле «еще одна рюшечка на сайт» могут этот метод внедрять.