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

YuriBtr

Клиенты
  • Content Count

    326
  • Joined

  • Last visited

Community Reputation

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

About YuriBtr

  • Rank
    Новичок

Информация

  • Пол
    Мужчина

Recent Profile Visitors

1,357 profile views
  1. Прошу прощения, не понял в каких логах смотреть SQL запрос? И как я говорил ранее, в access.log отсутствует строка обращения к профилю пользователя через админ панель:
  2. Комментарии удалялись модераторами, но это были комментарии других лиц. И в логах таких обращений не много.
  3. Комментарии и их счетчик восстановлены из бекапа. access.log ведется и как я написал, в нем нет никаких обращений к профилю пользователя. Другие обращения конечно можно искать, но надо бы знать что искать. Потому как каждый access.log занимает полгигабайта. Поэтому я и спрашиваю разработчика - какие есть еще методы удаления ВСЕХ комментариев, кроме как проставления галочки в профиле, очистки комментариев из списка пользователей, удаление с фронта последних комментариев по ссылке вида "/index.php?do=lastcomments&userid=1503". В том что это именно массовое удаление сомневаться не приходиться - это самый активный юзер, который написал за 4 года более 20 тысяч комментариев.
  4. По неизвестной причине, были удалены комментарии самого активного пользователя сайта (несколько десятков тысяч комментариев). В логах ничего нет. Нет записей редактирования данного пользователя. Записи редактирования других пользователей имеются, но они более ранние, и там мой IP. Права на администрирование есть только у Админа, доступ к которому есть только у меня. Входы от Админа были только с моего IP. Пароль супер сложный. Попыток неудачного входа не было. База не крашилась - ремонт и оптимизация БД прошла за доли секунды и ничего не изменилось. Остановок сервера не было. При удалении комментариев путем проставления галочки в профиле, в access.log веб сервера регистрируется GET, а потом и POST обращение к адресу вида "/admin.php?mod=editusers&action=edituser&id=1503". Так вот, в access логах за этот период нет обращений к профилю пользователя с таким ID. Версия DLE 13.0 Вопрос разработчику - возможна ли очистка комментариев без логгирования в журнале? Например когда в списке пользователей выбрать " Удалить комментарии", то в Журнал записывается сообщение " Удаление комментариев пользователя с ID ", а если в профиле пользователя выбираешь " Удалить все комментарии?" то данное действие не записывается. Возможно ли с фронта удалить все комментарии пользователя?
  5. Для этого нехватает одной важной функции - модерирования комментариев автором блога только в СВОЕЙ ветке. Без этого функционал DLE как блоговой платформы не имеет особого смысла.
  6. Потому что такая возможность есть. Если бы я знал что эти действия не пишутся в журнал (опять странная логика у разработчика), я бы наверное выключил вообще возможность добавления с фронта, чтобы полностью контролировать сайт. Но что тогда делать с быстрым редактированием непонятно. Оно ведь очень нужно, а изменения через него тоже не пишутся в журнал. Спасибо, я вас и так понял. Вы не можете быть уверенным в том, что проблема не во мне. Но и я не могу быть уверенным в том, что проблема не в скрипте. Конечно я не исключаю внешнего вмешательства - ведь скрипт стоит у хостинг провайдера, там же и БД находится. Мало ли какое обслуживание запускалось или может сбой был в БД при аварийной остановке. Поэтому я просто отправил сюда этот репорт, вдруг у кого нибудь будет похожая проблема, тогда это может стать основанием для более тщательной проверки кода скрипта. Ведь если не сообщать о странностях, то сложные баги выловить будет невозможно.
  7. очень грустно, получается модуль логирования есть, но его легко обмануть. И админ даже не будет подозревать что так работает логика движка. хочется надеяться что так и было, но я точно ничего в БД не менял, переносов не было. Кроме меня никто не смог бы это сделать, к тому же так точечно
  8. Вот это поворот! А как включить логгирование все добавления новостей, даже с фронта? Но вопрос даже не в этом, новость от Администратора точно была опубликована в нужной категории, у меня даже есть скриншот (приходится делать клиенту для подтверждения размещения). но потом таинственным образом у этой новости слетела категория. Если вы говорите, что пишутся все редактирования, то значит не все записывается. Потому что кто-то ее изменил.
  9. Мне понадобилось узнать, кто и когда поменял категорию в новости, созданной 20.03.19 от имени Администратора. При разборе ситуации выяснилось, что в модуле "Список действий в админпанели" вообще нет упоминания что данная новость создавалась. Также нет никаких данных о ее редактировании. Незадолго до этого, в этот же день, Редактором создавалась другая новость, на которую ссылается новость, созданная Администратором. Что интересно по обеим этим новостям никакой информации в логах нет ни за эту дату, ни за более поздние, вплоть до сегодняшнего дня. Искал не только по названиям и URL, но и по адресам картинок, загруженных в новость. Также вручную просмотрел все записи за 20.03.19. Видимо имеет место какой-то баг логгирования. P.S. Сейчас в журнале 3659 страниц по 50 записей (это список действий за год). Что в общем то немного для БД.
  10. Написать что??? Fenom и Smarty уже готовый продукт. Надо их подключать при обработке файлов шаблона с расширением например .tpl2 Подключение шаблонизаторов делается на уровне ядра. Если ядро не позволяет легко подключить шаблонизатор - видимо проблема в архитектуре движка. Отсюда еще одно пожелание, про которое я писал ранее - перевести движок DLE на MVC полностью.
  11. Очень жаль, что у вас это вызывает такое категорическое отторжение. На самом деле в шаблонах DLE очень не хватает возможностей PHP (как это сделано в Smarty или Fenom), если вы не хотите внедрять шаблонизаторы (ведь можно просто создать новый тип шаблонов и обеспечить обратную совместимость), то сделайте хотя бы обработку некоторых PHP инструкций.
  12. ИМХО тогда надо выключать мультикатегории. Иначе у вас будет куча дублей, что отразится на SEO. Или каким то образом указывать главную категорию по которой резолвить новость.
  13. Этот метод ненадежный. Нельзя исключать того, что человек мог руками вбить иной порядковый номер в поле ЧПУ URL в полном редактировании и тем самым сбить нумерацию. В моем случае мы выбираем все что подходит по маске, и в этом результате ищем свободный вариант с добавлением цифры. Его конечно тоже надо оптимизировать, так как чем больше новостей с одним заголовком, тем дольше будет идти проверка, но это уже что-то. Такую же проверку "на лету" надо сделать и при изменении в поле ЧПУ URL в полном редактировании. Пусть движок говорит, что такой URL уже занят, рекомендуем добавить символы справа.
  14. Если определять новость по alt_name может возникнуть ситуация, когда разные новости с одинаковыми заголовками перенаправляются на новость, созданную первой из них. У меня такая проблема возникает с типом ЧПУ №3. Если в течение суток опубликовать например утром и вечером новость с заголовком "Требуются работники". То вечерняя новость не будет открываться вовсе, а будет идти редирект на утреннюю. И хотя редакция у нас маленькая и все проинструктированы, но все равно несколько раз в месяц случаются такие дубликаты ЧПУ URL. Разработчику можно это исправить, добавив при создании новости проверку на уникальность ЧПУ. Если такой URL уже есть во ВСЕЙ базе, то просто добавить какой нибудь порядковый номер справа к ЧПУ URL новой статьи. Это также поможет в тех ситуациях, когда нужно "поднять" статью из архива. То есть опубликовать ее сегодняшним днем, чтобы не дублировать (а ведь это куда важнее для SEO). Поэтому считаю что движок должен при создании статьи учитывать не только ЧПУ URL текущей даты, но и во всей базе. Чтобы не было тормозов при повторных прохождениях по базе, при добавлении порядкового номера (нам ведь тоже надо проверить не существует ли к этому новому ЧПУ URL дубль), нужно делать предварительную выборку (кеширование) всех результатов по маске, которые включают в себя первоначальный ЧПУ URL. И при добавлении порядкового номера проверять уже этот кеш. Либо вести отдельный учет дополнительно присвоенных префиксов.
  15. А я просто показываю свою рекламу на тех ресурсах, которые у меня берут контент в автоматическом режиме и не ставят прямые ссылки. Для этого у меня есть специальная категория с рекламными новостями (реальные клиенты, либо тупо реклама моего сайта). Затем я подключил плагин, который определяет IP посетителя и если он входит в список грабберов, то показывает ему вместо полной новости - мою случайную рекламу. Так неделями моя реклама может висеть на чужих сайтах. Определить множественные обращения с грабберов можно анализируя access.log (его можно подключить как текстовую БД в Excel и сгруппировать по колонке IP, выводя сумму запросов) Вот пример плагина для ТС. Число "17" в запросе $dle_api->take_news надо заменить на номер рекламной категории. Если такой нет, можно сделать пустую категорию и разместить в ней одну новость - с рекламным текстом своего сайта. <?xml version="1.0" encoding="utf-8"?> <dleplugin> <name>Подделка новостей для ньюс-грабберов</name> <description>engine/modules/show.full.php</description> <icon></icon> <version></version> <dleversion></dleversion> <versioncompare>less</versioncompare> <mysqlinstall><![CDATA[]]></mysqlinstall> <mysqlupgrade><![CDATA[]]></mysqlupgrade> <mysqlenable><![CDATA[]]></mysqlenable> <mysqldisable><![CDATA[]]></mysqldisable> <mysqldelete><![CDATA[]]></mysqldelete> <file name="engine/modules/show.full.php"> <operation action="after"> <searchcode><![CDATA[$tpl->set_block ( "'\\[banner_(.*?)\\](.*?)\\[/banner_(.*?)\\]'si", "" );]]></searchcode> <replacecode><![CDATA[ $ip_black_list = array( "mansome.ru" => "87.236.16.5", "inemoras.ru" => "87.236.16.5"); if (in_array($_IP, $ip_black_list)) { include_once("engine/api/api.class.php"); $news_fake = $dle_api->take_news("17", "*", 0, 1, 'rand()', 'desc' ); if (count($news_fake) > 0) { $row['full_story'] = $news_fake[0]['full_story']; } }]]></replacecode> </operation> </file> </dleplugin> Большой размер картинки будет отъедать у вас лимит трафика, и грузить канал. Лучше сделать простой PHP файл в корне сайта и на него направлять воров контента. Содержание файлика простое: <?php sleep(5); echo ("Fuck off");