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

YuriBtr

Клиенты
  • Content Count

    327
  • Joined

  • Last visited

Community Reputation

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

About YuriBtr

  • Rank
    Новичок

Информация

  • Пол
    Мужчина

Recent Profile Visitors

1,402 profile views
  1. В этом году я сделал первый сайт на Вордпресс на трех языках - причем с кастомными типами записей, кастомными полями, кастомной таксономией, заливкой материалов/фоток через API. На все ушло 3 месяца без начальных знаний Wordpress. Такой гибкости и вариантов решения проблем я еще не видел. Это просто космос. Его хуки это нечто, а шаблонизатор с полной поддержкой PHP круть. Плюс масса уроков, документации, готовых плагинов. Хотя конечно PHP знать обязательно, хотя бы на начальном уровне. Об этом я уже писал здесь год назад и еще раньше. В DLE слишком мало возможностей. Да он быстр как степная лань, и легковесный. Но если ты хочешь хоть немного отойти от навязываемого разработчиком стиля (таблицы поиска, вывод кнопок и списков) - то надо писать кучу плагинов чтобы менять ядро. Потому как разделение кода разработчик не сделал. Ладно бы были нормальные плагины, с вызовами через хуки. Но плагин, который меняет просто кусок кода на другой - это хак. В работоспособности которого нельзя быть уверенным после очередного обновления. Это плохая идея, хотя конечно лучше чем вообще ничего. Про минимальную обработку PHP в шаблонизаторе (как в Smarty, Fenom) речь не идет. Хотя это бы на порядок облегчило написание шаблонов и избавило бы от написания некоторых плагинов. А ведь можно было бы сделать новый тип шаблонов, и обрабатывать их новым шаблонизатором, чтобы сохранить обратную совместимость. Подводя итог скажу: IMHO разработчик DLE нацелил движок на сайты с большой посещаемостью (тысячи и десятки тысяч уников в день). Об этом говорит то, что DLE платный (бесплатная демо версия не обновляется и на ней масса ограничений). Оптимизация и простота движка DLE позволяет экономить на хостинге, а простая система шаблонов позволяет экономить на верстальщиках. Однако все более-менее серьезные проекты требуют авторских доработок. А поскольку такие сайты наверняка приносят доход, который позволяет вложиться в шаблон хотя бы один раз при создании сайта - то почему бы не дать такую возможность клиентам? А школьникам пусть остается Джумла или Вордпресс с их "one-click install". Все равно их сайты не будут настолько нагружены, чтобы они увидели разницу. Да и денег платить они не привыкли.
  2. Прошу прощения, не понял в каких логах смотреть SQL запрос? И как я говорил ранее, в access.log отсутствует строка обращения к профилю пользователя через админ панель:
  3. Комментарии удалялись модераторами, но это были комментарии других лиц. И в логах таких обращений не много.
  4. Комментарии и их счетчик восстановлены из бекапа. access.log ведется и как я написал, в нем нет никаких обращений к профилю пользователя. Другие обращения конечно можно искать, но надо бы знать что искать. Потому как каждый access.log занимает полгигабайта. Поэтому я и спрашиваю разработчика - какие есть еще методы удаления ВСЕХ комментариев, кроме как проставления галочки в профиле, очистки комментариев из списка пользователей, удаление с фронта последних комментариев по ссылке вида "/index.php?do=lastcomments&userid=1503". В том что это именно массовое удаление сомневаться не приходиться - это самый активный юзер, который написал за 4 года более 20 тысяч комментариев.
  5. По неизвестной причине, были удалены комментарии самого активного пользователя сайта (несколько десятков тысяч комментариев). В логах ничего нет. Нет записей редактирования данного пользователя. Записи редактирования других пользователей имеются, но они более ранние, и там мой IP. Права на администрирование есть только у Админа, доступ к которому есть только у меня. Входы от Админа были только с моего IP. Пароль супер сложный. Попыток неудачного входа не было. База не крашилась - ремонт и оптимизация БД прошла за доли секунды и ничего не изменилось. Остановок сервера не было. При удалении комментариев путем проставления галочки в профиле, в access.log веб сервера регистрируется GET, а потом и POST обращение к адресу вида "/admin.php?mod=editusers&action=edituser&id=1503". Так вот, в access логах за этот период нет обращений к профилю пользователя с таким ID. Версия DLE 13.0 Вопрос разработчику - возможна ли очистка комментариев без логгирования в журнале? Например когда в списке пользователей выбрать " Удалить комментарии", то в Журнал записывается сообщение " Удаление комментариев пользователя с ID ", а если в профиле пользователя выбираешь " Удалить все комментарии?" то данное действие не записывается. Возможно ли с фронта удалить все комментарии пользователя?
  6. Для этого нехватает одной важной функции - модерирования комментариев автором блога только в СВОЕЙ ветке. Без этого функционал DLE как блоговой платформы не имеет особого смысла.
  7. Потому что такая возможность есть. Если бы я знал что эти действия не пишутся в журнал (опять странная логика у разработчика), я бы наверное выключил вообще возможность добавления с фронта, чтобы полностью контролировать сайт. Но что тогда делать с быстрым редактированием непонятно. Оно ведь очень нужно, а изменения через него тоже не пишутся в журнал. Спасибо, я вас и так понял. Вы не можете быть уверенным в том, что проблема не во мне. Но и я не могу быть уверенным в том, что проблема не в скрипте. Конечно я не исключаю внешнего вмешательства - ведь скрипт стоит у хостинг провайдера, там же и БД находится. Мало ли какое обслуживание запускалось или может сбой был в БД при аварийной остановке. Поэтому я просто отправил сюда этот репорт, вдруг у кого нибудь будет похожая проблема, тогда это может стать основанием для более тщательной проверки кода скрипта. Ведь если не сообщать о странностях, то сложные баги выловить будет невозможно.
  8. очень грустно, получается модуль логирования есть, но его легко обмануть. И админ даже не будет подозревать что так работает логика движка. хочется надеяться что так и было, но я точно ничего в БД не менял, переносов не было. Кроме меня никто не смог бы это сделать, к тому же так точечно
  9. Вот это поворот! А как включить логгирование все добавления новостей, даже с фронта? Но вопрос даже не в этом, новость от Администратора точно была опубликована в нужной категории, у меня даже есть скриншот (приходится делать клиенту для подтверждения размещения). но потом таинственным образом у этой новости слетела категория. Если вы говорите, что пишутся все редактирования, то значит не все записывается. Потому что кто-то ее изменил.
  10. Мне понадобилось узнать, кто и когда поменял категорию в новости, созданной 20.03.19 от имени Администратора. При разборе ситуации выяснилось, что в модуле "Список действий в админпанели" вообще нет упоминания что данная новость создавалась. Также нет никаких данных о ее редактировании. Незадолго до этого, в этот же день, Редактором создавалась другая новость, на которую ссылается новость, созданная Администратором. Что интересно по обеим этим новостям никакой информации в логах нет ни за эту дату, ни за более поздние, вплоть до сегодняшнего дня. Искал не только по названиям и URL, но и по адресам картинок, загруженных в новость. Также вручную просмотрел все записи за 20.03.19. Видимо имеет место какой-то баг логгирования. P.S. Сейчас в журнале 3659 страниц по 50 записей (это список действий за год). Что в общем то немного для БД.
  11. Написать что??? Fenom и Smarty уже готовый продукт. Надо их подключать при обработке файлов шаблона с расширением например .tpl2 Подключение шаблонизаторов делается на уровне ядра. Если ядро не позволяет легко подключить шаблонизатор - видимо проблема в архитектуре движка. Отсюда еще одно пожелание, про которое я писал ранее - перевести движок DLE на MVC полностью.
  12. Очень жаль, что у вас это вызывает такое категорическое отторжение. На самом деле в шаблонах DLE очень не хватает возможностей PHP (как это сделано в Smarty или Fenom), если вы не хотите внедрять шаблонизаторы (ведь можно просто создать новый тип шаблонов и обеспечить обратную совместимость), то сделайте хотя бы обработку некоторых PHP инструкций.
  13. ИМХО тогда надо выключать мультикатегории. Иначе у вас будет куча дублей, что отразится на SEO. Или каким то образом указывать главную категорию по которой резолвить новость.
  14. Этот метод ненадежный. Нельзя исключать того, что человек мог руками вбить иной порядковый номер в поле ЧПУ URL в полном редактировании и тем самым сбить нумерацию. В моем случае мы выбираем все что подходит по маске, и в этом результате ищем свободный вариант с добавлением цифры. Его конечно тоже надо оптимизировать, так как чем больше новостей с одним заголовком, тем дольше будет идти проверка, но это уже что-то. Такую же проверку "на лету" надо сделать и при изменении в поле ЧПУ URL в полном редактировании. Пусть движок говорит, что такой URL уже занят, рекомендуем добавить символы справа.
  15. Если определять новость по alt_name может возникнуть ситуация, когда разные новости с одинаковыми заголовками перенаправляются на новость, созданную первой из них. У меня такая проблема возникает с типом ЧПУ №3. Если в течение суток опубликовать например утром и вечером новость с заголовком "Требуются работники". То вечерняя новость не будет открываться вовсе, а будет идти редирект на утреннюю. И хотя редакция у нас маленькая и все проинструктированы, но все равно несколько раз в месяц случаются такие дубликаты ЧПУ URL. Разработчику можно это исправить, добавив при создании новости проверку на уникальность ЧПУ. Если такой URL уже есть во ВСЕЙ базе, то просто добавить какой нибудь порядковый номер справа к ЧПУ URL новой статьи. Это также поможет в тех ситуациях, когда нужно "поднять" статью из архива. То есть опубликовать ее сегодняшним днем, чтобы не дублировать (а ведь это куда важнее для SEO). Поэтому считаю что движок должен при создании статьи учитывать не только ЧПУ URL текущей даты, но и во всей базе. Чтобы не было тормозов при повторных прохождениях по базе, при добавлении порядкового номера (нам ведь тоже надо проверить не существует ли к этому новому ЧПУ URL дубль), нужно делать предварительную выборку (кеширование) всех результатов по маске, которые включают в себя первоначальный ЧПУ URL. И при добавлении порядкового номера проверять уже этот кеш. Либо вести отдельный учет дополнительно присвоенных префиксов.