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

YuriBtr

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

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

  • Посещение

Репутация

26 Хороший

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

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

Информация

  • Пол
    Мужчина

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

1 062 просмотра профиля
  1. Когда написал свой коммент полез проверить свои знания и увидел что такое есть, но начиная с MySQL 5.7.8 ))) Но думается мне что внедрение JSON и сопутствующие расходы CPU/Memory будут поболее чем если организовать обычное хранение дополнительных полей в отдельных записях примерно с такой структурой таблицы : id | post_id | extra_type | extra_vlaue Частично мои догадки подтверждаются отзывами юзеров на тостере Позволю процитировать самое понравившееся: В итоге - при удалении доп.поля или изменении его названия вам нужно пробежать по всем статьям и изменить JSON поле полностью.
  2. Если например сделать вот так: {custom xfields="значение 1,значение 2"} Как вы будете парсить json в SQL запросах? IMHO вариант только один - выносить все значения доп.полей в отдельные записи.
  3. MVC - грубо говоря, это подход, применяемый при построении приложения или сайта, позволяющий отделить бизнес-логику (php код) от внешнего вида (шаблоны c HTML, JS, CSS, картинками) и данных (БД MySQL, конфиги). Как видите разработчик DLE уже действует по этой модели (хотя еще попадаются отдельные модули, в которых в коде php встречаются HTML разметка). Данный подход упрощает модификацию движка под свои нужды, сокращает количество повторяющегося кода, а также позволяет отделить данные от кода с целью легкого обновления движка сайта. Было бы классно, если бы разработчик довел бы до конца соответствие DLE модели MVC, чтобы не нужно было править вывод голосовалок, рейтингов и прочего в php коде.
  4. Вся статика типа JS, CSS и файлы картинок должны находиться исключительно в папках шаблона и только. В папке модуля, таким файлам не место, а тем более в коде PHP не место HTML разметке. Это нарушение принципа построения сайта - MVC.
  5. Но это же именно то про что я и говорю. Администратор напишет финальную часть, а редактор после заметит опечатку в своем тексте - полезет править текст, и затрет финальную часть написанную Администратором. Неужели так тяжело понять про что я говорю? У меня доп.поля не используются для переписки, я привел это как пример - чтобы было понятнее. Я на сайте использую Список (Да/Нет) например для вывода статьи в "горячем" блоке новостей через модули BlockPro или Custom. И мне не хочется чтобы каждый Редактор мог влиять на важные настройки.
  6. Извините конечно, но вот вообще не очевидна данная "запланированная возможность". ИМХО здесь проблема в логике работы скрипта. Если у Редактора нет доступа к Дополнительному полю ранее заполненному Администратором, то никакие действия Редактора не должны приводить к изменению/удалению дополнительного поля, тем более такое обычное действие как сохранение новости. В том виде в котором существует функционал ограничения доступа к дополнительным полям, он (функционал) - бессмыслен. Представьте себе: я как Администратор, хочу к новостям делать свои примечания или замечания для журналистов, написавших эту новость. Они кинутся исправлять и затрут все мои замечания, хотя доступа к моему дополнительному полю у них как бы нет. Следовательно это баг, по моему мнению. В общем я не могу даже представить сценария при котором данный функционал в нынешнем виде мог бы использоваться. Если я не прав - прошу написать, в каких use case это может использоваться. Спасибо.
  7. Если в дополнительном поле (типа Список) в опции " Разрешить добавление для следующих групп:" указать группу Администратора, то при редактировании новости у Редакторов исчезает возможность редактировать это поле, и это то поведение, которое мне нужно. Но при изменении новости Редактором - выставленное ранее Администратором значение дополнительного поля попросту пропадает. Нужно при сохранении новости проводить проверку - если у Редактора нет прав на изменение дополнительного поля, то просто не трогать его.
  8. Читайте внимательно вопрос. Речь идет о пользователях с админскими правами, при переходе по ссылке снятой с публикации новости они видят новость как обычно. Мне нужно чтобы таким пользователям показывалось предупреждение что то-что они видят сейчас - обычным пользователям недоступно.
  9. Не хватает пары тегов, показывающих пользователям с админскими правами что данная новость опубликована или не опубликована : [published] новость опубликована [/published] [not-published] новость не опубликована [/not-published]
  10. Нехватает тега {banned} при выводе комментариев.
  11. Да, такое же пожелание я оставлял месяц назад здесь.
  12. Вообще то @temius прав. Приложения на Андроиде лучше браузеров, иначе бы все крупные сайты не делали свои приложения, а гоняли бы посетителей через браузеры ))) Я например изучал разработку под Андроид и могу сказать, что приложения лучше: 1. Полное использование возможностей API Андроида (Android Push, загрузка картинок прямо из коллекции, авторизация и сохранение данных на устройстве). 2. Скорость загрузки. Вы грузите не кучу стилей и скриптов, а "очищенные" страницы и картинки через API DLE, например в формате JSON. 3. Нормальное кеширование данных и оффлайн использование сайта. Написали коммент, но сети нет. Как только сеть появится - коммент отправится на сайт. То же самое с любыми действиями. 4. Удобный и не глючный UI, который выглядит независимо от браузера и размера экрана. Кстати один раз написав клиент для DLE, можно будет его брендировать и продавать как отдельный продукт.
  13. Это можно сделать на уровне дополнительных полей, либо как я сделал - скармливать Яндексу RSS только главной категории новости (с подкатегориями), а всякая реклама, справочники, туда сами не попадут.
  14. 1. Сделайте пожалуйста также поддержку PHP форматов времени для тега {edit-date}. Такой вариант в отличие от {date} не работает ((( 2. Еще хотелось бы иметь расширенные возможности по обработке HTML в самом шаблонизаторе по типу Smarty или Fenom (предпочтительнее) с помощью PHP. На последнем работает BlockPro - из за чего возможная очень мощная обработка. Например через $.php можно подключить много разных PHP функций: $.php.strip_tags() Часто надо чтобы не править файлы движка в некоторых случаях очищать {tags}, {link-category} и прочие шаблонные теги от HTML тегов, оставляя только текст. Или добавлять к ним новые классы для поддержки микроразметки. 3. И еще, чтобы несколько раз не писать, не хватает тега типа: [not-image-x] текст [/not-image-x] Это надо, чтобы в случае, если вдруг все картинки в новости загружены просто в галлерею (через доп.поле) и в тексте картинок нет, то мы можем из галереи дернуть картинку для затравки и микроразметки.
  15. Ну на самом деле $where_date используется не менее чем в 7 файлах движка. Если приведенное вами выражение инициализирует $where_date именно для show.full.php , то конечно перезаписывать его не надо, как я предложил в последнем абзаце.