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

YuriBtr

Клиенты
  • Content count

    322
  • Joined

  • Last visited

Community Reputation

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

About YuriBtr

  • Rank
    Новичок

Информация

  • Пол
    Мужчина

Recent Profile Visitors

1,315 profile views
  1. Для этого нехватает одной важной функции - модерирования комментариев автором блога только в СВОЕЙ ветке. Без этого функционал DLE как блоговой платформы не имеет особого смысла.
  2. Потому что такая возможность есть. Если бы я знал что эти действия не пишутся в журнал (опять странная логика у разработчика), я бы наверное выключил вообще возможность добавления с фронта, чтобы полностью контролировать сайт. Но что тогда делать с быстрым редактированием непонятно. Оно ведь очень нужно, а изменения через него тоже не пишутся в журнал. Спасибо, я вас и так понял. Вы не можете быть уверенным в том, что проблема не во мне. Но и я не могу быть уверенным в том, что проблема не в скрипте. Конечно я не исключаю внешнего вмешательства - ведь скрипт стоит у хостинг провайдера, там же и БД находится. Мало ли какое обслуживание запускалось или может сбой был в БД при аварийной остановке. Поэтому я просто отправил сюда этот репорт, вдруг у кого нибудь будет похожая проблема, тогда это может стать основанием для более тщательной проверки кода скрипта. Ведь если не сообщать о странностях, то сложные баги выловить будет невозможно.
  3. очень грустно, получается модуль логирования есть, но его легко обмануть. И админ даже не будет подозревать что так работает логика движка. хочется надеяться что так и было, но я точно ничего в БД не менял, переносов не было. Кроме меня никто не смог бы это сделать, к тому же так точечно
  4. Вот это поворот! А как включить логгирование все добавления новостей, даже с фронта? Но вопрос даже не в этом, новость от Администратора точно была опубликована в нужной категории, у меня даже есть скриншот (приходится делать клиенту для подтверждения размещения). но потом таинственным образом у этой новости слетела категория. Если вы говорите, что пишутся все редактирования, то значит не все записывается. Потому что кто-то ее изменил.
  5. Мне понадобилось узнать, кто и когда поменял категорию в новости, созданной 20.03.19 от имени Администратора. При разборе ситуации выяснилось, что в модуле "Список действий в админпанели" вообще нет упоминания что данная новость создавалась. Также нет никаких данных о ее редактировании. Незадолго до этого, в этот же день, Редактором создавалась другая новость, на которую ссылается новость, созданная Администратором. Что интересно по обеим этим новостям никакой информации в логах нет ни за эту дату, ни за более поздние, вплоть до сегодняшнего дня. Искал не только по названиям и URL, но и по адресам картинок, загруженных в новость. Также вручную просмотрел все записи за 20.03.19. Видимо имеет место какой-то баг логгирования. P.S. Сейчас в журнале 3659 страниц по 50 записей (это список действий за год). Что в общем то немного для БД.
  6. Написать что??? Fenom и Smarty уже готовый продукт. Надо их подключать при обработке файлов шаблона с расширением например .tpl2 Подключение шаблонизаторов делается на уровне ядра. Если ядро не позволяет легко подключить шаблонизатор - видимо проблема в архитектуре движка. Отсюда еще одно пожелание, про которое я писал ранее - перевести движок DLE на MVC полностью.
  7. Очень жаль, что у вас это вызывает такое категорическое отторжение. На самом деле в шаблонах DLE очень не хватает возможностей PHP (как это сделано в Smarty или Fenom), если вы не хотите внедрять шаблонизаторы (ведь можно просто создать новый тип шаблонов и обеспечить обратную совместимость), то сделайте хотя бы обработку некоторых PHP инструкций.
  8. ИМХО тогда надо выключать мультикатегории. Иначе у вас будет куча дублей, что отразится на SEO. Или каким то образом указывать главную категорию по которой резолвить новость.
  9. Этот метод ненадежный. Нельзя исключать того, что человек мог руками вбить иной порядковый номер в поле ЧПУ URL в полном редактировании и тем самым сбить нумерацию. В моем случае мы выбираем все что подходит по маске, и в этом результате ищем свободный вариант с добавлением цифры. Его конечно тоже надо оптимизировать, так как чем больше новостей с одним заголовком, тем дольше будет идти проверка, но это уже что-то. Такую же проверку "на лету" надо сделать и при изменении в поле ЧПУ URL в полном редактировании. Пусть движок говорит, что такой URL уже занят, рекомендуем добавить символы справа.
  10. Если определять новость по alt_name может возникнуть ситуация, когда разные новости с одинаковыми заголовками перенаправляются на новость, созданную первой из них. У меня такая проблема возникает с типом ЧПУ №3. Если в течение суток опубликовать например утром и вечером новость с заголовком "Требуются работники". То вечерняя новость не будет открываться вовсе, а будет идти редирект на утреннюю. И хотя редакция у нас маленькая и все проинструктированы, но все равно несколько раз в месяц случаются такие дубликаты ЧПУ URL. Разработчику можно это исправить, добавив при создании новости проверку на уникальность ЧПУ. Если такой URL уже есть во ВСЕЙ базе, то просто добавить какой нибудь порядковый номер справа к ЧПУ URL новой статьи. Это также поможет в тех ситуациях, когда нужно "поднять" статью из архива. То есть опубликовать ее сегодняшним днем, чтобы не дублировать (а ведь это куда важнее для SEO). Поэтому считаю что движок должен при создании статьи учитывать не только ЧПУ URL текущей даты, но и во всей базе. Чтобы не было тормозов при повторных прохождениях по базе, при добавлении порядкового номера (нам ведь тоже надо проверить не существует ли к этому новому ЧПУ URL дубль), нужно делать предварительную выборку (кеширование) всех результатов по маске, которые включают в себя первоначальный ЧПУ URL. И при добавлении порядкового номера проверять уже этот кеш. Либо вести отдельный учет дополнительно присвоенных префиксов.
  11. А я просто показываю свою рекламу на тех ресурсах, которые у меня берут контент в автоматическом режиме и не ставят прямые ссылки. Для этого у меня есть специальная категория с рекламными новостями (реальные клиенты, либо тупо реклама моего сайта). Затем я подключил плагин, который определяет 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");
  12. Именно так и сделано, но как правильно заметил alex32, это не влияет на отправку через do=feedback&user=10 За идею с редиректом - спасибо, понадобились следующие правила: исходный адрес: /?*user=*&do=feedback* адрес для редиректа: /?do=feedback исходный адрес: /?*do=feedback*&user=* адрес для редиректа: /?do=feedback исходный адрес: /index.php?*user=*&do=feedback* адрес для редиректа: /index.php?do=feedback исходный адрес: /index.php?*do=feedback*&user=* адрес для редиректа: /index.php?do=feedback Но этот способ не защитит от прямой подмены ID в HTML коде, при отправке запроса. Выходит что единственная надежная защита - это создание белого списка.
  13. Читайте внимательно то, что я написал. В моих плагинах нет ничего, что меняло бы количество комментариев, также нет чужих (сторонних) плагинов.
  14. Нет такой настройки. Я могу либо запретить отправлять сообщения в обратную связь всем, кроме Администраторов (что меня не устраивает - Редактор и Рекламный отдел не должны быть администраторами), либо разрешить отправлять всем (как сейчас). По факту нужен белый список получателей. Придется делать плагин.
  15. Не смешно. По русски написано же - сторонних плагинов нет.