| Flat |
Отправлено: 3 апреля 2019 — 09:09 • Тема: Мод: Спойлеры • Форум: Модификации и дополнения |
Ответов: 115
Просмотров: 87976
 |
1Bot пишет:Вы меня удивляете, как в браузере будет выполняться jQuery
Имелось в виду также то, что гораздо лучше мод спойлеры реализовать всё же через jquery, при этом мы получим современный дизайн/поведение + кроссбраузерность. По умолчанию все спойлеры открыты(через css) Если у юзера включён js, то они закроютс по умолчанию, и откроются только в случае клика юзера по ссылке. |
| Flat |
Отправлено: 3 апреля 2019 — 06:44 • Тема: EXBB gold edition • Форум: Обсуждаем |
Ответов: 87
Просмотров: 38792
|
1Bot пишет:Вы пришли к самому правильному выводу - нужно использовать sqllite3 для хранения данных в файлах. Очень много плюсов.
Ну, да - если использовать файлы прямого доступа , то есть у же готовая ОТЛИЧНАЯ база для этого, но... во-первых - существует уже много движков которые поддерживают sqlite из коропки - mybb, flatbb, punbb и др, поэтому незачем городить огород и лучше поставить соответствующий форум, во-вторых, как я уже говорил, мы находимся и разрабатываем ФАЙЛОВУЮ версию, причём версию, которой нет равных среди файловых движков. И двигаться нужно в сторону продолжения развития данного движка. То есть чисто на файлах. Поэтому дальнейшие разговоры по поводу перевода exbb на мускул или ещё куда-нибуль ничего хорошего exbb не дадут, мы только потеряем своё время..
А менять надо много чего. Развитие прекратилось потому, скажу вам по секрету, потому, что этому препятствует сама механика структур данных движка. Все боятся большой работы по реструктуризации оного. А я не боюсь: давно уже копаюсь в его внутренностях, поэтому стал опытным хирургом.
К сожалению, все разработчики разбежались, и мне придётся самостоятельно принимать решения. |
| Flat |
Отправлено: 3 апреля 2019 — 02:35 • Тема: Мод: Спойлеры • Форум: Модификации и дополнения |
Ответов: 115
Просмотров: 87976
|
Те, у кого javascript в браузере выключен увидят открытый блок спойлера. Естественно они не смогут его закрывать/открывать, а просто будут видеть информацию, которая заключена в этом блоке. Ничего удивительного тут нет. |
| Flat |
Отправлено: 2 апреля 2019 — 11:37 • Тема: Мод: Спойлеры • Форум: Модификации и дополнения |
Ответов: 115
Просмотров: 87976
|
К сожалению, информация в спойлере не видна тем, у кого отключен javascript - пример плохого юзабилити. Нельзя обделять любых пользователей. Попробую сделать через джейквэри в качестве домашнего задания.. |
| Flat |
Отправлено: 2 апреля 2019 — 06:40 • Тема: EXBB gold edition • Форум: Обсуждаем |
Ответов: 87
Просмотров: 38792
|
1Bot пишет:Есть у меня одна идея для хранения произвольной информации в файлах прямого доступа.
Возможно Вы попробуете ее реализовать.
Я не только думал над этим, но и реализовал часть функций по работе с подобной базой, только без индексного файла. С индексным файлом можно реализовать записи с разной длиной. Я знаком по крайней мере с двумя подобными наработками, которые присутствуют в сети.
В чём тут загвоздка именно для нас?
В том, что гораздо проще не париться, а перевести базу на sqlite, при этом у нас будет та же самая база прямого доступа в одном файле, который для нас доступен. Но тут возникает момент: файл-то доступен, но его практически невозможно редактировать вручную. Даже сериализированный файл уже трудоёмко редактировать, ведь надо высчитать длину поля, его тип, да и правильно всё прописать, что не каждый сможет корректно сделать. А представим, что у нас база прямого доступа. В этом случае файлы становятся абсолютно нередактируемыми. И чтобы исправить что-то в такой базе, надо будет пройти через огонь, воду, и медные трубы.. Править бинарные файлы та ещё мука. Так уж лучше вообще на мускул перейти, там хотя бы следят за целостностью данных. Но это не наш путь.
Нам нужна база, которую легко отремонтировать самим, своими силами. Если слетит мускул, то это катастрофа, если слетит файловая база есть шансы всё поправить в ручном режиме. Я видел админов, которые теряли на мускуле половину загрузок, к примеру, хотя были опытными сисадминами, работающими в компаниях по разработке web приложений. А теперь представьте менее опытного человека.. Думаю не надо будет говорить, что малейшая ошибка в мускуле его может поставить в ступор. Малейшая ошибка в такой базе может поставить под вопрос существование всей базы целиком!
Вот поэтому я и отказался от идеи файлов прямого доступа.
Существующую базу можно легко ускорить на порядок, применив разделение больших файлов типа users на более мелкие фрагменты. Например имеем один файл со всеми emailами, один файл со всеми никами. Или для большей оптимизации делим файлы по номерам пользователей: в файле от 1 до 100 номеров, от 101 до 200 и так далее, или по алфавитному принципу для адресов почты, ников и пр.
Таким образом ускоряем всё на порядок и больше. и имеем форум с 500000 пользователей без мускула.
Вот это и есть наш путь. |
| Flat |
Отправлено: 1 апреля 2019 — 11:52 • Тема: EXBB gold edition • Форум: Обсуждаем |
Ответов: 87
Просмотров: 38792
|
Реализовал систему "длинных" тем, за исключением переноса и удаления сообщений. А так всё пофиксил: множественное прикрепление сообщений, пагинацию, добавления и т.д. Всё работает как часики  . Голову пришлось поломать конкретно. Осталась только реализация переноса и удаления, самая трудная и важная. И хотелось бы посоветоваться, насчёт того, как реализовать это дело..
Тут всего два варианта, как мне представляется:
1) Так как у нас в папке с темой файлы по 60 сообщений в файле, то чтобы всё корректно работало, при удалении надо перераспределить сообщения между этими файлами так, чтобы в каждом из них по прежнему было по 60 сообщений за исключением последнего файла либо первого файла если этот первый файл и последний в теме.
Допустим нам нужно удалить ВСЕ сообщения пользователя во всех темах, форумах и т.д. В данном случае операция перестройки всех тем с его сообщениями довольно затратна и опасна, так как придётся перестраивать все темы, в которых находятся его сообщения. А хочется всё-таки реализовать такую функцию, как удаление все сообщений разом. В этом недостаток подобного способа.
2) В данном случае мы удаляем только тело поста пользователя(текст сообщения), а само сообщение помечаем как удалённое, без перераспределения сообщений между файлами. Данная операция довольно быстра и гораздо менее опасна, так как не требует перестройки темы. При просмотре темы, в которой есть удалённое сообщение, пользователь видит на месте удалённого сообщения текст "удалено".
Конечно, могут найтись люди, которым может не понравится такой вариант, хотя я не знаю причин, при которых людям не нужно видеть информацию о том, что здесь когда-то было сообщение. Но ведь мы не удаляем сообщения пользователей каждый день не так ли? Только сообщения откровенных спаммеров - да, а сообщения зарегистрированных пользователей наоборот чаще подвергаются редактированию админами, чем удалению. Ведь каждый админ заинтересован, чтобы пользователи как можно больше постили своих сообщений, это полезно для продвижения форума. А если часто удалять сообщения без особой на то причины по типу мне не нравится этот человек, то с такого форума люди просто разбегутся.. Да, это будет определённым, незначительным ограничением, но не является ли таковым, сегодняшнее деление тем на множество фрагментов? Мне кажется что первое ограничение ни в какую не может сравнится со вторым, по неудобству для пользователей. А для админов это является скорее чисто психологическим мотивом..
Во втором случае можно довольно быстро удалить все сообщения юзера без опасности что-то запороть, как в первом случае.
Интересно ваше мнение по данному вопросу, так как от его решения будет зависеть каким будет новый движок форума в будущем(данный форк движка). |
| Flat |
Отправлено: 29 марта 2019 — 04:12 • Тема: EXBB gold edition • Форум: Обсуждаем |
Ответов: 87
Просмотров: 38792
|
1Bot пишет:Теперешнюю структуру нет смысла менять, т.к. для одинаковых данных:
Единственно, что напрягает, так это то, что для массивов с большим числом элементов serialize начинает безбожно тормозить. Например есть массив 500 000 элементов, к примеру файл users.php(на нём и проверялось). serialize грузит его 30 сек, а var_export 3 сек. То есть если форум имеет более 100000 пользователей то, всё, приплыли. Но тут можно поделить users на несколько файлов, что может несколько спасти положение.
Некоторые тут задавались вопросом: при каком числе пользователей форум будет тормозить, где предел? Вот он, предел. То есть без перестройки структуры данных мы производительность не поднимем.
1Bot пишет:Дополнительно хочу порекомендовать Вам выставить для тестов у себя настройки как на реальных хостингах:
Спасибо, учту.
-------------
По делам текущим.
Плотно взялся, за создание "длинных" тем. Это самое главное, что не хватает exbb. Если это реализовать то форум приблизится вплотную к гигантам.. При создании темы, в папке data/forums/forum(id)/создаётся папка с темой. В этой папке формируются сами файлы topic(id).php по 60 сообщений в файле, а также несколько подсобных файлов, которые обслуживают тему. Это уже реализовано: автоматически создаются папки и файлы.
По моим прикидкам, такая система не будет тормозить если в теме будет до 60 000 сообщений... Это достаточно даже для супер-форумов.. Далее могут возникнуть определённые задержки при удалении/перемещении сообщений, если удаляемые/перемещаемые сообщения находятся в начале темы. Если они в конце темы, как обычно и бывает, то тормозов не будет и тема может иметь хоть миллион сообщений.
Сообщения удаляются физически. Протестировал: даже при открытии 1200 файлов на это уходит менее секунды, поэтому удалять будем физически с перестройкой темы, естественно с он-лайн проверками на целостность в процессе пересоздания, чтобы ничего не потерять.
Сейчас занимаюсь пагинатором в topics.php, чтобы всё корректно выводилось. Штатная функция пагинатора останется такой же.
Изменены некоторые поля в list.php в файле топика. Например раньше было поле 'state' где было записано состояние темы: состояние темы: open - открыта, closed - закрыта, moved - закрыта и перемещена. Теперь вместо одного поля 'state' два поля - 'isOpen' и 'isMoved', при этом у нас тема может быть одновременно и открыта и перемещена, а не как сейчас. Как сейчас это бред сивой кобылы в тёмную ночь..
Такой же бред кобылы наблюдается и в allforums в полях [stview], [stnew], [strep]. Вместо того, чтобы сделать отдельные поля для каждой группы по типу 'stviewGe' , 'stviewMe', 'stviewMo', 'stviewAd' - кто может просматривать форум? - гости 1/0, пользователи 1/0, модераторы 1/0, администраторы 1/0. Пр этом мы можем по каждой группе выставить права на просмотр, чтение, запись и т.д. Это я уже давно хотел изменить. В этом случае легко выставляются права в любом порядке по группам. |
| Flat |
Отправлено: 27 марта 2019 — 11:33 • Тема: EXBB gold edition • Форум: Обсуждаем |
Ответов: 87
Просмотров: 38792
|
Ещё раз протестировал, но теперь уже не на массивах с числом элементов доходящим до полумиллиона, а на массивах с числом элементов несколько тысяч, но с большим обьёмом информации в массиве. Оказалось, что функция сериализации ведёт себя очень хорошо, и главное быстро, практически не уступая, а иногда и превосходя загрузку текстовой базы, и даже формат var_export..
30 мегабйтный массив с числом элементов 10 000 грузится 0,15 сек., а через var_export 0,57 сек.
То есть где число элементов очень большое, эта функция тормозит, а на маленьком хоть и с большим обьёмом, всё нормально.
Думаю, при таких результатах незачем городить огород с новым форматом, тем более, что сериализированный массив, многие не знают, может хранить в себе бинарные данные, а var_export не может. Преимущество исключительно важное!
Так что остаёмся на старом формате  |
| Flat |
Отправлено: 27 марта 2019 — 10:06 • Тема: EXBB gold edition • Форум: Обсуждаем |
Ответов: 87
Просмотров: 38792
|
Если делить список сообщений, да и список тем, то трудно будет обеспечить сортировку по автору, названию и т.п. Если список один, то его легко отсортировать, но если список разделён по нескольким файлам, то придётся прежде открыть все эти файлы и собрать список в один, и только потом сортировать. Геморрно. А если тема ~ 5000 сообщений? надо будет открыть ~ 100 файлов?
А если пойти по другому пути: по пути оптимизации и разгона форума? Например если применить несериализованную текстовую базу, то скорость загрузки файла обьёмом к примеру 60 мегабайт будет 0,35 сек. Как я уже писал сериализированный массив такого обьёма загружается более минуты, честно говоря я перестал ждать загрузки такого массива через минуту.. На более лёгких массивах разница составляет 32 раза по скорости. К тому же в такую базу легко добавлять новые элементы без полной перезаписи массива, так как это позволяет сама файловая система ОС.
В таком случае мы сохраняем все фичи существующего форума, при этом разгоняем его. Мы можем иметь длинные темы примерно до 60 мегов, и форум по прежнему не будет тормозить. Сейчас темы делятся при обьёме около 300-400 килобайт.
Так стоит ли овчинка выделки? Не проще ли перевести форум на текстовую базу? Ведь сейчас база в общем-то не текстовая, а скорее просто отображения php сущности на файл.
Хочется услышать ваше мнение. Перевести на много более лёгкая задача, чем переделывать практически весь код. |
| Flat |
Отправлено: 26 марта 2019 — 06:57 • Тема: EXBB gold edition • Форум: Обсуждаем |
Ответов: 87
Просмотров: 38792
|
Тема превращается в некий девелоперский блог. 
С файловой базой закончено. Строки останутся с пробелами, как и сейчас. Не зачем ужимать , так как и так она загружается в 2 раза быстрее.
Сейчас приступил к самой важной хирургической операции: созданию "длинных" тем. Всё сделаю горздо проще: при удалении/перемещении сообщения, мы просто заменяем текст сообщения на нечто вроде "(Удалено! - кем-то)/(Перенесено! - туда-то)".
Помню, на одном из форумов был такой слишком ретивый админ, который постоянно тасовал сообщения из одной темы в другую, видимо полагая, что делает доброе дело - тусует то по тематике, причём доходило до абсурда: читаешь тему и видишь, что человек беседует с кем-то, чьих сообщений в теме давно нет, с пустым местом... Такие покоцанные темы читать невозможно, и кроме плевков ничего на ум не приходит. Никогда не понимал, отсутствие хотя бы на месте удалённого сообщения, напоминания о том, что оно здесь было.
Если же оставить хотя бы сообщение о том, что оно удалено, все ссылки если таковые были на него в других сообщениях останутся валидными и при переходе по ссылке сразу будет видно, что сообщение удалено. Друзья, давайте немножко думать и о пользователях тоже и об их интересах, а не только о собственном всемогуществе. Это первое..
Второй этап - налаживание модуля подсчёта онлайн посетителей. Это вторая важнейшая вещь.
Третий этап - новая система шаблонов, тем более, что собственный шаблонизатор уже написан и протестирован. осталось только преобразовать в новый формат все шаблоны.
Всё, приступаю к неотложному вмешательству в тело пациента.  |
| Flat |
Отправлено: 25 марта 2019 — 16:11 • Тема: EXBB gold edition • Форум: Обсуждаем |
Ответов: 87
Просмотров: 38792
|
1Bot пишет:Дополнительно следует добавить функционал при удалении/переносе в другую тему сообщений по перераспределению сообщений между файлами.
Можно просто делать пометку для сообщения "удален"
Физически перераспределять сообщения между файлами с сообщениями плохая и тупиковая идея. Предположим у нас огромная тема, я видел темы с пол миллионом сообщений на одном форуме(они мечтают довести до миллиона сообщений поэтому там приветствуется любой флуд ). В этом случае нужно открыть под сотню файлов с риском потерять или запороть тему, если к примеру сервер отключится от электроэнергии.
Выход я вижу в наличии отдельного файла для каждой темы со списком, в котором записана информация типа: [номер страницы] => array(file => количество сообщений в файле, ). При этом легко вычислить необходимую информацию, которая нужна для определения номера файла и для удаления записи или целог файла если сообщение/я удаляются. В этом случае юзер получает возможность выбрать произвольное число сообщений на страницу, как и сейчас, при этом тема может быть сколь угодно большой!
Этим займусь в первую очередь, так как это самая серьёзная задача по изменению кода ядра на которое завязано многое в движке. много зависимостей фиксить нужно
Но представьте, какое удобство будет иметь целые темы! Наконец-то!
Кстати нужно ввести возможность перехода на произвольную страницу задавая число в поле ввода, как на других форумах. |
| Flat |
Отправлено: 25 марта 2019 — 06:41 • Тема: Перспективы дальнейшего развития • Форум: Новости |
Ответов: 117
Просмотров: 98688
|
Heavenanvil пишет:вопрос уже больше в том, нужно ли вообще дальше пилить движок?
В наше время использовать движок на mysql вообще не проблема
Как по мне, - надо продолжать. Соц сети никогда не заменят тематических форумов. Они просто для этого не предназначены, они предназначены для оглупления, а не для образования. Форум так устроен, что есть отдельная тема, к которой можно всегда удобно вернуться. То, что в соц-сетях сидит большинство, то это не значит того, что меньшинство, которым нравится профессиональное обсуждение какого-то вопроса должны быть обделены вниманием. А сейчас с каждым днём всё меньше людей которые разбираются в веб-технологиях. Дайте ему форум на мускуле, и не дай бог что-то там заглючит с базой, он останется один на один с большими проблемами. Это возможно вы такие продвинутые, но большинство нет, им нужен понятный движок, который можно было бы легко модифицировать и ремонтировать.
Есть машинки, которые ремонтируют сами, и, кстати получают от этого процесса удовольствие, а есть которые ремонтируют в автосервисах за большие бабки, каждому своё, и каждому по его карману и желаниям.
Количество форумов, которые созданы именно на плоских файлах очень велико, как у нас, так и у "них". Вопрос: почему люди выбирают более простую и надёжную вещь вместо сложной и ненадёжной? Посмотрите: вобла начинает глючить при определённом количестве пользователей, замечено на многих форумах, и это проблемы именно с базой, именно там косяки..
Файловый движок ПО ОПРЕДЕЛЕНИЮ быстрее любой СУБД. СУБД может выиграть иногда при поиске и выборке отдельных полей или значений, но если правильно организовать файловый движок, то по скорости он не только не уступит, а во многом переплюнет любой мускул, и это аксиома. Файловая система сама по себе иерархическая база данных.
Heavenanvil пишет:Или создать что-то новое, с использованием современных технологий. Даже готов поучаствовать.
ExBB это чисто файловый движок! Это его фишка! И ему нет конкурентов в своей нише! Он им и должен остаться! Он никогда не переплюнет гигантов на mysql, неужели не понятно? Ну давайте применим какой-нибудь фреймворк, а поверх этого фреймворка ещё один, а поверх... Но давайте подумаем: что из этого выйдет? Из этого выйдет ужасно медленный, глючный, пухлый продукт, который никому не нужен в силу того, что он будет непонятен, непрозрачен и пр. |
|
Сайт проекта ExBB
Чат на форуме
Помощь
Поиск
BanList
Найдено сообщений: 186