Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Идея мне очень нравится! С удовольствием поучаствовал бы. Как раз нужен форумный движок.
простите... А можно вопрос? А почему выбор пал на vue/jquery а не react\riot + jquery?
в разработке
Не в сети
Идея мне очень нравится! С удовольствием поучаствовал бы. Как раз нужен форумный движок.
простите... А можно вопрос? А почему выбор пал на vue/jquery а не react\riot + jquery?
потому что быстрее, с тем, что уже есть.
я вообще сейчас ничего на js вешать не хочу, кроме диалогов, да алертов, кои у меня в пакете lib-appjs уже имеются...
сначала тупо страницы надо сделать... потом умничать будем
Не в сети
так то да! что знаешь на том и быстрее выходит.
после использования многих форумов, хотельось бы простое прикрепление аттачментов аля вконтакте. типо фото\ссылка опрос.
У себя на сайте это реализовал через PolyMorh attachable.
просто почему спросил про riot. я себе сделал начальную реализацию медиа менеджера на riot+jquery. Отсилы за часов 20 сделал.
Изменено fagtr (12.12.2016 16:20:58)
в разработке
Не в сети
Двухдневный трах с приключениями:
Встал вопрос, как реализовать переход по ссылке "последнего поста", - страницу-то (номер) никто не знает, величина динамическая... Где собственно мой пост!?! %)
На обсуждение:
1. Генерю линк поста вида
forums/p-{ID}#post-{ID}
По приходу в контроллер дёргается метод "найди меня", который возвращает номер страницы, где лежит пост (тупой перебор id постов согласно постраничности).
2. Перебрасываем на правильную ссылку темы с номером страницы и якорем, вида
forums/t-{tID}-{seoTitle}?page={PAGE}#post-{pID}
Почему:
(можете попробовать переубедить меня)
- Две ссылки с идентичным контентом ловятся поисковиками на ура. Могут наказать, учтём этот факт.
- Создавать два почти идентичных метода в двух контроллерах - чувство долга не позволяет
Мнение?
Изменено hzone (14.12.2016 19:01:56)
Не в сети
кстати, относительно идентичности.
https://laravel.ru/forum/viewtopic.php?pid=10480#p10480
идентично
https://laravel.ru/forum/viewtopic.php?id=2041
забудем про якорь и сбегаем в гугл, что он на это скажет
Не в сети
Proger, слей обратно темы обсуждения и эту, а? Неудобно .
Не в сети
- Две ссылки с идентичным контентом ловятся поисковиками на ура. Могут наказать, учтём этот факт.
С одной стороны это проблема метода как у FluxBB, а с другой — очень сомневаюсь, что поисковики за это наказывают, т.к. это используется повсеместно. Если злоупотреблять — тогда наверное. Строить карту сайта это задача поисковика, который и делается под сайты, а не наоборот.
Редирект на конечный URL это хорошо, но если пост будет перемещён, то ?pid=… останется неизменным и ссылку менять будет не надо, а вот ссылка после редиректа будет указывать уже не туда, куда нужно.
- Proger, слей обратно темы обсуждения и эту, а? Неудобно.
Предполагалось, что ты сюда будешь анонсы выкладывать, но как хочешь. Склеить?
Не в сети
но если пост будет перемещён
я учёл это, поэтому на входе только пост ид, остальное вычисляемо.
однако возможно в будущем, когда дойдёт до паблик-разработки мы причешем все уголки.
в одно рыльцо-то писать сложновато. мозг один и две руки...
как говорится, - "глаза боятся, а руки из жопы".
да, склей плиз. пусть будет история моего фейла
Не в сети
- я учёл это, поэтому на входе только пост ид, остальное вычисляемо.
Я говорил про выход. Человек добавил к себе в закладки ссылку на пост. Если ссылка неизменная, вида …?topic_id=123#post_id=123 (т.е. ссылка зависит от ID темы, а пост просто прокручивается якорем), то после перемещения поста в другую тему якорь исчезнет и вместо нужной темы (и нужного поста) будет открываться тема, где поста нет.
В случае с FluxBB ?pid=… это не редирект и ссылка не меняется, что бы не происходило с самим постом.
p.s: выложи доступ к форуму для всех и поставь виртуалку на сброс каждые пару часов, если хочешь живого обсуждения с кем-то ещё.
Не в сети
понял о чём ты. подумаю. спасибо за наводку
... а чего тут думать? ссылки на пост отдавать не ссылкой тем и все дела)
Изменено hzone (14.12.2016 22:27:56)
Не в сети
- … а чего тут думать? ссылки на пост отдавать не ссылкой тем и все дела)
Тогда ты возвращаешься к своим же вопросам о том, что одинаковое содержимое отдаётся по разным ссылкам:
- Почему:
- (можете попробовать переубедить меня)
- — Две ссылки с идентичным контентом ловятся поисковиками на ура. Могут наказать, учтём этот факт.
- — Создавать два почти идентичных метода в двух контроллерах — чувство долга не позволяет
Я лично здесь проблем не вижу, поэтому сам сделал бы по принципу FluxBB.
Не в сети
}%> ... а чего тут думать? ссылки на пост отдавать не ссылкой тем и все дела)
Тогда ты возвращаешься к своим же вопросам о том, что одинаковое содержимое отдаётся по разным ссылкам:>> Почему:
>> (можете попробовать переубедить меня)
>> - Две ссылки с идентичным контентом ловятся поисковиками на ура. Могут наказать, учтём этот факт.
>> - Создавать два почти идентичных метода в двух контроллерах - чувство долга не позволяетЯ лично здесь проблем не вижу, поэтому сам сделал бы по принципу FluxBB.
У меня ссылка на пост = постоянный редирект на тему с нужной страницей и якорем, кои вычисляются на странице поста. Даже если пост перемещён куда-то = вычиляется правильная тема.
В целом проблем не вижу.
Следующий вопрос:
* Редактор.
Вот думаю, что нужно писать свой. Почему?
1) интеграция с bbcode движком, чтобы можно было настраивать и добавлять bbcode теги (как не важно, пока в конфиге все настройки), чтобы новый добавленный ббкод не вызывал у редактора отторжения
2) загрузка файлов и картинок без интерфейса. одной кнопкой один файл или много.
2.1) при этом надо решить что делать с загруженными файлами если человек не сохранил пост/тему
3.) вставка аттачей в тело поста, где угодно.
короче идеальный редактор у ipb...
Кто-то работал с CK/tiny редакторами?
Их реально заточить под названные цели?
Опыта с редакторами не сильно много.
Изменено hzone (15.12.2016 11:35:28)
Не в сети
После редактора займусь кешированием...
Сквозные данные, такие как кол-во постов/последний постивший итп уйдут в кеш навечно, пока запущен хост с форумом.
Не в сети
Редактор: выбрал TinyMCE
Сделал пакет-затычку https://github.com/h-zone/laravel-tinymce
Чую пакетов для форума наклепаю, как не знаю чего ))) Прям приключения не по теме.
Не в сети
Это для редактирования сообщений пользователями? А почему именно TinyMCE? CKeditor похуже будет?
Не в сети
Да, для постинга сообщений, их последующего редактирования...
ckeditor:
1)
ссылка http://ckeditor.com/
в редакторе жми изображение => загрузка файла
при условии, что язык определился русский - вёрстка съезжает.
если не покажет - выложу скриншот.
2)
он сложнее tinymce в плане интеграции
3)
знакомый рекомендовал сегодня, аргументировав, что проще интеграция аплоадера файлов/изображений.
Не в сети
- Кто-то работал с CK/tiny редакторами?
- Их реально заточить под названные цели?
Я TinyMCE использовал во многих проектах, хороший редактор, можно как угодно настроить и довольно легко расширяемый.
Но для форума использовать WYSIWYG это плохая идея. Визуальные редакторы очень косячат, в них сложно набирать посты с оформлением и к тому же они выдают грязный HTML. Кто пытался пользоваться редактором с оформлением для веб-почты, где после копировании/вставки едет половина форматирования — поймёт, о чём я. Причём, если будет нужно потом, то сконвертировать посты в markdown/bb-кодах в визуальный редактор можно, т.к. они выдают HTML, с которым и работают редакторы, а вот из HTML в разметку — уже нет.
Не в сети
Я с TinyMCE поработал.. ну, не то, чтобы много, но прилично, поэтому понимаю . Есть там и другие неприятные особенности, например, принудительно вставляет изображения в тэг абзаца. И, вроде как, есть рецепты в сети на этот счет, но у меня лично победить не получилось.
Другое дело, что его можно настроить - оставить лишь самый необходимый функционал, чтобы не особо форматировали.
Не в сети
Мне МСЕ нужен только для ББКодов, Медиатегов. И то хрен его знает, как оно себя поведёт через пару месяцев. Может снесу нафиг и напишу свой редактор. Только не хочу.
Изобращения и файлы будут отдельным пакетом laravel-attachment, который я уже расписать успел даже.
Не в сети
Если нужна ббкод то и наличие редактора то не нужно. Достаточно div contenteditable и с серверной стороны уже обрабатывать ббкод. Я вообще противник всех редакторов ибо проблем от них больше чем пользы.
в разработке
Не в сети
Прогеры могут быть против чего угодно. Прогеров - единицы, а вот основной массе людей, пользующихся форумом, редактор нужнее. Это факт, и спорить с ним глупо. Согласен?
Не в сети
И не всегда за счёт разумности стоит жертвовать аудиторией. В противном случае Продукт не нужен.
Вам бы стоило изучить "коммерческую целесообразность", изучить UI/UX.
Не в сети
- Я вообще противник всех редакторов ибо проблем от них больше чем пользы.
Вот, совершенно верно. Единственный вид более-менее адекватных WYSIWYG это десктопные текстовые процессоры (Word и пр.). В вебе contentEditable это какое-то недоразумение.
Если речь только о быстрой вставке [тегов], то написать свой тулбар это дело часа-двух. Я для FluxBB как-то уже делал такой. Занимает ≈300 строк, и то потому что vanilla JS, без jQuery.
Не в сети
Не в сети
Вот просто по опыту знаю. Что разгрести то что приходит от редакторов ну то ещё занятие. В итоге я плюнул и сделал своё решение для bb и смайлов.
Опять же моё мнение - на том этапе что находится проект нецелесообразно тратить время на эти редакторы, когда других забот вагон. А не проще ли продумать со стороны сервера что вообще должно в итоге попадать в таблицу и сделать нормальную валидацию данных что придут с браузера. А прикрутить редактор это уже совсем другая опера.
в разработке
Не в сети