stihhi 8 Опубликовано: 25 октября 2020 Рассказать Опубликовано: 25 октября 2020 Уважаемые разрабоичики, очень не хватает списка запрещенных слов, а то вводить вручную 700 матерных слов очень не удобно и ещё добавить пункт оповещение администратора если какой-то пользователь употребил запрещённое слово, очень не обходимо чтоб быстро искать нарушителей на сайте. 1 Цитата Ссылка на сообщение Поделиться на других сайтах
MSK 154 Опубликовано: 25 октября 2020 Рассказать Опубликовано: 25 октября 2020 23 минуты назад, stihhi сказал: вводить вручную 700 матерных слов очень не удобно Для подобного фильтра есть класс "матотест" для русского языка - хорошо справляется с детектированием (я использовал когда-то в чатах), а "извратные" сочетания отдельно добавлял. Автор класса был раньше на dklab, сейчас сайт уже не фурычит - гугл в помощь. Цитата Ссылка на сообщение Поделиться на других сайтах
stihhi 8 Опубликовано: 26 октября 2020 Рассказать Опубликовано: 26 октября 2020 13 часов назад, MSK сказал: Для подобного фильтра есть класс "матотест" для русского языка - хорошо справляется с детектированием (я использовал когда-то в чатах), а "извратные" сочетания отдельно добавлял. Автор класса был раньше на dklab, сейчас сайт уже не фурычит - гугл в помощь. А оповещение, если человеку просто выводится Аякс окно о запрещенных Слован он просто ставит пару точек и все dle принимает такой комент. Цитата Ссылка на сообщение Поделиться на других сайтах
videowoolf 0 Опубликовано: 5 ноября 2020 Рассказать Опубликовано: 5 ноября 2020 Было бы не плохо включить в функционал предварительный просмотр шаблона и его редактирование без активации на сайте бывает нужно что то подправить а возможности предварительно отценить то что будет видно юзерам нет. Цитата Ссылка на сообщение Поделиться на других сайтах
Nicksemsujahan 2 Опубликовано: 6 ноября 2020 Рассказать Опубликовано: 6 ноября 2020 Обновления которые очень нужны: -убрать быдлокод при вставке картинок через редактор -видео с ютуба вставляются некоректно (у бутсрап есть готовое решение) -кнопка генерации сайтмап после публикации статьи -при загрузке картинки к ее названию добавляется кучу мусора. Это не нужно и негативно влияет на сео 1 Цитата Ссылка на сообщение Поделиться на других сайтах
celsoft 5 569 Опубликовано: 7 ноября 2020 Рассказать Опубликовано: 7 ноября 2020 Автор 22 часа назад, Nicksemsujahan сказал: -видео с ютуба вставляются некоректно (у бутсрап есть готовое решение) Все прекрасно и корректно вставляется. На чем основано подобное утверждение непонятно. 22 часа назад, Nicksemsujahan сказал: -убрать быдлокод при вставке картинок через редактор Никакого "быдлокода" там нет. 22 часа назад, Nicksemsujahan сказал: -при загрузке картинки к ее названию добавляется кучу мусора. Это не нужно и негативно влияет на сео Никакого мусора тоже там нет. Если не знаете для чего и почему, это не значит что это мусор. P.S. Вам предупреждение, за не уважение к другим участникам форума и не умение корректно излагать свои мысли и сообщения. Здесь долго не задерживаются те, кто кто считает что если ему что то не нужно, то это уже и "быдлокод" и "мусор". Цитата Ссылка на сообщение Поделиться на других сайтах
Drage 17 Опубликовано: 13 ноября 2020 Рассказать Опубликовано: 13 ноября 2020 Хотелось бы добавить возможность показывать пользователю последние посещенные новости. Количество последних новостей которые будут отображаться, хорошо чтобы можно было указывать в админке. Цитата Ссылка на сообщение Поделиться на других сайтах
radrigo 95 Опубликовано: 13 ноября 2020 Рассказать Опубликовано: 13 ноября 2020 3 часа назад, Drage сказал: Хотелось бы добавить возможность показывать пользователю последние посещенные новости. Данная возможность добавлена в версии 14.0 Смотрите 12 пункт https://dle-news.ru/release/1789-datalife-engine-v140-final-release.html 1 Цитата Ссылка на сообщение Поделиться на других сайтах
Drage 17 Опубликовано: 13 ноября 2020 Рассказать Опубликовано: 13 ноября 2020 3 часа назад, radrigo сказал: Данная возможность добавлена в версии 14.0 Смотрите 12 пункт https://dle-news.ru/release/1789-datalife-engine-v140-final-release.html Да, у меня было ощущение что эта функция есть, и я даже припоминал что добавлена в одном из последних релизов, но я не смог найти. Спасибо большое! Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 51 Опубликовано: 14 ноября 2020 Рассказать Опубликовано: 14 ноября 2020 Хочу обсудить вопрос оптимизации и целесообразности использования таблицы dle_post_extras_cats Имеется тестовый сайт с 60к+ новостями. Мультикатегории включены, но каждая новость отмечена только в одной категории. Берем штатный, стандартный запрос для категории (в ней 44к записей) и проведем несколько замеров: SELECT SQL_NO_CACHE p.id, p.autor, p.date, p.short_story, full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN (1)) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE approve=1 ORDER BY date DESC LIMIT 50,20 Запрос занял 2.1704 сек. Запрос занял 1.7433 сек. Запрос занял 1.6352 сек. Но если выполнить этот запрос по старому формату, с category REGEXP '[[:<:]])(1)[[:>:]]', то числа получаются уже совершенно другие: Запрос занял 0.0024 сек. Запрос занял 0.0017 сек. Запрос занял 0.0020 сек. На другом тестовом сайте, где в категории ~100к записей - ситуация абсолютно такая же. И вот еще, если в запросе несколько категорий, то в первом случае время запроса всегда больше 2 сек, во втором практически не меняется, так же в районе 0,002 сек. EXPLAIN запроса показывает вовсе не радостную картину: Using temporary; Using filesort - т.е. используется временная таблица и сортировка выполняется без использования каких-либо индексов. Я не хочу сказать, что использование REGEXP - хорошая практика. Его действительно следовало заменить, но текущая реализация, как мне кажется, тоже не является лучшим решением. Цитата Ссылка на сообщение Поделиться на других сайтах
crafic 5 Опубликовано: 14 ноября 2020 Рассказать Опубликовано: 14 ноября 2020 40 minutes ago, Sander1 said: Мультикатегории включены, но каждая новость отмечена только в одной категории если новость в одной категории то зачем юзать мульти? Цитата Ссылка на сообщение Поделиться на других сайтах
celsoft 5 569 Опубликовано: 14 ноября 2020 Рассказать Опубликовано: 14 ноября 2020 Автор 7 часов назад, Sander1 сказал: Имеется тестовый сайт с 60к+ новостями. Мультикатегории включены, но каждая новость отмечена только в одной категории. Для чего в принципе включать мультикатегории непонятно. Их проще отключить и тогда запрос будет намного проще. 7 часов назад, Sander1 сказал: Но если выполнить этот запрос по старому формату, с category REGEXP '[[:<:]])(1)[[:>:]]', то числа получаются уже совершенно другие Этот запрос не будет работать например в MySQL 8.xx 7 часов назад, Sander1 сказал: Запрос занял 2.1704 сек. Запрос занял 1.7433 сек. Запрос занял 1.6352 сек. Он не должен столько выполняться при 60к публикаций. Что то некорректо настроено в MySQL, недостаточно выделено под служебные данные. Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 51 Опубликовано: 14 ноября 2020 Рассказать Опубликовано: 14 ноября 2020 46 минут назад, celsoft сказал: Для чего в принципе включать мультикатегории непонятно. Их проще отключить и тогда запрос будет намного проще. Вопрос немного не по теме. Я акцентировал внимание на одной категории, чтобы показать, что это "голая" система и там не отмечено по 100 категорий в каждой новости. Есть много кино-сайтов, где мультикатегории используются в качестве жанров, подборок или еще чего-либо. 59 минут назад, celsoft сказал: Этот запрос не будет работать например в MySQL 8.xx Не знал, буду иметь ввиду. Но я и не говорю, что следует использовать именно старый формат запроса. 1 час назад, celsoft сказал: Он не должен столько выполняться при 60к публикаций. Что то некорректно настроено в MySQL, недостаточно выделено под служебные данные. Ради интереса и чистоты эксперимента, поставил свежий OpenServer 5.3.7. PHP 7.4, MySQL 8.0.19 DLE 14.1, добавил 78к новостей, каждая отмечена в 3х категориях. Ситуация чуть лучше, но все равно за пределами нормы. SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('3')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE approve=1 ORDER BY date DESC LIMIT 10,10 [time] => 0.94885897636414 SELECT COUNT(*) as count FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('3')) c ON (p.id=c.news_id) WHERE approve=1 [time] => 0.33806180953979 Когда несколько категорий в запроса (подкатегории), ситуация частично лучше, частично хуже Тайминги 0.482 и 0.55 соответственно. Если в категории 10к новостей, то тайминги: 0.137 и 0.041. Наличие подкатегорий не сильно влияет. Цитата Ссылка на сообщение Поделиться на других сайтах
Gameer 255 Опубликовано: 14 ноября 2020 Рассказать Опубликовано: 14 ноября 2020 26 минут назад, Sander1 сказал: Ради интереса и чистоты эксперимента, поставил свежий OpenServer 5.3.7. PHP 7.4, MySQL 8.0.19 DLE 14.1, добавил 78к новостей, каждая отмечена в 3х категориях. Ситуация чуть лучше, но все равно за пределами нормы. SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('3')) c ON (p.id=c.news_id) LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE approve=1 ORDER BY date DESC LIMIT 10,10 [time] => 0.94885897636414 SELECT COUNT(*) as count FROM dle_post p INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN ('3')) c ON (p.id=c.news_id) WHERE approve=1 [time] => 0.33806180953979 Когда несколько категорий в запроса (подкатегории), ситуация частично лучше, частично хуже Тайминги 0.482 и 0.55 соответственно. Если в категории 10к новостей, то тайминги: 0.137 и 0.041. Наличие подкатегорий не сильно влияет. А можно поделится базой? Хочу кое что проверить. Цитата Ссылка на сообщение Поделиться на других сайтах
celsoft 5 569 Опубликовано: 15 ноября 2020 Рассказать Опубликовано: 15 ноября 2020 Автор 7 часов назад, Sander1 сказал: Не знал, буду иметь ввиду. Но я и не говорю, что следует использовать именно старый формат запроса. Ну а это самый быстрый запрос который бы поддерживал и функциональность и новое серверное ПО, отказаться от поддержки нового ПО, которое уже используется повсеместно невозможно. Под "самый быстрый" я безусловно имею ввиду что из тех, что известны мне. Если вы можете вы знаете лучшее решение, то я был бы рад это услышать. Быстродействие наш приоритет, мы всегда прислушиваемся к таким советам. 7 часов назад, Sander1 сказал: Ради интереса и чистоты эксперимента, поставил свежий OpenServer 5.3.7. PHP 7.4, MySQL 8.0.19 Чистый, это априори значит плохо. Стандартая конфигурация, это всегда самые неоптимальные настройки, потому как заточены на совместимость а не на быстродействие. Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 51 Опубликовано: 15 ноября 2020 Рассказать Опубликовано: 15 ноября 2020 13 часов назад, Gameer сказал: А можно поделится базой? Хочу кое что проверить. Да это просто програмно заполненная база из "Test #{n}" заголовков с рандомным распределением по заданным категориям. 6 часов назад, celsoft сказал: Если вы можете вы знаете лучшее решение, то я был бы рад это услышать. К сожалению, если бы оно у меня было - я бы его уже озвучил :( Разве что такое предложение, сделать пункт "мультикатегории" опциональным индивидуально для каждой категории. 7 часов назад, celsoft сказал: Чистый, это априори значит плохо. Не могу не согласиться. Но так же нельзя сказать, что эти базовые настройки отвратно оптимизированы для небольших БД. Я попробовал поиграться с настройками, это дало некоторый результат, но все равно он далек от приемлемого. Но обнаружил интересный факт. WHERE cat_id IN (2) - обрабатывается в среднем 220мс (против 900мс раньше) при количестве 54к Зато когда несколько категорий, то уже совершенно другое дело. WHERE cat_id IN (2,3) - за 39мс. 71к записей. WHERE cat_id IN (2,1000) - за 28мс. 1000 - такой категории нет, но все работает быстро и правильно. Удивительно, но факт Цитата Ссылка на сообщение Поделиться на других сайтах
Gameer 255 Опубликовано: 15 ноября 2020 Рассказать Опубликовано: 15 ноября 2020 2 часа назад, Sander1 сказал: Да это просто програмно заполненная база из "Test #{n}" заголовков с рандомным распределением по заданным категориям. К сожалению, если бы оно у меня было - я бы его уже озвучил :( Разве что такое предложение, сделать пункт "мультикатегории" опциональным индивидуально для каждой категории. Не могу не согласиться. Но так же нельзя сказать, что эти базовые настройки отвратно оптимизированы для небольших БД. Я попробовал поиграться с настройками, это дало некоторый результат, но все равно он далек от приемлемого. Но обнаружил интересный факт. WHERE cat_id IN (2) - обрабатывается в среднем 220мс (против 900мс раньше) при количестве 54к Зато когда несколько категорий, то уже совершенно другое дело. WHERE cat_id IN (2,3) - за 39мс. 71к записей. WHERE cat_id IN (2,1000) - за 28мс. 1000 - такой категории нет, но все работает быстро и правильно. Удивительно, но факт Как на счёт такого запроса? SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p LEFT JOIN dle_post_extras e ON (p.id=e.news_id) JOIN (SELECT id FROM dle_post LEFT JOIN dle_post_extras e ON (id=e.news_id) INNER JOIN (SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN (2)) z ON (id=z.news_id) WHERE approve=1 ORDER BY date desc LIMIT 0,10) as l ON p.id=l.id ORDER BY date desc Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 51 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 17 часов назад, Gameer сказал: Как на счёт такого запроса? С тем же успехом, 220мс. Даже чуть хуже. Во всех ситуациях в среднем на 15мс медленнее. Это более заметно, когда выборка идет по двум категориям, когда тайминги в районе 40мс и 55мс соответственно. Цитата Ссылка на сообщение Поделиться на других сайтах
crafic 5 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 у меня запрос SELECT p.id, p.autor, p.date, p.short_story, full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE approve=1 AND date < '2020-11-16 16:38:32' AND p.category REGEXP '[[:<:]](29|30)[[:>:]]' ORDER BY date DESC LIMIT 20; занял 0.003сек при 26 912 новостях. если же с INNER JOIN DISTINCT , то (0.590 s) подставлял и по 4 категории. p.category REGEXP '[[:<:]](9|10|12|23)[[:>:]]' - (0.003 s) . с INNER JOIN DISTINCT , то (0.412 s) версия mysql 5.7.29-log так что подтверждаю с регуляркой быстрее. ето логично. так как один только запрос SELECT DISTINCT(dle_post_extras_cats.news_id) FROM dle_post_extras_cats WHERE cat_id IN (9,10,12,23) занимает (0.342 s) . не говоря уже о обьединениях с dle_post dle_post_extras Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 51 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 (изменено) Следующая тема о которой я так же хотел бы поговорить - тег {sort} Я согласен с тем, что разделение таблицы dle_post на dle_post и dle_post_extras - это хорошее решение. Но вот с тем как выполнено это разделение - я немного не согласен. По моему мнению, во вторую таблицу так же следовало бы вынести второстепенные данные, которые используются преимущественно только на странице полной новости. К примеру это такие поля как: descr, keywords, allow_br и, пожалуй, full_story Но в свою очередь перенести обратно из dle_post_extras поля: news_read, allow_rate, rating, vote_num, editdate, editor, reason Чтобы при штатном выводе контента show.short.php - вообще не использовалась таблица dle_post_extras (за исключением rss). Теперь немного конкретики и зачем я изначально упомянул тег {sort} При использовании сортировки по популярности или посещаемости: SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE category IN ('1') AND approve=1 ORDER BY e.news_read desc LIMIT 0,60 Время запроса стабильно 1 - 1.5 сек. Количество новостей в категории 44к EXPLAIN: Using index condition; Using where; Using temporary; Using filesort Но если перенести колонку news_read в dle_post, то картина совершенно другая SELECT p.id, p.autor, p.date, p.short_story, CHAR_LENGTH(p.full_story) as full_story, p.xfields, p.title, p.category, p.alt_name, p.comm_num, p.allow_comm, p.fixed, p.tags, e.news_read, e.allow_rate, e.rating, e.vote_num, e.votes, e.view_edit, e.editdate, e.editor, e.reason FROM dle_post p LEFT JOIN dle_post_extras e ON (p.id=e.news_id) WHERE category IN ('1') AND approve=1 ORDER BY p.views desc LIMIT 0,60 Время запроса не превышает 5мс EXPLAIN: Using where Аналогичная проблема касается сортировок в custom Изменено 16 ноября 2020 пользователем Sander1 1 2 Цитата Ссылка на сообщение Поделиться на других сайтах
crafic 5 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 на счет полей я тут тему создавал https://searchengines.guru/ru/forum/1021845 если по рейтингу сортируем то беда. Цитата Ссылка на сообщение Поделиться на других сайтах
celsoft 5 569 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 Автор 1 час назад, Sander1 сказал: Но если перенести колонку news_read в dle_post, то картина совершенно другая А на запись она какой станет? Не проверили. А вот существенно увеличится. Во время просмотра не только чтение происходит, но и запись. Ваше тестирование в данном случае по одному запросу не совсем корректно. Цитата Ссылка на сообщение Поделиться на других сайтах
Gameer 255 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 4 часа назад, Sander1 сказал: С тем же успехом, 220мс. Даже чуть хуже. Во всех ситуациях в среднем на 15мс медленнее. Это более заметно, когда выборка идет по двум категориям, когда тайминги в районе 40мс и 55мс соответственно. Очень странно. Тот что я предложил. Стандартный В базе 54000 записей. PHP 7.3, MariaDB 10.3 Цитата Ссылка на сообщение Поделиться на других сайтах
Sander1 51 Опубликовано: 16 ноября 2020 Рассказать Опубликовано: 16 ноября 2020 34 минуты назад, celsoft сказал: А на запись она какой станет? Не проверили. А вот существенно увеличится. Вот, провел небольшой тест: $ids = range(10000, 60000); shuffle($ids); $mt = microtime(true); for ($i = 0; $i < 10000; $i++) { $id = array_pop($ids); //$db->query('UPDATE dle_post SET views = views + 1 WHERE id = ' . $id); $db->query('UPDATE dle_post_extras SET news_read = news_read + 1 WHERE news_id = ' . $id); } echo microtime(true) - $mt; Для обоих таблиц - время одинаковое, ~1.2 сек на 10к запросов. Но ведь к тому же есть кеширование счетчика просмотров. Сохранение оценки в рейтинге выполняется достаточно редко, уж точно не 10к оценок в секунду, поэтому полагаю им можно пренебречь. Да и не будет там ситуация сильно отличаться. 43 минуты назад, celsoft сказал: Ваше тестирование в данном случае по одному запросу не совсем корректно. Справедливости ради стоит заметить, что этот один запрос тоже может быть не один, если в настройках DLE или категории по умолчанию включена сортировка по просмотрам. Цитата Ссылка на сообщение Поделиться на других сайтах
celsoft 5 569 Опубликовано: 17 ноября 2020 Рассказать Опубликовано: 17 ноября 2020 Автор 16.11.2020 в 18:18, Sander1 сказал: Для обоих таблиц - время одинаковое, ~1.2 сек на 10к запросов. Оно не может быть одинаковое. Там данные в принципе другие и таблица dle_post априори намного больше, ее обновление занимает больше времени. При условии что у вас там тексты новостей нормальные и обьемные, как и положено, а не одно предложение. Цитата Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Присоединяйтесь к обсуждению
Вы можете опубликовать сообщение сейчас, а зарегистрироваться позже. Если у вас есть аккаунт, войдите в него для написания от своего имени.