Jump to content

YuriBtr

Клиенты
  • Content Count

    329
  • Joined

  • Last visited

Community Reputation

56 Очень хороший

About YuriBtr

  • Rank
    Новичок

Информация

  • Пол
    Мужчина

Recent Profile Visitors

1,541 profile views
  1. Было бы неплохо сделать версионирование материалов (вариант как редакции в Вордпресс вполне бы устроил). А то лезут несколько человек исправлять статью, а потом не разберешь, кто что менял и кого наказывать. Да и откатиться было бы неплохо, если в спешке затерли какой нибудь абзац. И проверку дублей ЧПУ URL при сохранении очень хотелось бы увидеть.
  2. В этом году я сделал первый сайт на Вордпресс на трех языках - причем с кастомными типами записей, кастомными полями, кастомной таксономией, заливкой материалов/фоток через API. На все ушло 3 месяца без начальных знаний Wordpress. Такой гибкости и вариантов решения проблем я еще не видел. Это просто космос. Его хуки это нечто, а шаблонизатор с полной поддержкой PHP круть. Плюс масса уроков, документации, готовых плагинов. Хотя конечно PHP знать обязательно, хотя бы на начальном уровне. Об этом я уже писал здесь год назад и еще раньше. В DLE слишком мало возможностей. Да он быстр как степная лань, и легковесный. Но если ты хочешь хоть немного отойти от навязываемого разработчиком стиля (таблицы поиска, вывод кнопок и списков) - то надо писать кучу плагинов чтобы менять ядро. Потому как разделение кода разработчик не сделал. Ладно бы были нормальные плагины, с вызовами через хуки. Но плагин, который меняет просто кусок кода на другой - это хак. В работоспособности которого нельзя быть уверенным после очередного обновления. Это плохая идея, хотя конечно лучше чем вообще ничего. Про минимальную обработку PHP в шаблонизаторе (как в Smarty, Fenom) речь не идет. Хотя это бы на порядок облегчило написание шаблонов и избавило бы от написания некоторых плагинов. А ведь можно было бы сделать новый тип шаблонов, и обрабатывать их новым шаблонизатором, чтобы сохранить обратную совместимость. Подводя итог скажу: IMHO разработчик DLE нацелил движок на сайты с большой посещаемостью (тысячи и десятки тысяч уников в день). Об этом говорит то, что DLE платный (бесплатная демо версия не обновляется и на ней масса ограничений). Оптимизация и простота движка DLE позволяет экономить на хостинге, а простая система шаблонов позволяет экономить на верстальщиках. Однако все более-менее серьезные проекты требуют авторских доработок. А поскольку такие сайты наверняка приносят доход, который позволяет вложиться в шаблон хотя бы один раз при создании сайта - то почему бы не дать такую возможность клиентам? А школьникам пусть остается Джумла или Вордпресс с их "one-click install". Все равно их сайты не будут настолько нагружены, чтобы они увидели разницу. Да и денег платить они не привыкли.
  3. Прошу прощения, не понял в каких логах смотреть SQL запрос? И как я говорил ранее, в access.log отсутствует строка обращения к профилю пользователя через админ панель:
  4. Комментарии удалялись модераторами, но это были комментарии других лиц. И в логах таких обращений не много.
  5. Комментарии и их счетчик восстановлены из бекапа. access.log ведется и как я написал, в нем нет никаких обращений к профилю пользователя. Другие обращения конечно можно искать, но надо бы знать что искать. Потому как каждый access.log занимает полгигабайта. Поэтому я и спрашиваю разработчика - какие есть еще методы удаления ВСЕХ комментариев, кроме как проставления галочки в профиле, очистки комментариев из списка пользователей, удаление с фронта последних комментариев по ссылке вида "/index.php?do=lastcomments&userid=1503". В том что это именно массовое удаление сомневаться не приходиться - это самый активный юзер, который написал за 4 года более 20 тысяч комментариев.
  6. По неизвестной причине, были удалены комментарии самого активного пользователя сайта (несколько десятков тысяч комментариев). В логах ничего нет. Нет записей редактирования данного пользователя. Записи редактирования других пользователей имеются, но они более ранние, и там мой IP. Права на администрирование есть только у Админа, доступ к которому есть только у меня. Входы от Админа были только с моего IP. Пароль супер сложный. Попыток неудачного входа не было. База не крашилась - ремонт и оптимизация БД прошла за доли секунды и ничего не изменилось. Остановок сервера не было. При удалении комментариев путем проставления галочки в профиле, в access.log веб сервера регистрируется GET, а потом и POST обращение к адресу вида "/admin.php?mod=editusers&action=edituser&id=1503". Так вот, в access логах за этот период нет обращений к профилю пользователя с таким ID. Версия DLE 13.0 Вопрос разработчику - возможна ли очистка комментариев без логгирования в журнале? Например когда в списке пользователей выбрать " Удалить комментарии", то в Журнал записывается сообщение " Удаление комментариев пользователя с ID ", а если в профиле пользователя выбираешь " Удалить все комментарии?" то данное действие не записывается. Возможно ли с фронта удалить все комментарии пользователя?
  7. Заметил, что счетчик {comments-num} выдает неправильные результаты. Почти во всех статьях, где есть комментарии, счетчик показывает на 2-3 комментария больше чем на самом деле было добавлено (даже с учетом удаленных и не прошедших модерацию). Если комментариев не было вовсе, то счетчик правильно показывает ноль. Версия DLE 13.0 Плагинов, которые меняли бы счетчик комментариев - нет.
  8. Не секрет, что существующая система смены скина на сайте страдает недостатками. Один из них это то, что смена происходит по запросу типа POST. И после загрузки страницы, ее просто обновить нельзя - например в FireFox появляется сообщение: Также нельзя ограничить список выводимых шаблонов для переключения, дать им псевдонимы и сделать красивый переключатель. Вобщем я пытаюсь переделать систему изменения скинов под себя, и столкнулся с тем, что если просто изменить куку с именем dle_skin на другой шаблон, и запросить страницу по GET, то смены шаблона не произойдет ((( Получается, что необходимо обязательно отправлять POST запрос на сервер с именем нового скина. Мне не понятно, зачем это делать (сервер привязывает выбранный мной шаблон к моей сессии?), ведь нужное мне имя шаблона передается каждый раз в куке dle_skin. Почему бы серверу не брать значение dle_skin именно из куки? P.S. Сам написал, сам ответил: 1. Текущий подход нужен для того, чтобы не было откатов к прежнему шаблону, если сайт открыт одновременно в нескольких вкладках браузера. Так я поменяю куку в одной вкладке, а в той, что была открыта ранее, кука останется старой, и при любом переходе в этой вкладке старый шаблон вернется сам собой. 2. Текущий подход хорош для оптимизации - накладные расходы в каждом запросе на проверку изменился ли скин в куке, превышают пользу от смены скина через куку. Вопрос снимается, тему можно закрывать. Запрос на смену куки буду пробовать делать в отдельном AJAX POST запросе.
  9. Ситуация такая, в 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
×
×
  • Create New...