Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
пока статика...
следубщий этап - выяснение вышенаписаного, а потом система управления.
тоже будем обсуждать
Не в сети
Фух как всегда в коммит уходят баги и недоработки. Вроде всё пофиксил.
Не в сети
GitHub https://github.com/h-zone/laravel-forums-engine
Packagist https://packagist.org/packages/h-zone/l … ums-engine
Установка в README.md
Не в сети
Установка вливает тестовый форумный контент (форумы/темы/посты.
Подразумевается, что у вас есть пользователь с id=1, в противном случае работать фейковый контент не будет
Не в сети
- 1. Оптимально вычислять и хранить (не) прочитанные темы.
Самый оптимальный — в cookie, но это плохо работает, если устройств несколько. Самый очевидный — в отдельной таблице (пользователь + тема), как в FluxBB. Таблица может быть очень большой, но с другой стороны у неё компактный формат (фиксированный размер строки) и она не вызовет больше проблем, чем большая таблица с постами.
Можно хранить в отдельном поле для каждой темы. По умолчанию тема «не просмотрена» всеми; ID пользователя добавляется в этом поле, а при отображении ищется. Формат поля может быть бинарный: ID сохраняются как pack('V'), т.е. ID начинаются на каждый 4й байт и ищутся в цикле типа
$p = -1; do { $p = strpos($s, "\x\x\x\x", $p + 1); } while ($p !== false and $p % 4);
Очень компактный формат. Однако определить ID нельзя, используя функции MySQL, и если это нужно, то лучше использовать строковой формат, где ID разделены, например, |.
- Просмотр темы влияет на рейтинг (от активности пользователей).
Каким образом? Довольно странный получится рейтинг, ИМХО.
- Считать ли гостя? Засчитывать ли повторы от гостей?
Гость вообще никак не должен влиять на статистику, кроме «сейчас на форуме».
- Считать ли поисковики? Если нет, то надо писать механизм определения поисковика.
Если гость на статистику не влияет, то вопрос отпадает сам собой.
- Предполагаю, что просмотр темы зарегистрированного пользовател считать с повторами.
Просмотр это уникальное событие, 1 просмотр это то же самое, что и 10. Иначе нельзя определить заинтересованность людей в теме — может 1000 просмотров это 10 по 100, а может 1000 по 1. Особенно если тема справочная или активная, которую постоянно перезагружают, но только некоторые.
Не в сети
"прочитанные темы"
Я тоже склоняюсь к таблице. так в ИПБ сделано. И я за вертикальную таблицу из 3-4 полей -- она читается катастрофически быстро.
Я использую уже 13 лет только PostgreSQL (начинал с 7.0). Там многое можно положить на триггеры. Например читая строку в таблице автоматом проставить "прочтено". И это отработает до 20 раз быстрее чем на MySQL. В целом я подсел на pgsql только из-за того, что на select он быстрее mysql в 15-20 раз. С того времени прижилось как-то.
"рейтинг"
Он не странный, просто ты не встречал ещё подобных алгоритмов, что впрочем 99% программистов рнр - пользователи, а не разработчики приложений ;-)
Как это работает:
У нас есть просмотры темы, лайки, входы по внутренней ссылке, входы на страницу извне сайта. Если каждому действию придать "вес", и тупо пересобирать рейтинг множением, то можно получить цифры, основанные на активности пользователей. Про механизм хранени я болтать не буду - время жалко. Со временем количество допустимых действий можно ростить от появления новых фич.
"Гость"
в некоторых проектах "гость" = пользователь №1. и от него много чего зависит. но пока пофиг, соглашусь.
"Поисковики"
Ох не факт. Не факт. Поисковика по хорошему надо отслеживать, и не пускать куда-то на программном уровне. Например Если возникает необходимость гостям показать страницу со ссылкой, а поисковикам показать "иди вон!". Например торрент-трекер. Страница находится по ссылке/ключевым словам, но поисковик ни разу не видел прямой ссылки. Про nofollow не надо говорить - оно всё равно в индекс попадает, а надо тупо отрезать эту фичу.
Поэтому подобное надо учитывать, однако на этом этапе соглашусь, - не влияет на данный проект никак.
Не в сети
- Я использую уже 13 лет только PostgreSQL (начинал с 7.0). Там многое можно положить на триггеры. Например читая строку в таблице автоматом проставить «прочтено». И это отработает до 20 раз быстрее чем на MySQL. В целом я подсел на pgsql только из-за того, что на select он быстрее mysql в 15-20 раз. С того времени прижилось как-то.
Против PgSQL никто не спорит, но если ты завязываешься на «массового потребителя», то рассчитывай в первую очередь на MySQL.
- У нас есть просмотры темы, лайки, входы по внутренней ссылке, входы на страницу извне сайта. Если каждому действию придать «вес», и тупо пересобирать рейтинг множением, то можно получить цифры, основанные на активности пользователей.
Это не рейтинг, это активность. Человек может по сайту не ходить, отвечать раз в сто лет и при этом его будут плюсовать больше, чем какого-нибудь флудера. В этом случае показатели рейтинга и активности будут противоположные.
- в некоторых проектах «гость» = пользователь №1. и от него много чего зависит. но пока пофиг, соглашусь.
В FluxBB, phpBB и т.п. тоже есть такой пользователь (в phpBB, кажется, даже по пользователю на каждый распознаваемый поисковик). Это удобно, если допускать гостевые посты, как на laravel.ru. Но учитывать поисковиков и гостей в просмотре тем бесполезно — лучше уж сразу добавлять ко всем новым темам +1 на каждую такую служебную запись.
- Если возникает необходимость гостям показать страницу со ссылкой, а поисковикам показать «иди вон!». Например торрент-трекер. Страница находится по ссылке/ключевым словам, но поисковик ни разу не видел прямой ссылки. Про nofollow не надо говорить — оно всё равно в индекс попадает, а надо тупо отрезать эту фичу.
Не в сети
Вендор БД.
У нас всё просто - PDO
Рейтинг/активность.
Рейтинг от активности лучше рейтинга от оценки.
Почему?
Потому что оценивают не все и не всё. Активность же прозрачным слоем лежит на предмете вопроса.
Плюсы/лайки да и впрочем оценки тоже = активность. Не?
Не в сети
Далее - по управлению форумом.
2 дня думал "КАК".
Прихожу к мнению, что Web 2.0 -- без админки. На базе прав пользователя.
Админ видит кнопку "удалить тему", Модератор "спрятать тему" итд.
Каждый пользователь видит свой набор ссылок и кнопок, доступных ему в этот момент времени. Основываясь на группе форума. Один пользователь может нести много групп.
Почему без Админки - потому что у самого движка ларавел в этот момент может стоять админка, о которой производитель форума и слыхом не слыхивал, и писать модельный ряд подо все админки - писать ради писанины.
Однако есть смысл создать визуальную блок-схему, а так же функциональные блок-схемы, по окончании разрабтки, чтбы пользователи могли сами интегрировать форум в свои админки.
Не в сети
- Вендор БД.
- У нас всё просто — PDO
У «вас» не всё просто — если тут триггеры, то PDO никаким боком не поможет.
- Потому что оценивают не все и не всё. Активность же прозрачным слоем лежит на предмете вопроса.
Хм, вопрос спорный, но допустим. В любом случае, называй вещи своими именами, раз это активность, то пусть она так и называется. «Рейтинг», который «набивается» собственным хождением по форуму, так не называется; рейтинг это всё же оценка другими участниками кого-то одного.
- Каждый пользователь видит свой набор ссылок и кнопок, доступных ему в этот момент времени. Основываясь на группе форума. Один пользователь может нести много групп.
В чём новшество? У любого форума так же. Тот же FluxBB имеет кнопки под постом (пожаловаться, удалить, править, цитировать), которые зависят от уровня пользователя, плюс ссылки внизу страницы (модерировать тему, перенести, закрыть, закрепить).
Но отдельный раздел для настроек нужен в любом случае, так как, например, настройки SMTP, maintenance mode и пр. никуда не выведешь, кроме как на отдельную страницу. Либо всё держать в config/…php.
Не в сети
Главная проблема, почему не хочу ставить ничего нового (написанное кем-то из нас или со стороны) - не уверен в качестве кода.
По качеству кода одним из лучших является XenForo. Хотя и его код на данный момент уже устарел немного, по отзывам он остается все равно на порядок лучше конкурентов.
Совсем недавно они выкатили демо-бету второй версии. Внешне вроде не сильно изменилось, но для разработчиков плагинов обещают еще лучшие возможности. Пока неясно, какой фреймворк используется (версии 1.* были на первом Зенде).
Из минусов конечно же его не бесплатность (но цена не то, чтобы уж кусается). Ну и такая мелочь, как не самый лучший скин по умолчанию.
- Complaint (жалобы на темы/комменты)
Мелочь конечно, но тут лучше Reports подойдет.
Не в сети
ох, блин, люди, вы в программировании видно не давно.
КРАТКОСТЬ - СЕСТРА ТАЛАНТА!
Уже читать СТЕНЫ ни желания ни времени нет!
Хватит уже дискутировать. Есть альтернативное предложение - предлагайте, нет - ваше мнение возможно будет прочитано.
Старайтесь без стен текста, особо к Proger_XP относится.
Не в сети
По порядку.
Триггеры с PDO вообще не связаны. Речь шла о синтаксисе, да и в ОРМ синтаксис держит тот же ПДО. Повторяю речь шла об облегчении кодинга, средствами ОРМ.
Был большой проект (может кто помнит iSlava.ru - видео/аудио-конкурсы талантов), там рейтинг формировался из голосования (5 звёзочек), оценки (те же 5 звёзд), принятых смс, активности просмотра/входа на страницу, шаринга итп итд - учитывалось абсолютно всё возможное на тот 2007й год. Рейтинг писал я. Хочу эту же систему внедрить в рейтинги тем. Но исключить возможность голосования/оценки темы, так как считаю этот инструмент морально устаревшим.
__ возможно пересмотрю своё решение __ когда доберусь до реального проектирования рейтингов, а пока не стоит этого обсуждать. как что-то будет разумное, я сразу тут выпалю всю идею на суд.
Про веб 2.0 и отказ от админки, - мне не понятно вообще что мы обсуждаем.
Будет интерфейс назначения пользоватебя администратором/модератором. В качестве админки этого достаточно.
Настройки пока в конфиге. если кто-то возьмётся рефакторить на настройки в бд - флаг в руки, я только за.
По репортам вместо жалоб.
Жалоба - это конкретное действие в конкретном контексте.
Репорты же подразумевают разный контекст и "размытое" действие. Так вот попрошу развернуть, где ещё можно использовать репорты в контексте форума. И попрошу не путать со статистикой и аналитикой. Если докажете (продадите идею) - будут репорты.
Не в сети
Не в сети
Не в сети
Не в сети
К началу февраля потребуется проф верстальщик для допиливания.
Понадобится сделать несколько цветовых тем.
Не в сети
Будет время, допилить помочь могу. Верстаю неплохо, стаж в этом деле лет шесть, работал верстальщиком в серьезных командах. Но только если верстка на bootstrap 3, потому что уже не хотелось бы связываться с чем-то другим.
Не в сети
Будет время, допилить помочь могу. Верстаю неплохо, стаж в этом деле лет шесть, работал верстальщиком в серьезных командах. Но только если верстка на bootstrap 3, потому что уже не хотелось бы связываться с чем-то другим.
3й, но скоро надо будет и 4й заюзать.
vue знаешь? тоже интересно... однако на потом, пока аяксов нет - нет смысла дёргаться.
Не в сети
Сейчас как-раз осваиваю связку bootstrap-ajax-laravel. На своем проекте реализовал функционал с модальными окнами, в которые подгружаются представления. Кроме того, реализовал подгрузку представлений в информеры bootstrap.
Не в сети
Я в почту написал тебе
Не в сети
Спасибо.
Не в сети
Вынес себе мозг, но частично автоматизировал кеширование информации о последнем посте в дереве форумов... Хех.
Делалось ради отказа от hasManyThrough с учётом того, что форумы имеют parent'а и сами вложены в группу форумов...
Вопрос, кто проводил стресс-тесты веб приложения?
Интересен опыт. Параметры, аргументы "почему так".
Чую, что пора смотреть стресс-тест. Главная страница самая нагруженная аналитикой уже.
Изменено hzone (10.12.2016 04:43:24)
Не в сети
Прогресс:
+ Создание поста
+ Удаление поста
+ Немного UI без UX
+ Оптимизации кода
+ Интеграция пакета (в будущем через композер) http://github.com/h-zone/lib-appjs/ (демка)
Жаль тут нельзя картинки цеплять к посту упарился с тормозными хостингами картинок
Изменено hzone (10.12.2016 16:08:32)
Не в сети
упарился с тормозными хостингами картинок
Используй imgur.com, он не тормозной.
Не в сети