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

YuriBtr

Клиенты
  • Публикаций

    250
  • Зарегистрирован

  • Посещение

Репутация

13 Обычный

Информация о YuriBtr

  • Звание
    Новичок

Информация

  • Пол
    Мужчина

Посетители профиля

730 просмотров профиля
  1. Если кому интересно, алгоритм определения похожих новостей удалось заметно улучшить (хотя еще далеко до идеала): В файле engine/modules/show.full.php: заменить $body = strip_tags( stripslashes( $metatags['title'] . " " . $body ) ); на $body = strip_tags( stripslashes( $metatags['title'] . " " . $metatags['keywords'] . " " . $social_tags['news_keywords'] . " " . $body ) ); чуть ниже в этом же файле заменить $db->query( "SELECT id, date, short_story, xfields, title, category, alt_name FROM " . PREFIX . "_post WHERE {$where_category}{$allowed_cats}{$not_allowed_cats}MATCH (title, short_story, full_story, xfields) AGAINST ('$body') AND id != " . $row['id'] . " AND approve=1" . $where_date . " LIMIT " . $config['related_number'] ); на $db->query( "SELECT id, date, short_story, xfields, title, category, alt_name, MATCH (title, short_story, full_story, xfields) AGAINST ('$body') as score FROM " . PREFIX . "_post WHERE {$where_category}{$allowed_cats}{$not_allowed_cats} MATCH (title, short_story, full_story, xfields) AGAINST ('$body') AND id != " . $row['id'] . " AND date < NOW() AND approve=1" . $where_date . " ORDER BY score DESC, date DESC LIMIT " . $config['related_number'] ); Кстати не нашел где формируется условие $where_date, полагаю что про него забыли. В нем можно прописать ограничение по дате, чтобы не тянуть старые новости, например так: $where_date = " AND date >= NOW() - INTERVAL 365 DAY AND date < NOW() ";
  2. Да, прошу прощения, действительно есть, это видно по запросу: select index_name, group_concat(column_name) as columns from information_Schema.STATISTICS where table_schema = 'your_db_name' and table_name = 'dle_post' and index_type = 'FULLTEXT' group by index_name; Я неправильно смотрел наличие этого индекса в phpMyAdmin. Кстати в \engine\ajax\find_relates.php также есть выборка но с учетом релевантности.
  3. Заметил, что выборка похожих новостей через тег {related-news} очень и очень далека от идеала. Например в статьях про ДТП выводятся "похожие" новости про ямы на дорогах или концерты. При том, что новости про ДТП почти каждый день попадают на сайт. Как следует из анализа \engine\modules\show.full.php, поиск похожих делается только в момент первого открытия новости, и не перестраивается после, пока не обнулишь поле related_ids (например через "Перестроение кэша похожих новостей") . Поиск похожих новостей делается через: SELECT ... MATCH (title, short_story, full_story, xfields)... AGAINST Как видно, запрос MATCH AGAINST проходит не в boolean режиме (в отличие от полнотекстового поиска). А значит для нормальной работы этого запроса требуется полнотекстовый индекс ( FULLTEXT) у тех полей, по которым проходит поиск. Как видно из структуры БД у указанных полей (title, short_story, full_story, xfields) отсутствует таковой индекс. Его можно добавить самому, но теперь вопрос @celsoft: а это так и должно быть или у меня не обновилась база при обновлении скрипта? К тому же судя по инструкции нужно еще и сортировать результаты по релевантности (делая два запроса MATCH AGAINST - второй пример по ссылке). У нас же сортировки вообще не наблюдается. Кстати, было бы неплохо делать автоматический сброс кеша похожих новостей хотя бы раз в день (отдельно от настройки "Количество дней, в течение которых кешировать полную новость после ее публикации").
  4. Это не проблема DLE. У вас в логотипе watermark_dark.png текст в виде картинки вырезанной со светлого фона. Вокруг текста присутствуют куски фона. Вам надо просто создать PNG файл с прозрачностью, и написать заново ваш текст поверх. И кстати не забудьте поменять также watermark_light.png
  5. Чисто пофантазировать, о такой фиче, которую еще нигде не видел. При включенной предмодерации комментариев (когда комментарии появляются только после одобрения), было бы классно видеть что такой то пользователь добавил коммент, но его содержимое пока недоступно, так как проверяется. Это бы немного увеличило дружелюбность сайта и побудило бы других пользователей также оставлять комментарии. Также хотелось бы чтобы комментарии не удалялись из базы, если не прошли модерацию. Но исчезали бы из ленты, если модератор нажмет кнопку "Скрыть". Сейчас альтернативы удалению комментариев нет. И в случае "разборов полетов" неизвестно что писал юзер и за что модератор его забанил или удалил комментарий. И последнее: при отклонении комментария, можно было бы выбрать одну из причин отклонения, либо написать свою (как на некоторых форумах). Примерный образец прилагаю: uploads
  6. Поверьте, я не сижу и не выискиваю к чему бы придраться, у меня на это нет ни времени, ни желания. Я просто привел пример ошибки в спроектированной Вами системе. Я сам являюсь программистом и мне обидно бывает слышать что что-то работает не так как люди ожидали. Но при всем моем уважении, исходя из спроектированного Вами же интерфейса становится непонятно, почему на одни картинки накладывается вотермарк, а на другие нет. И если Вы меня ткнете носом в документацию, где описан этот вопрос, я соглашусь с Вами что это не баг, а просто плохо реализованная фича и ошибка в логике интерфейса. Вот смотрите - в настройках Вы говорите что вотермарк накладываем на все картинки более 300 точек. И все! Других условий при которых вотермарк не накладывается нигде нет! А по факту получается что юзер скармливает движку качественный, большой, красивый вотермарк, а он не накладывается. И предупреждений нигде нет, ни в документации, ни в интерфейсе. Не кажется ли Вам, что надо было бы как то сигнализировать юзеру: "Эй, чувак! Несмотря на то что эта картинка больше 300 точек, твой логотип 800 точек больше картинки на 640 точек. Так как ресайзить логотипы меня разработчик пока не научил, то и делать ничего не буду". Это конечно шутка, но человек должен знать что так нельзя делать. Потому как на кону - авторский материал.
  7. Доработать систему наложения watermark (водяных знаков): 1. Сейчас движок не может уменьшить вотермарк и наложить его на картинку, если размер вотермарка больше картинки. Картинки должны быть строго больше размера вотермарка. Следовательно нужно сделать возможность принудительного уменьшения размера вотермарка, до размера обрабатываемой картинки, в случае конечно если картинка превышает установленный порог срабатывания вотермарка. 2. Вотермарк не масштабируется, а это значит что на небольших картинках он будет большим, а на маленьких вообще незаметным. Нужно учитывать размер картинки перед наложением вотермарка. Например делаем вотермарк для максимального разрешения, указанного в настройке "Максимально допустимые размеры оригинального изображения", и если картинка меньше, то пропорционально уменьшаем вотермарк. 3. Нужно добавить возможность делать текстовый вотермарк (с отступами в процентах), такой легко модифицируется и масштабируется. 4. Добавить настройку наложения вотермарка "По центру". 5. Сделать наложение вотермарков на превьюшки и средние картинки, при превышении ими установленного порога срабатывания вотермарка.
  8. Ну вот опять начинается. Давайте начнем с теории: Если я загружаю вотермарк на 800 точек ширины, указываю минимальную ширину для наложения 300 точек, и при этом у меня нет предупреждения о том, что я что то делаю неправильно, значит имеет место неожиданное поведение. Верно? Все бы ничего, сайт работает, но в результате оказывается что эксклюзивные фото с шириной менее 800 точек вывешиваются без логотипа, что дает возможность украсть их недобросовестным конкурентам. Вот и получается, что есть неожиданное поведение, и неожиданный, негативный результат. Будем спорить дальше? Или просто напишете в документации что мол вотермарк не должен быть более целевого разрешения картинки. Вы как разработчик скрипта конечно имеете право не делать то что я предлагаю, но спорить с тем что это баг - бесперспективно.
  9. Аглицкий я знаю, и понимаю что вотермарки для темного и светлого изображения. Только вот непонятно зачем и как оно работает. У меня на темное изображение накладывается темный вотермарк. Думаю этот алгоритм неправильно работает. К тому же до этого в сторонней программе я делал один темный вотермарк со светлой обводкой (или наоборот), который везде хорошо смотрится. Остальные пункты - это не совсем пожелания. Пункт 1 это точно баг. Пункт 2 и 5 проистекает из первого.
  10. 1. При включенных настройках "Разрешить наложение водяных знаков:" и "Минимальный размер для накладывания водяного знака:" в 300 точек, не происходит наложения на картинки с размерами: 640px × 480px, 500px × 333px, 734px × 489px. При этом размер watermark_dark.png и watermark_light.png 800х200 точек, потому как меньший размер не заметен на больших разрешениях, типа 1920х1080. Выходит что движок не может пропорционально уменьшить вотермарк и наложить его на картинку, если размер вотермарка больше картинки. 2. Вотермарк не масштабируется, а это значит что на небольших картинках он будет большим, а на маленьких вообще незаметным. Нужно учитывать пропорции картинок перед наложением (например делаем вотермарк для максимального разрешения, указанного в настройке "Максимально допустимые размеры оригинального изображения"). Если исходная картинка меньше - пропорционально уменьшаем вотермарк. 3. Было бы неплохо добавить возможность делать текстовый вотермарк (с отступами в процентах), такой легко модифицируется и массштабируется. 4. Отсутствует настройка наложения вотермарка "По центру". 5. Не накладывается вотермарк на превьюшки и средние картинки. А ведь они могут быть достаточно большими. 6. Не понятно для чего две версии вотермарка: watermark_dark.png и watermark_light.png, какая логика их применения.
  11. В комплекте с DLE идет Highslide версии 4.1.13, которой уже 7 лет (!!!). И хотя она работает более-менее сносно, но в ней отсутствует нормальная галлерея. Хотелось бы подключить в движок по умолчанию включенную ленту изображений (thumbstrip) как здесь: демка или вот так
  12. Хорошо было бы обновить версию jQuery, которая идет в комплекте с движком. Так как на jQuery 2.2.4 можно запустить Bootstrap максимальной версии 3.3.6. Понятно что это повлечет за собой переписывание шаблонов, но может в админке сделать возможность выбора версии jQuery ?
  13. Не нашел как можно разделить вывод имени пользователя и ccылки для входа, чтобы их можно было легко выводить в разных частях сайта или просто в несвязанных блоках. Кажется не хватает в main.tpl нового тега типа {username} и {user-avatar}
  14. В разделе документации по Панели авторизации на сайте отсутствует описание тега {login}
  15. Естественно это было сделано. Но, за время включенной настройки без протокола, другие сайты насоздавали много ссылок на мой сайт с неправильной адресацией. Теперь надо как то резолвить эти обращения на моей стороне, чтобы не было у них 404 ошибок.