CMS DataLife Engine - Система управления сайтами

YuriBtr

Клиенты
  • Публикаций

    302
  • Зарегистрирован

  • Посещение

Репутация

45 Хороший

Информация о YuriBtr

  • Звание
    Новичок

Информация

  • Пол
    Мужчина

Посетители профиля

1 208 просмотров профиля
  1. Считаю что некоторые теги можно было бы сделать глобальными, то есть доступными во всех файлах шаблона. Таким тегам даже можно присвоить какой нибудь префикс, чтобы не путать с обычными и обеспечить обратную совместимость. Например, я хочу оформить поле ввода своего комментария как на этом форуме - чтобы слева показывался логин и аватарка. Но ни в addcomments.tpl ни в fullstory.tpl не поддерживаются теги {login}, {foto}
  2. Возможно ли стандартными средствами DLE делать вставку новостей из одной категории между новостями при выводе другой категории? Вставка нужна в произвольные места (например 3, 6, 9 позиция). Примерно так: Новости города - Городская новость №1 - Городская новость №2 - Важная районная новость №1 - Городская новость №3 - Городская новость №4 - Важная районная новость №2 - Городская новость №5 - Городская новость №6 - Важная районная новость №3 Похожая тема давно обсуждалась здесь. Может было какое нибудь нормальное решение?
  3. Столкнулся с неприятной вещью, оказывается в базе не хранятся отдельные ответы на опросы, которые встроены в статью (таблица dle_poll_log). В отличие от аналогичной таблицы для "сквозных" голосований (dle_vote_result) в dle_poll_log нет поля answer, из за чего невозможно убрать накрутку. В таблице я вижу множественные одинаковые IP адреса, но убрать ответы этих накрутчиков я уже не могу. Со "сквозными" голосованиями, которые выводятся по тегу {vote} такой проблемы нет. Поэтому прошу добавить поле answer и в dle_poll_log Также, как оказалось скрипт, не контролирует подачу голосов с одного адреса IPv6. Например вот такой адрес 2001:19f0:5:518b:5400:1ff:fece проголосовал аж 400 раз в опросе. Для раздачи денежных призов вышеуказанные недостатки весьма существенны. Прошу добавить контроль адресов в опросах.
  4. Кстати, еще можно сделать разбивку статьи на страницы, и подгружать их динамически, по мере прокрутки. Данный вариант реализации тоже имеется на форуме.
  5. Я вам написал ту рекомендацию, потому как много лет пользуюсь этим движком и убедился что легче все сделать самому, тем более что это JS (то есть фронтенд). Мы кстати уже долго говорим про необходимость внедрения обновленной библиотеки галлереи Highslide (тоже кстати JS) и JQuery, но все идет намного медленнее чем хотелось бы. Но в этом случае хотя бы есть причины - теги Highslide зашиты намертво в тексты статей. В случае с lazyload нет таких проблем. Вы выбираете тот плагин, который вам нравится, (например этот), и внедряете его на уровне шаблона. Для этого нет необходимости вносить правки в код движка, так как мы бьемся как раз за разделение визуальной части и бизнес-логики. И поверьте, есть масса других, более насущных проблем, которые предстоит изменить/внедрить разработчику DLE. Я с вами могу согласиться в том, что DLE нехватает нормальной системы плагинов. То что было сделано в 13 версии, это управление хаками, но не плагинами, ведь если искомый код незначительно меняется - плагин перестает работать. Надо конечно в перспективе разработать нормальную систему точек подключения плагинов, которая не будет зависеть от кода, вызывающего плагин. Но для этого придется пересмотреть всю архитектуру скрипта и проделать огромнейшую работу, в результате чего может пострадать и скорость работы DLE. Тут уже как говорится надо выбирать.
  6. Это JS и делается на уровне шаблона, плагинов много разных. Ищите по слову lazyload
  7. Позвольте мне с вами не согласиться. Эту задачу по другому не решить, редактировать теги придется, для добавления недостающих классов в иерархию тегов, чтобы задействовать основной файл стилей. Плюсы такого подхода очевидны. И считаю, что для этого хорошо подойдет шаблон preview.tpl. А простое копирование стилей из основного файла стилей в /css/myTinyCss.css - это тупая ручная работа, которой можно было бы избежать. Придется это делать каждый раз, когда меняется основной стиль. Впрочем, если вы считаете что это не стоит автоматизировать - ваше право. В данной теме я всего лишь хотел обсудить сложившуюся практику по адаптации стилей и то, как их разделить в зависимости от шаблона. Ответы на свои вопросы я получил, всем спасибо.
  8. Поскольку никакой реакции не было на этот баг, я сам исправил его. В файле engine/inc/preview.php надо найти $tpl->dir = ROOT_DIR.'/templates/'.$config['skin']; и выше добавить if (isset ( $_COOKIE['dle_skin'] ) ) { $_COOKIE['dle_skin'] = trim( totranslit($_COOKIE['dle_skin'], false, false) ); if ($_COOKIE['dle_skin'] != '' AND @is_dir ( ROOT_DIR . '/templates/' . $_COOKIE['dle_skin'] )) { $config['skin'] = $_COOKIE['dle_skin']; } }
  9. Я честно говоря устал вам объяснять. Прочитайте пожалуйста выше мои сообщения. Речь идет об эмуляции страницы просмотра новости в окне IFRAME, загружаемой в редакторе
  10. На приведенном мной скриншоте, видно, что в IFRAME выводится страница, к которой можно подключить пользовательский стиль из своего шаблона и вставить необходимую иерархию тегов. Именно про это я и говорю. Да, но мне не это надо. Я прекрасно знаю ограничения браузера, и поэтому предлагаю выводить страницу в IFRAME с уже подключенным стилем и обрамленную нужными тегами. Для этого и нужен шаблон.
  11. Спасибо за плагин, но задача не просто адаптировать стиль и подгружать его из папки /css/myTinyCss.css текущего шаблона. А заставить в редакторе показывать контент натуралистично, в соответствии с правками, внесенными в основной stylesheet текущего шаблона. Для этого нужно воспроизвести всю минимальную иерархию тегов, в которую обернут текст, выводимый через {content} Данный подход можно реализовать, если вынести код формирования тега страницы, находящейся в IFRAME в отдельный шаблон.
  12. Я всю ветку пытаюсь объяснить, что я хочу сделать следующее: 1. поддержку разных шаблонов в окне редактора TinyMCE 2. заставить скрипт использовать в окне редактора TinyMCE уже готовые стили (переиспользование стилей), из папки текущего шаблона Данный подход обеспечит следующие преимущества: 1. Каждый шаблон на сайте получит свой уникальный внешний вид текста в окне редактора 2. Облегчится адаптация внешнего вида текста в окне редактора, приравняв их отображение к шаблонному (это будет настоящий WYSIWYG, а не компромисс, как сейчас. Достаточно будет прописать в шаблоне IFRAME страницы отсутствующие HTML теги верхнего уровня - обертку текста и подключить стиль) 3. от обновления сайта не будет зависеть внешний вид текста в окне редактора (стили не будут сбрасываться) Похожий подход я реализовал в preview.tpl - теперь при изменении стиля шаблона, вид страницы предпросмотра автоматически меняется под текущие правила CSS. IMHO, для этого нужно заставить IFRAME страницу формироваться по шаблону, который будет находиться в папке выбранного шаблона.
  13. Я всего лишь имел ввиду код страницы, которая загружается в IFRAME окне редактора TinyMCE. Вот образец:
  14. Вы не поняли. По GET запросу я просто получаю страницу. А вот насчет идеи по отправке GET запроса на смену скина, спасибо. Попробую.