Автоматическая вставка кода плагина в шаблоны.
Macik |
|
---|---|
Сейчас многи расширения помимо установки через админ панель требуют руками прописывать теги в шаблоны, что для начинающего пользователя может быть затруднительно, и в любом случае неудобно и требует лишнего времени. (Даже мне порой сложно - т.к. не сразу поймешь какой шаблон используется из плагина, из модуля или который лежит в теме оформления...). Поэтому родилась идея использовать в плагинах (там где это возможно) автоматическую вставку (шаблоны при этом остаються неизменными). Реализуется это достаточно просто. Многие Теги вставляются в стандартные для данного плагина места - виджет «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); // обрабатываем тэги шаблона (виджет будет ставлен только при наличии тега) } Думаю код нагляден и понятен. И плагин начинает работать сразу после установки (без каких-либо дополнительных телодвижений) как, например, в Вордпресс. Это еще один шаг к юзабилити и «широким массам» пользователей. Естественно не для каждого плагина и шаблона этот метод можно применить, но большинство дополнений в стиле «еще одна рюшечка на сайт» могут этот метод внедрять.
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
Trustmaster |
|
---|---|
Была мысль вставлять во все шаблоны специальные якоря, к которым привязываются новые теги. Например, {{MENU}}, {{SIDEBAR}}, {{BLOCK}} и так далее. То есть своего рода хуки в TPL-файлах. Останавливает следующее:
Относительно привязки к тегам, озвученной в первом посте:
May the Source be with you!
|
Moool13 |
|
---|---|
Лично мне не нравится идея |
Trustmaster |
|
---|---|
#35853 Moool13: Какая именно и почему? May the Source be with you!
|
Moool13 |
|
---|---|
Не нравится идея автовставки тега в шаблон, по-моему, лучше на странице администрирования плагина в понятном для новичков виде отображать какой тег в какой шаблон вставляется (это уже есть), и за что он отвечает (этого нет, но в большинстве случаев можно догадаться по названию тега). Считаю что этого будет вполне достаточно.
А вопрос:
Понятно, что если tpl файл лежит в теме, править надо его, а перепутать плагин с модулем сложновато будет, ИМХО. |
Nik Samokhvalov |
|
---|---|
Macik, а как твое решение обеспечит настройку порядка вывода сразу нескольких плагинов в одном обработанном теге? Мне кажется, единственное рациональное решение здесь, — это чуть перефразировать твою идею, сделать редактор шаблонов сайта. Установил плагин, открыл шаблон виртуальным редактором — вписал нужный тег, сохранил, закрыл. Пользуйся на здоровье. В прочем, редактор можно поставлять в качестве обычного плагина. P. S. Только про секретарш опять не начинайте… :-) Sorry for my English.
|
Macik |
|
---|---|
#35850 Trustmaster: Да, это тоже первое, что пришло в голову, но поразмысли в быстро отказался.
Да, как я и писал выше подойдет только для некоторого количества простых виджет-стайл плагинов, типа лайки, шаринг, коммментарии и т.п. #35865 Nik Samokhvalov: В общем случае никак. Можно «докручивать» меняя значения «Order» для конкретного плагина, но это тоже дополнительные телодвижения. Что касается противников - по моей задумке (которая реализована в «Social share») режим «автовставки» можно глобально (для всех шаблонов плагина) отключить. К тому же, живой тег в шаблоне имеет приоритет и если он там есть (читай пользователь его туда вставил) - будет использоваться он (автоматическая вставка отключается).
Да. Такой подход реализован например в Вордпресе (только опять не начинайте… :))) ). Причем вызывать его можно даже со страницы информации о плагине, где есть таблица хуков плагина и используеых шаблонов. И дойдут руки реализую… …для этого как мне кажется хорошо подойдет редактор кода ACE. Кроме приятного оформления и схем расцветки, там есть вполне полноценный API (code folding, line wraps, поиск и замена, веделение фрагментов и получение выделенного текста) - в общем мне очень понравился.
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
|
Dieser Beitrag wurde von Macik (am 19. Oktober 2012, 23:14, vor 12 Jahre) bearbeitet |
Trustmaster |
|
---|---|
Боже сохрани нас от CHMOD 777. Если серьёзно:
May the Source be with you!
|
Macik |
|
---|---|
Чего жаждет народ понятно. Но не реализуемо. К тому же доступ на редактирование шаблонов будет только у админа.
Да и причем здесь «777». Файл сохраняет системный скрипт. Соответственно у него права «владельца».
https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
Trustmaster |
|
---|---|
Историческая справка: множество дефейсов сайтов на Seditio было связано с использованием плагина TPL Editor. Данный плагин редактирует шаблоны онлайн, если PHP имеет право на запись оных. Обычно люди не заморачивались, и ставили CHMOD 777 на всё. Но если PHP является владельцем файлов, то эффект примерно тот же и без CHMOD 777. Техника взлома следующая: а) находится дырявый скрипт на сайте, позволяющий выполнять тем или иным образом произвольный пхп-код или записывать файлы; перезаписываются легкодоступные файлы шаблонов или php; б) заводится аккаунт на том же shared-хостинге, использующем глобальный пхп для всех аккаунтов, пишется скрипт, который делает что душе угодно с незащищёнными файлами соседа; в) посредством эксплоита получается непривелегированный доступ к системе, перезаписываются легкодоступные файлы. May the Source be with you!
|
Macik |
|
---|---|
Что-то я запутался. Т.е. если следовать описанному тобой, то логически получается следующее: - если PHP имеет право на запись «644» файлов - то это равносильно «777» и система подвержена риску (и не важно есть ли редактор или нет) - если PHP не имеет прав на запись «644» файлов (или файлы 444) - то все Ок. (тогда опять же не важно есть ли редактор или нет, т.к. он не сможет работать.) В обоих случаях получается, что редактор как бы и не причем?
(Или речь о том, что люди не разбираясь ставят 777? Как мне кажется такие люди скорее всего даже и не смотрят на то какие права на файлы стоят изначально. И вообще мало заботятся о безопасности. https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |
|
Dieser Beitrag wurde von Macik (am 21. Oktober 2012, 02:28, vor 12 Jahre) bearbeitet |
Nik Samokhvalov |
|
---|---|
Сейчас работаю на Битриксе, так там редактор выполнен безо всякого АПИ: открываешь файл, меняешь содержимое, сохраняешь ПХП-скриптом. Доступ к системным файлам, без которых сайт не заведётся — закрыт. Очень удобно, когда нужно внести правки на боевой сайт. Каких-либо проблем с безопасностью замечено не было.
Присоединяюсь, Trustmaster :-) Sorry for my English.
|
Trustmaster |
|
---|---|
Описанная конфигурация хостинга не является оптимальной. С точки зрения безопасности гораздо лучше следующая комбинация: владельцем файлов является владелец учетной записи для данного хоста (например, user), имеющий доступ по sftp/git, а вебсервер/php выполняется от имени другой учётной записи, входящей в ту же группу (например, user-www, входящий в группу user), тогда права на большинство файлов (в частности, php и tpl) следует установить 644 или даже 640, а для директорий типа datas/cache 775 или 770. Конечно, неплохо, если при этом ещё и настроены umask, чтобы не было проблем у user при доступе к файлам в datas, владельцем которых является user-www. И ещё отключить выполнение скриптов в datas. Зачем такие сложности? Если будет выполнен произвольный код от имени юзера php (например, user-www), то он не сможет затронуть основные файлы системы, а сможет повредить только пользовательские файлы (поэтому бекапы никто не отменял). Если короче и без лирических отступлений: все хостинги разные, очень разные. Где-то редактор шаблонов заработает сразу, где-то придётся поменять права на все tpl-файлы (причём на многих хостингах). В любом случае, а особенно когда юзер php относится к категории others, это повышает риск взлома. Я не говорю, что такой редактор будет однозначным злом. Но его следует использовать разумно и не использовать вовсе, если конфигурация хостинга подвержена повышенному риску. Определить последнее обывателю не так-то просто.
Added 1 minutes later: P.S.: не забывайте, что с появлением callback-функций в шаблонах теперь можно практически любые PHP-функции вызывать. May the Source be with you!
|
Macik |
|
---|---|
На моем хостинге впс хостинге апач работает под своим процессом, а вот php5.cgi работает от имени конкретного пользователя. p.s. Callback это да... Безотносительно редактора - может сделать для колбек функций своего рода черный список запрещенных для вызова. во-первых их (пока) не так много используется, во-вторых можно проверку сделать отключаемой. https://github.com/macik
правильный хостинг — https://goo.gl/fjCa1F |