YuriBtr
-
Публикации
336 -
Зарегистрирован
-
Посещение
-
Дней в лидерах
17
Сообщения, опубликованные пользователем YuriBtr
-
-
Добрый день. Может кто сталкивался с такой проблемой - при резком увеличении посещаемости просаживается база данных. В логах куча медленных запросов вида в разных вариациях:
"SELECT id FROM `dle_post` AS p WHERE approve AND category regexp "([[:punct:]]|^)(10)([[:punct:]]|$"
На сайте включены мультикатегории, версия движка 14.1 Кеширование включено, кеш файловый.
Такое бывает редко, в основном в случае всяких ЧП, при котором большой наплыв юзеров (сайт новостной). -
Все нормально, так можно делать. У меня написана такая функция:
function skinChange() { ShowLoading('Переключаемся на старый дизайн, подождите...'); $.post( '/index.php', { action_skin_change: "yes", skin_name: "oldskin" } ).always(function() { window.location = window.location.href.split("#")[0]; } ); }
И на кнопке стоит обработчик:
<button onclick="skinChange();" class="btn btn-sm btn-primary" title="Переключиться на старый вид сайта">
-
2
-
-
Было бы неплохо сделать версионирование материалов (вариант как редакции в Вордпресс вполне бы устроил). А то лезут несколько человек исправлять статью, а потом не разберешь, кто что менял и кого наказывать. Да и откатиться было бы неплохо, если в спешке затерли какой нибудь абзац.
И проверку дублей ЧПУ URL при сохранении очень хотелось бы увидеть.
-
2
-
-
В 04.10.2019 в 14:34, Gameer сказал:
Не только PHP но и структуры самого Wordpress, знания переменных и функций этого движка.
В этом году я сделал первый сайт на Вордпресс на трех языках - причем с кастомными типами записей, кастомными полями, кастомной таксономией, заливкой материалов/фоток через API. На все ушло 3 месяца без начальных знаний Wordpress. Такой гибкости и вариантов решения проблем я еще не видел. Это просто космос. Его хуки это нечто, а шаблонизатор с полной поддержкой PHP круть. Плюс масса уроков, документации, готовых плагинов. Хотя конечно PHP знать обязательно, хотя бы на начальном уровне.
Об этом я уже писал здесь год назад и еще раньше. В DLE слишком мало возможностей. Да он быстр как степная лань, и легковесный. Но если ты хочешь хоть немного отойти от навязываемого разработчиком стиля (таблицы поиска, вывод кнопок и списков) - то надо писать кучу плагинов чтобы менять ядро. Потому как разделение кода разработчик не сделал.
Ладно бы были нормальные плагины, с вызовами через хуки. Но плагин, который меняет просто кусок кода на другой - это хак. В работоспособности которого нельзя быть уверенным после очередного обновления. Это плохая идея, хотя конечно лучше чем вообще ничего.
Про минимальную обработку PHP в шаблонизаторе (как в Smarty, Fenom) речь не идет. Хотя это бы на порядок облегчило написание шаблонов и избавило бы от написания некоторых плагинов. А ведь можно было бы сделать новый тип шаблонов, и обрабатывать их новым шаблонизатором, чтобы сохранить обратную совместимость.
Подводя итог скажу: IMHO разработчик DLE нацелил движок на сайты с большой посещаемостью (тысячи и десятки тысяч уников в день). Об этом говорит то, что DLE платный (бесплатная демо версия не обновляется и на ней масса ограничений). Оптимизация и простота движка DLE позволяет экономить на хостинге, а простая система шаблонов позволяет экономить на верстальщиках. Однако все более-менее серьезные проекты требуют авторских доработок. А поскольку такие сайты наверняка приносят доход, который позволяет вложиться в шаблон хотя бы один раз при создании сайта - то почему бы не дать такую возможность клиентам?
А школьникам пусть остается Джумла или Вордпресс с их "one-click install". Все равно их сайты не будут настолько нагружены, чтобы они увидели разницу. Да и денег платить они не привыкли.
-
3
-
-
8 часов назад, Gameer сказал:
Тогда скорее всего удаляли через редактирование пользователя в админ панели. Посмотрите в логах в таблице
SELECT * FROM dle_admin_losgs WHERE extras='НИК' AND action=64
Прошу прощения, не понял в каких логах смотреть SQL запрос?
И как я говорил ранее, в access.log отсутствует строка обращения к профилю пользователя через админ панель:
20 часов назад, YuriBtr сказал:При удалении комментариев путем проставления галочки в профиле, в access.log веб сервера регистрируется GET, а потом и POST обращение к адресу вида "/admin.php?mod=editusers&action=edituser&id=1503". Так вот, в access логах за этот период нет обращений к профилю пользователя с таким ID.
-
43 минуты назад, webair сказал:
Попробуйте сделать поиск по слову "deletecomments"
Комментарии удалялись модераторами, но это были комментарии других лиц. И в логах таких обращений не много.
-
41 минуту назад, webair сказал:
Восстановите из бекапа комментарии пользователя.
И сделайте логгирование удаления комментариев с фронтенда (написать простой плагин).
Может у вас ведется access.log? Посмотреть все запросы, может уязвимость какая то.
Комментарии и их счетчик восстановлены из бекапа.
access.log ведется и как я написал, в нем нет никаких обращений к профилю пользователя.
Другие обращения конечно можно искать, но надо бы знать что искать. Потому как каждый access.log занимает полгигабайта.
Поэтому я и спрашиваю разработчика - какие есть еще методы удаления ВСЕХ комментариев, кроме как проставления галочки в профиле, очистки комментариев из списка пользователей, удаление с фронта последних комментариев по ссылке вида "/index.php?do=lastcomments&userid=1503".
В том что это именно массовое удаление сомневаться не приходиться - это самый активный юзер, который написал за 4 года более 20 тысяч комментариев.
-
По неизвестной причине, были удалены комментарии самого активного пользователя сайта (несколько десятков тысяч комментариев).
В логах ничего нет. Нет записей редактирования данного пользователя. Записи редактирования других пользователей имеются, но они более ранние, и там мой IP.
Права на администрирование есть только у Админа, доступ к которому есть только у меня. Входы от Админа были только с моего IP. Пароль супер сложный. Попыток неудачного входа не было.
База не крашилась - ремонт и оптимизация БД прошла за доли секунды и ничего не изменилось. Остановок сервера не было.
При удалении комментариев путем проставления галочки в профиле, в access.log веб сервера регистрируется GET, а потом и POST обращение к адресу вида "/admin.php?mod=editusers&action=edituser&id=1503". Так вот, в access логах за этот период нет обращений к профилю пользователя с таким ID.
Версия DLE 13.0
Вопрос разработчику - возможна ли очистка комментариев без логгирования в журнале? Например когда в списке пользователей выбрать " Удалить комментарии", то в Журнал записывается сообщение " Удаление комментариев пользователя с ID ", а если в профиле пользователя выбираешь " Удалить все комментарии?" то данное действие не записывается. Возможно ли с фронта удалить все комментарии пользователя?
-
2 часа назад, Primary Sphinx сказал:
Кстати, в движке довольно легко можно реализовать личные и "коллективные блоги", приблизив его фунционал к информационной или тематической соц.сети
Для этого нехватает одной важной функции - модерирования комментариев автором блога только в СВОЕЙ ветке.
Без этого функционал DLE как блоговой платформы не имеет особого смысла.
-
1
-
-
1 час назад, celsoft сказал:
Зачем вы там добавляете новость непонятно.
Потому что такая возможность есть.
Если бы я знал что эти действия не пишутся в журнал (опять странная логика у разработчика), я бы наверное выключил вообще возможность добавления с фронта, чтобы полностью контролировать сайт. Но что тогда делать с быстрым редактированием непонятно. Оно ведь очень нужно, а изменения через него тоже не пишутся в журнал.
1 час назад, celsoft сказал:я имел ввиду что DLE может перенести автоматом, если при добавлении новости было оказано это. Например указан срок действия. Это можно сделать было и случайно, не заметив.
Спасибо, я вас и так понял. Вы не можете быть уверенным в том, что проблема не во мне. Но и я не могу быть уверенным в том, что проблема не в скрипте. Конечно я не исключаю внешнего вмешательства - ведь скрипт стоит у хостинг провайдера, там же и БД находится. Мало ли какое обслуживание запускалось или может сбой был в БД при аварийной остановке.
Поэтому я просто отправил сюда этот репорт, вдруг у кого нибудь будет похожая проблема, тогда это может стать основанием для более тщательной проверки кода скрипта. Ведь если не сообщать о странностях, то сложные баги выловить будет невозможно.
-
1
-
-
1 час назад, celsoft сказал:
Никак. Это не включается.
очень грустно, получается модуль логирования есть, но его легко обмануть. И админ даже не будет подозревать что так работает логика движка.
1 час назад, celsoft сказал:Вполне возможно, но уже не через DLE. Ее же можно изменить и напрямую в БД. Или вообще можно задать опции по переносу еще при добавлении, указав что категория у новости временная, такая же возможность есть в DLE.
хочется надеяться что так и было, но я точно ничего в БД не менял, переносов не было. Кроме меня никто не смог бы это сделать, к тому же так точечно
-
1
-
-
3 часа назад, celsoft сказал:
Это значит только одно, что новость не создавалась в админпанели. Это логи админпанели, и фиксиуется добавление новости только в админпанели. А новость могли например добавить с сайта.
Вот это поворот! А как включить логгирование все добавления новостей, даже с фронта?
Но вопрос даже не в этом, новость от Администратора точно была опубликована в нужной категории, у меня даже есть скриншот (приходится делать клиенту для подтверждения размещения). но потом таинственным образом у этой новости слетела категория. Если вы говорите, что пишутся все редактирования, то значит не все записывается. Потому что кто-то ее изменил.
-
1
-
-
Мне понадобилось узнать, кто и когда поменял категорию в новости, созданной 20.03.19 от имени Администратора.
При разборе ситуации выяснилось, что в модуле "Список действий в админпанели" вообще нет упоминания что данная новость создавалась. Также нет никаких данных о ее редактировании.
Незадолго до этого, в этот же день, Редактором создавалась другая новость, на которую ссылается новость, созданная Администратором. Что интересно по обеим этим новостям никакой информации в логах нет ни за эту дату, ни за более поздние, вплоть до сегодняшнего дня. Искал не только по названиям и URL, но и по адресам картинок, загруженных в новость. Также вручную просмотрел все записи за 20.03.19. Видимо имеет место какой-то баг логгирования.
P.S. Сейчас в журнале 3659 страниц по 50 записей (это список действий за год). Что в общем то немного для БД.
-
2 часа назад, Captain сказал:
Так напиши, если сможешь, а мы потестим.
Написать что???
Fenom и Smarty уже готовый продукт. Надо их подключать при обработке файлов шаблона с расширением например .tpl2
Подключение шаблонизаторов делается на уровне ядра. Если ядро не позволяет легко подключить шаблонизатор - видимо проблема в архитектуре движка. Отсюда еще одно пожелание, про которое я писал ранее - перевести движок DLE на MVC полностью.
-
4 часа назад, celsoft сказал:
Этого не будет никогда. Могу сказать совершенно точно. Потому как во первых многие люди любят DLE именно за простоту его шаблонизатора, во вторых это нарушит совместимость со всеми существующими шаблонами. Поэтому можете абсолютно точно этого не ждать.
Очень жаль, что у вас это вызывает такое категорическое отторжение. На самом деле в шаблонах DLE очень не хватает возможностей PHP (как это сделано в Smarty или Fenom), если вы не хотите внедрять шаблонизаторы (ведь можно просто создать новый тип шаблонов и обеспечить обратную совместимость), то сделайте хотя бы обработку некоторых PHP инструкций.
-
2 часа назад, dimitron сказал:
Обратите внимание пожалуйста может стоит добавить 4 вид ЧПУ.
Тип 4 - ссылки на полную новость будут иметь вид http://site.ru/категория/подкатегория/имя новости.html
ИМХО тогда надо выключать мультикатегории. Иначе у вас будет куча дублей, что отразится на SEO.
Или каким то образом указывать главную категорию по которой резолвить новость.
-
5 часов назад, dimitron сказал:
это можно решить, когда мы создаем или редактируем пост мы должны проверить в БД есть ли новость с таким alt_name. Алгоритм решения прост, сколько нашло записей (получаем количество записей и итерируем $count++). И просто к alt_name добавляем номер. И получим name_news.html, если есть name_news добавляем номер. И получиться name_news_01.html. И таким образом избавляемся от дублей.
Этот метод ненадежный. Нельзя исключать того, что человек мог руками вбить иной порядковый номер в поле ЧПУ URL в полном редактировании и тем самым сбить нумерацию.
В моем случае мы выбираем все что подходит по маске, и в этом результате ищем свободный вариант с добавлением цифры. Его конечно тоже надо оптимизировать, так как чем больше новостей с одним заголовком, тем дольше будет идти проверка, но это уже что-то.
Такую же проверку "на лету" надо сделать и при изменении в поле ЧПУ URL в полном редактировании. Пусть движок говорит, что такой URL уже занят, рекомендуем добавить символы справа.
-
11 часов назад, dimitron сказал:
В новостях нужно убрать .html и ID новости, ловить новость по alt_name (и что бы это можно было настроить в категории, например в одной категории новости выводить по ID в другой по alt_name) то есть что бы мы в категории настраивали ссылку новости. Это очень важно для SEO присутствие ID и .html уже устарело. Да я понимаю что по ID проще словить новость но присутствие ID в ссылке это не красивая ссылка.
Если определять новость по alt_name может возникнуть ситуация, когда разные новости с одинаковыми заголовками перенаправляются на новость, созданную первой из них. У меня такая проблема возникает с типом ЧПУ №3. Если в течение суток опубликовать например утром и вечером новость с заголовком "Требуются работники". То вечерняя новость не будет открываться вовсе, а будет идти редирект на утреннюю. И хотя редакция у нас маленькая и все проинструктированы, но все равно несколько раз в месяц случаются такие дубликаты ЧПУ URL.
Разработчику можно это исправить, добавив при создании новости проверку на уникальность ЧПУ. Если такой URL уже есть во ВСЕЙ базе, то просто добавить какой нибудь порядковый номер справа к ЧПУ URL новой статьи.
Это также поможет в тех ситуациях, когда нужно "поднять" статью из архива. То есть опубликовать ее сегодняшним днем, чтобы не дублировать (а ведь это куда важнее для SEO). Поэтому считаю что движок должен при создании статьи учитывать не только ЧПУ URL текущей даты, но и во всей базе.
Чтобы не было тормозов при повторных прохождениях по базе, при добавлении порядкового номера (нам ведь тоже надо проверить не существует ли к этому новому ЧПУ URL дубль), нужно делать предварительную выборку (кеширование) всех результатов по маске, которые включают в себя первоначальный ЧПУ URL. И при добавлении порядкового номера проверять уже этот кеш. Либо вести отдельный учет дополнительно присвоенных префиксов.
-
А я просто показываю свою рекламу на тех ресурсах, которые у меня берут контент в автоматическом режиме и не ставят прямые ссылки. Для этого у меня есть специальная категория с рекламными новостями (реальные клиенты, либо тупо реклама моего сайта). Затем я подключил плагин, который определяет 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><\\[/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>
33 минуты назад, Datagor сказал:Размер и содержание картинки-заместителя полностью зависит от вашего вкуса и кровожадности, хоть 4K.
Большой размер картинки будет отъедать у вас лимит трафика, и грузить канал. Лучше сделать простой PHP файл в корне сайта и на него направлять воров контента. Содержание файлика простое:
<?php sleep(5); echo ("Fuck off");
-
2
-
-
1 час назад, radrigo сказал:
Или можете убрать из feedback.tpl тег {recipient} и самому вместо него прописать код, где сами пропишете, кому можно отсылать письма. value это id пользователя.
Именно так и сделано, но как правильно заметил alex32, это не влияет на отправку через do=feedback&user=10
1 час назад, radrigo сказал:Ну а если добавить ещё такой редирект?
За идею с редиректом - спасибо, понадобились следующие правила:
исходный адрес:
/?*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 коде, при отправке запроса.
Выходит что единственная надежная защита - это создание белого списка.
-
2 часа назад, proba сказал:
Вы подразумеваете сторонних по отношению какого-то другого разработчика, но:
имелось ввиду по отношению к дистрибутиву dle вообще, не только чьих-то, но и "сделанных вами лично".
Читайте внимательно то, что я написал.
ЦитатаНо в моем случае ничего похожего нет, я все проверил еще раз (((
Все плагины/хаки сделаны мной лично. Сторонних нет.
В моих плагинах нет ничего, что меняло бы количество комментариев, также нет чужих (сторонних) плагинов.
-
10 часов назад, Nektov сказал:
Выйдите с учетной записи на сайте и попробуйте фокус от odys-a
+ настройте права группам
Нет такой настройки. Я могу либо запретить отправлять сообщения в обратную связь всем, кроме Администраторов (что меня не устраивает - Редактор и Рекламный отдел не должны быть администраторами), либо разрешить отправлять всем (как сейчас). По факту нужен белый список получателей. Придется делать плагин.
-
1 час назад, ntrtv сказал:
То есть, плагины, сделанные Вами, Вы не считаете сторонними модификации?
Не смешно. По русски написано же - сторонних плагинов нет.
-
6 часов назад, alex32 сказал:
Если разбегается статистика то в первую очередь надо делать перестроение публикаций, комментариев и оптимизацию.
Проблема не в этом, это решение проблемы, одно из возможных. Перестроение публикаций тоже стоит сделать, что бы оптимизировать таблицы, относящиеся к новостям. ТАм хранится и кол-во комментариев в том числе
Ничего не помогло: пересчет статистики, оптимизация и ремонт БД, сброс кэша. Стабильно показывает комментариев больше чем есть на самом деле. Но не везде. В некоторых статьях количество комментариев совпадает.
4 часа назад, celsoft сказал:Такое может быть если некорректно вмешивались в БД в части удаления комментариев, или их добавления. Т.е. делали это либо напрямую не через DLE, либо сторонние модификации.
Согласен, может быть. Но в моем случае ничего похожего нет, я все проверил еще раз (((
Все плагины/хаки сделаны мной лично. Сторонних нет.
Мне важно было понять, есть ли у кого-либо такая проблема. Если нет ни у кого, буду искать проблему у себя.
Тяжелые запросы к БД
в DataLife Engine (Общие вопросы)
Опубликовано:
Спасибо! Да, в двух файлах шаблона было указано не кешировать вывод через "custom", это очень старые шаблоны, для пользователей старой версии сайта. Вряд ли это могло дать такую нагрузку. Тем не менее, я поправил, проверяю.
Ок, спасибо. Возможно что это BlockPro так косячит. Буду проверять. Сбило с толку что в коде самого DLE в одном месте есть также использование регулярок.