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

YuriBtr

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

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

  • Посещение

Репутация

40 Хороший

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

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

Информация

  • Пол
    Мужчина

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

1 145 просмотров профиля
  1. Не секрет, что существующая система смены скина на сайте страдает недостатками. Один из них это то, что смена происходит по запросу типа POST. И после загрузки страницы, ее просто обновить нельзя - например в FireFox появляется сообщение: Также нельзя ограничить список выводимых шаблонов для переключения, дать им псевдонимы и сделать красивый переключатель. Вобщем я пытаюсь переделать систему изменения скинов под себя, и столкнулся с тем, что если просто изменить куку с именем dle_skin на другой шаблон, и запросить страницу по GET, то смены шаблона не произойдет ((( Получается, что необходимо обязательно отправлять POST запрос на сервер с именем нового скина. Мне не понятно, зачем это делать (сервер привязывает выбранный мной шаблон к моей сессии?), ведь нужное мне имя шаблона передается каждый раз в куке dle_skin. Почему бы серверу не брать значение dle_skin именно из куки? P.S. Сам написал, сам ответил: 1. Текущий подход нужен для того, чтобы не было откатов к прежнему шаблону, если сайт открыт одновременно в нескольких вкладках браузера. Так я поменяю куку в одной вкладке, а в той, что была открыта ранее, кука останется старой, и при любом переходе в этой вкладке старый шаблон вернется сам собой. 2. Текущий подход хорош для оптимизации - накладные расходы в каждом запросе на проверку изменился ли скин в куке, превышают пользу от смены скина через куку. Вопрос снимается, тему можно закрывать. Запрос на смену куки буду пробовать делать в отдельном AJAX POST запросе.
  2. О чем Вы вообще говорите? Я имел ввиду редактирование кода IFRAME страницы загружающейся в окне редактора TinyMCE. Этот код зашит в php файл движка. Именно его и надо выносить в шаблон, чтобы можно было легко привести в соответствие внешний вид страницы в WYSIWYG редакторе и отображение страницы на фронте.
  3. Ну допустим проблема со стилями решается плагинами (хотя как она решалась до 13 версии ума не приложу). Но как получить доступ к IFRAME коду страницы, которая загружается в окне редактора? И как в нее передать имя шаблона, чтобы задействовать тему, активную у данного пользователя? В этом вся соль. Если у вас нет рецепта, значит придется писать новый код и создавать еще один плагин (их число уже подошло к 50 на моем сайте), а было бы удобнее все сделать через шаблоны, как это реализовано с предпросмотром (preview.tpl).
  4. К сожалению, с Вашей позицией согласиться не могу. Очень грустно, что мы опять имеем непредсказуемое поведение скрипта. Для чего спрашивается вообще делать поддержку разных шаблонов, если в какой то части сайта все равно будет показываться то, что выбрано "по умолчанию". Конечно вопрос риторический. На мой взгляд это явный баг или недоработка, хотя и некритическая, но неожиданная. Помнится где то давно Вы говорили что дизайнер должен настраивать сам вид текста в окошке редактора. Но для того чтобы это сделать, должны быть инструменты, или Вы считаете нормальным, что после каждого обновления движка - раз в полгода придется переписывать заново стили, которые идут вместе с ядром редактора? Неужели нельзя этот вопрос как то решить и вынести в шаблоны ту часть, которая формируется при выводе редактора?
  5. Ну хорошо, а как вы считаете правильным менять отображение стилей в редакторе для разных шаблонов? Ведь может быть прописан только один стиль. Предлагаю как вариант, придумать пользовательскую переменную, которая будет передаваться в шаблон, а она будет вставляться например в оформление блока и таким образом можно делать различное оформление редактора для разных шаблонов. Но у нас нет доступа к коду страницы, которая загружается в iframe окно редактора. Я же объяснял в той теме. Допустим на сайте есть два шаблона: "Test1" и "Test2". Шаблон Test1 установлен по умолчанию. Но у меня выбран Test2. Если я нажимаю на предпросмотр новости в админке, то у меня загружается preview.tpl из папки шаблона Test1, а должен загружаться из папки Test2. Причем, если я добавляю новость на фронте, и там нажимаю предпросмотр, то preview.tpl загружается правильно - из папки Test2.
  6. Со стилями понятно где их искать, но проблема в том, что я хотел бы подключить стили из активного шаблона, а для этого было бы классно менять шаблон iframe страницы, которая загружается в редактор, чтобы можно было вставить ключевые классы из оформления статей. Я так сделал в preview.tpl и теперь у меня в предпросмотре, при добавлении текста на фронте, загружается нужное оформление без каких-либо правок файлов движка. Кстати такое решение НЕ работает для админки, я написал об этом в баг-репорт и Вы до сих пор не на него не обратили внимания (((
  7. Здравствуйте, мне нужно подогнать оформление текста статей, которые отображаются в редакторе TinyMCE (при полном и быстром редактировании) под стили активного шаблона пользователя. Это необходимо, чтобы редактор правильно расставлял картинки, отступы и цитаты. Кто знает как это сделать правильно, может есть какое то готовое решение? К сожалению на форуме не смог найти информацию по этой теме. Так выглядит текст на фронте Так выглядит текст в редакторе
  8. Вы забыли добавить что в этом стандарте есть еще и прозрачность. А это огромный плюс. Но помимо пока еще плохой поддержки в броузерах, у данного формата нет поддержки среди настольных графических редакторов. Тот же Photoshop, Paint и встроенный просмотровщик фото в Windows 10 не открывает такие файлы. Это точно. Все мы помним ситуацию с микроразметкой и Open Graph тегами )))
  9. А зачем? Вроде как это еще пока плохо поддерживаемый формат. Постоянные проблемы с ним на мобилках.
  10. Это закрытая часть сайта, показать не получится. Про тег {info} не вспомнил, спасибо. Поставил его, и все заработало.
  11. Создаю новый шаблон на основе другого, гарантированно работающего. Заметил, что в новом шаблоне не выводятся сообщения об ошибках или другие системные сообщения, которые идут через шаблон info.tpl Данный файл шаблона НЕ переименовывался, замена этого файла другим с работающего шаблона ничего не дает. В исходном тексте страницы просто отсутствуют классы оформления ошибки и сам текст. Также если удалить данный файл из шаблона, то DLE не напишет "Template not found:" В системе установлен по умолчанию другой шаблон. Но в других шаблонах (которые не по умолчанию) все нормально. Может кто сталкивался с такой проблемой?
  12. Если группе пользователей был назначен шаблон отличный от указанного "по умолчанию" в настройках скрипта, то при предпросмотре новостей из админки, этой группе показывается шаблон предпросмотра (preview.tpl, preview.css) взятый из шаблона "по умолчанию". При этом, если создавать новость на "фронте", то там предпросмотр работает корректно. Вообще кстати надо сказать - генерация предпросмотра очень странная. Чтобы не дублировать стили, приходится полностью очищать preview.css и в preview.tpl подключать css из активного шаблона. Благо тег {THEME} в нем работает корректно. Также доставляет встроенная в код "engine\inc\preview.php" генерация HTML c заголовком "XHTML 1.0 Transitional", в то время как уже вся верстка переведена на HTML5. Все таки хочется полного MVC в скрипте
  13. Странно, зацикливание может быть и в одном шаблоне, если как вы сами написали - вызвать себя же из него. А про ограничение на уровень вложенностей я в документации не видел. Думаю это важный момент - предлагаю отразить его в документации. Хотя в идеале такого ограничения не должно быть, но это конечно вам решать.
  14. Ситуация такая, в main.tpl загружается шаблон правого меню right_menu.tpl через строку {include file="modules/right_menu.tpl"} в шаблоне правой строки идет подгрузка других шаблонов (боковое меню, банеры, информеры) также через строки типа {include file="modules/informer.tpl"} Проблема в том, что в первых двух шаблонах ( main.tpl, right_menu.tpl ) подгрузка шаблонных тегов происходит нормально. Корректно распознаются шаблонные теги [static=имя страницы] [/static] и [not-static=имя страницы] [/not-static] Но в третьем шаблоне уже эти теги не распознаются и выводятся текстом. Это так и должно быть, ли все таки баг? Версия DLE 13.0
  15. На данный момент более менее надежно определить страну посетителя можно только по IP адресу (IP геолокация). Базы этих адресов ведутся специальными компаниями, они их регулярно обновляют, и занимают базы много места, а продают их за большие деньги (например MaxMind). Бюджетный вариант - это подключить бесплатный пакет CloudFlare и анализировать IP заголовок CF-IPCountry - в нем закодирована страна. Но как всегда будут иметь место неточности. Разработчику DLE можно предложить подключить анализатор IP заголовков, и если такой заголовок присутствует, то выводить соответствующий country тег. Думаю если сделать пока только для CloudFlare - будет несложно.