Вы не зашли.
когда я ставлю ID 6,80,5,23 например то хочу чтоб новости у меня шли там только из этих категорий, чесно говоря не совсем понимаю какие тут могут быть другие варианты
то есть если тебе нужен топ по комментариям, то в выборку попадут все новости к которым привязана хотя бы одна из этих категорий? Новость 6, 80, новость 6, новость 75, 80, 21 (80 есть в середине), новость 98, 23 (вторая категория 23). Хотя я думаю, что в реальной организации сайта такого хаоса в присваивании категории не будет?
Тогда вечером напишу тебе, попробуем замерить время в разнице старой версии, которая перебирает все строки и скоро выложу новую тестовую, в которой будет другой механизм. Думаю должен быть хороший прирост в скорости.
и еще, если ты планируеш вовсе отказатся от xfields то было б прикольно чтоб хотяби сделать возможность работы одновременно старого и нового плагина (сделать клон чтоли)
я б например одни новости те что требуют интергации с xfields выводил старым, а остальные (впринципе большую часть) новым плагином
возможно такое нетолько мне подойдет.
нет, отказываться я не собираюсь конечно, просто временно убрал плохой вариант. Другой будет обязательно.
Чем он лучше, чем Логинза?
> вывод переменных для комбинаций показа даты в новостях
это что? какие-то другие комбинации, отличные от дефолтных?
> добавлена ссылка для каждой части даты на соответствующий раздел в плагине календаря
вообще это не плагин календаря, даже без него ссылки все работать будут, а это реально нужная фича?
А для какой версии модификация, чтобы я diff мог сделать, а то сложно смотреть что добавилось.
Это разговор для плагина рейтинга и его организации. Мне по сути не важно с чем интегрироваться.
[1.5][2012-01-07]
+ плагин теперь в репозитории кода NG CMS
+ вывод автора новости и категории
- удалена возможность вывода новостей по рейтингу (плагин rating),
т.к. она совершенно бессмысленна в текущей реализации
- удалена интеграция с новостными плагинами,
т.к. в своей "тупой реализации" может сильно грузить сайт
Это для точки отсчета, версия работающая с релизом 0.9.3. Все остальное: интеграцию с плагинами и про категории хочется услышать ваши ответы.
Wolverine, в плагине кнопка редактирования не пашет вот что выдает при нажатии
http://i29.fastpic.ru/thumb/2011/1103/e … 7f0ee.jpeg
доработка плагина будет?
Sorry, man. Fixed.
Neosa, а зачем тебе понадобилась возможность делать по возрастанию?
Также интересует момент интеграции с другими плагинами, что чаще всего используется, явно не все плагины, которые выводятся в новости. Часто вывод идет только заголовка и ссылки, поэтому вызывать все новостные фильтры это бессмысленно. Теоретически можно задавать с какими именно плагинами нужно интегрироваться. Самый смак это видимо xfields...
Интересен вопрос людей с большим количеством новостей и категорий, особенно тех у кого новость стазу в нескольких категориях.
Движок хранит новости в текстовой колонке с перечисленными через запятую категориями и в отдельной таблице news_map, каждая строка новость - категория.
Сейчас поиск делается через regexp и так как оно не использует индексы, то на больших базах это выполняется очень очень медленно. Думаю заменить это на поиск в news_map с последующим join с таблицей news.
Интересует что вы подразумеваете под опцией "Категории для отображения (ID через запятую)" и как вы ее используете. И что вы хотите видеть в результатах выдачи.
Я так понимаю, что самое логичное это присваивать новости главную категорию и одну из ее "подкатегорий", что нужно искать, новости в которых полное совпадение (то есть количество и сами категории полностью совпадают) или как сейчас берем каждую категорию новости и ищем все новости из каждой категории в отдельности, а потом берем самые лучшие по просмотрам и т.д.
Должна ли иметь какое-то преимущество главная самая первая категория или нет? Возможно искать нужно только по второй категории, если новость в категории Спорт и Хоккей, то просматриваемые именно с Хоккея должны выводиться, а не со всего Спорта.
Мнения нужны именно по использованию, кто как УЖЕ СЕЙЧАС это использует. Потому что такой поиск через regexp мне кажется ни фига не релевантным и бессмысленным...
P.S. Думаю вопрос прежде всего к Легенде, у него самые посещаемые и нагруженные сайты. Плюс новостные
А где был сбор мнений? Или вы там как-то между собой решаете Какой вариант был выбран?
А ты уже в одиночку решаешь что будет, а что нет или как?
Евгений, ну а чо) Форум мне нужен, как инструмент для решения моих задач, fluxBB с этим не справляется, в частности из-за плохой реализации поиска и отвратительной расширяемости.
В punBB поиск, который мне нравится, он удобен. Расширения ставятся в один клик, могу поставить что захочу без траты времени на обновление. Структура БД схожа с Flux, то есть сконвертировать и переехать будет легко. Он бесплатный. У него есть хорошее сообщество, в том числе русскоязычное.
Вот и все
Такого точно не будет.
Это кто сказал? Я с Виталием говорил, он был не против
Нет, я надеюсь.
Мы переезжаем на punBB 1.4.1, я надеюсь.
z41, то есть хак нужен тогда, когда мы не знаем какие условия пользователь захочет использовать, дать ему гибкость, что в случае прописывания flags вручную ничем не отличается от использования regx, кроме как количеством кода.
Ты не понял, фишку ты зачем сделал? Чтобы использовать только в своих разработках, которые никому не видны, тогда все ОК. Как решение, которое можно применить для всех уже существующих плагинов это не подходит, так как потребует их модификации. То есть зачем такое искусственное ограничение? Зачем что-то передавать в какой-то новой дополнительной переменной flags, когда можно изменить логику хака и проверять сразу значение внутри блока, это не обязательно должен быть параметр, который передается плагином, это может быть и уже готовая внутренняя переменная, например имя пользователя {username}, тогда будет рабочий блок [flag="{username}"]Привет[/flag]
Проблема в том, что ты заменил стандартный байндинг переменных к шаблону, поэтому чтобы хак заработал необходимо хакнуть и все места в плагинах или движке, где происходят нужные вызовы. А это уже очень и очень грубо
Если такой хак и делать, то в виде [flag="myFlag"] text [/flag], и отдельно проверять выражение в скобочках, содержит ли оно какое-то значение или нет.
А лучше просто использовать новый шаблонизатор.
По моему очень неудобно. Никакой наглядности... Зато быстрый и простой способ
Я не знаю, но использовать ничего нельзя без согласования
Еще и нарушает условия использования сайта. А с учетом того, что установить личность любого человека на форуме не составит труда, то отписываться о его использовании по меньшей мере не разумно
Да, пока это обкатка только, веб морду из галочек сделать всегда можно. Это по большей части для тех, кому нужно такое разграничение, чтобы они поклацали и высказали свое мнение.
http://trac.assembla.com/ngcms/changeset/919
+ Для плагинов-новостных фильтров добавлен обработчик onBeforeShowlist(), который вызывается после выполнения SQL запроса, но до запуска основного цикла по показу новостей. Обработчик может использоваться для подгрузки необходимых данных единым SQL запросом вместо генерации пачки запросов по каждой новости.
http://trac.assembla.com/ngcms/changeset/911
!! Это ЭКСПЕРИМЕНТАЛЬНОЕ обновление, на работающие проекты ставить противопоказано !!
+ Добавлено расширенное управление правами доступа к новостям (и пока - только к ним), для каждой группы пользователей настройки заданы в файле-конфиге engine/conf/perm.default.php
ТЕСТИРУЕМ И ОТПИСЫВАЕМСЯ ОБ ОШИБКАХ.
В случае отсутствия ошибок - работа будет продолжена и формат управления правами доступа будет зафиксирован.
Во, теперь и индекс по postdate используется
А, все вижу вижу. В любое случае это довольно сильно тормозить будет на десятках тысячах новостей:)
FROM_UNIXTIME лучше не использовать в левом выражении http://tarlyun.com/mysql/from_unixtime-v-uslovii-zlo/
В итоговом запросе у тебя уже не учитывается, что нужно за последний день выводить новости? У тебя сейчас разыскиваются новости добавленные прямо в эту секунду, их наверное не будет вовсе...
WHERE DATE(FROM_UNIXTIME(postdate))=DATE(FROM_UNIXTIME(UNIX_TIMESTAMP()))
Оптимально сделать так за последние 24 часа
WHERE 'postdate' > UNIX_TIMESTAMP(NOW() - INTERVAL 1 DAY)
Или такой вариант, за сегодня
WHERE postdate > unix_timestamp( curdate( ) )
variables.ini
параметр dots