В сей нити мы упорядочиваем усилия по доработке местного движка. Репозиторий: https://codeberg.org/FBE410/fbe-410 1. Для ваших предложений предназначена ветка public. 2. Только администрация 410чана решает, что в этом движке надо, а что не надо. Соответственно, не стоит излишне пропихивать всякие там революционные идеи. Одобренные потенциальные изменения перечислены на багтрекере (записи, созданные владельцами репозитория). 3. Тестирование предложенных изменений и развёртывание принятых ведётся при наличии у администрации свободного времени на это. Обычно это делается по выходным. 4. Код выложен как есть. Никаких неопубликованных скрытых функций и частей не существует. Предыдущая нить: >>20450
>>28097 Функция «Убрать фреймы» на самом деле не сломана, а имеет misleading сообщения про. Не «Фреймы убраны», а «Фреймы будут убраны» — по переходу на страницу доски. Может, лучше сделать в виде checkbox’а. > и которыя оттого не оснащены никаким значением перемѣнной max_message_length Аа, вижу. Не сколько из-за отсутствия формы, сколько из-за того, что оно ту переменную для несвязанных с досками страниц не пишет в head. Если не пишет.
Чуть болѣе восьми лѣтъ назад (в декабре 2017 года, как это по адресу https://410chan.org/dev/arch/res/17371.html#18031 может быть видно) я начал досадовать о том, что движок 410чана замѣнялъ апостроф в именах файлов на нѣкій кодъ. В сентябре 2018 года (как это по адресу https://410chan.org/dev/arch/res/20450.html#20583 может быть видно) я дополнительно подосадовал о том ещё, что правки, мною в код движка внесённыя для исправления именно этого поведения его, не смогли достигнуть желаемого. Вид имени файла, к сообщению >>/b/199156 прикрѣплённаго, свидѣтельствуетъ о том, что проблема эта наблюдалася ещё в январе 2023 года. Вид имени файла, к сообщению >>/a/19830 прикрѣплённаго, свидѣтельствуетъ о том, что проблема эта исправлена была, по меньшей мѣрѣ, к маю 2024 года. А теперь — уточняющий вопрос: кто-нибудь сможет ли указать ту конкретную правку кода, которою желаемое поведение движка было тогда достигнуто наконец?
>>27866 Пока работа стоит, придумываю, как это могло бы выглядеть.
Реквест >>28097 был в середине декабря, сейчас конец января, никакой мёрдж до сих пор не произошёл, разскажите почему. Дополнительно сообщаю, что теперь ужé больше двух лѣтъ каждая новая версия каждого браузера способна показывать AVIF, а в спину ей начинает дышать уж и поддержка формата JPEG XL, которую во Хром на днях прибавили¹ за флагом², да и в Mozilla Firefox её прибавили ≈одиннадцать часов назад³ за флагом же, так что Firefox 149 предположительно способен выйти с возможностью включать поддержку JPEG XL в настройках (если эту возможность пропустят далѣе ночной сборки). ____________ ¹ О появлении поддержки JPEG XL во Хроме можно прочесть по адресу https://www.opennet.ru/opennews/art.shtml?num=64639#:~:text=В%20Chrome%20Canary,Rust%2E ² Флагом здѣсь по традиции называется возможность в настройках браузера включить нѣкоторую функцию, по умолчанию выключенную. ³ Момент появления поддержки JPEG XL во браузере Mozilla Firefox можно обнаружить в комментарии https://bugzilla.mozilla.org/show_bug.cgi?id=1986393#c47 в Багзилле.
>>28137 Да пока ещё предыдущий реквест не засунули на сайт, а этот даже не смотрел пока никто. Работа встала, сказано же.
Возможно, в течение следующих двух недель напишу код для отображения в заголовке страницы темы треда или его номера, если в теме пусто. Как быть со страницей каталога и с ненулевыми страницами досок?. "Авто/b/ус | Каталог"? "Каталог | Авто/b/ус"? "Авто/b/ус | Страница 4"? Точно ли стоит "—" в качестве разделителя, а не более короткие "-" или "|"? С более коротким, чуть больше места под значимую информацию останется.
>>28144 >Точно ли стоит "—" в качестве разделителя, а не более короткие "-" или "|"? С более коротким, чуть больше места под значимую информацию останется. При длинных названиях всё равно толку не будет от пары пикселей сэкономленных, а с номерами вообще без разницы. Я вижу, что на сайтах практикуется формат «Название контента — Имя сайта». Теоретически, можно вообще сделать схему «Тема/номер/Название страницы — /доска/ Имя сайта». Это поможет лучше идентифицировать контент.
>>28081 Тесты показали, что массовое удаление хоть и работает, но фактически вешает движок на некоторое время. Это как-то можно исправить?
>>28151 Можно, оптимизирую.
Пока ждём оптимизатора, давайте обсудим ещё одну идею, которую никто не станет запиливать. Давно была мысль (и кто-то где-то её даже реализовывал), что можно присобачить метки (тэги) для категоризации нитей для общего удобства поиска нужного содержимого и как альтернативу открытию отдельных досок. Главная проблема, как мне кажется, заключается в том, делать ли список доступных меток официально закреплённым или разрешить пользовательские. Во втором случае есть некий простор для злоупотреблений: придётся некий чёрный список делать. Возможно, стоит одобренные и пользовательские в интерфейсе разделить на два типа? При этом у модераторов в любом случае должна быть возможность их проставлять и изменять. Вроде бы в недрах «Сэриссы» даже были какие-то зачатки категоризации для какого-то отдельного типа досок, как будто бы можно это даже взять за основу. Дисскасс.
Раз >>28129 в итоге все проигнорировали, выложил значок нити: https://coyc.net/files/thread.svg Как обычно, для использования в движке следует прогнать через оптимизацию.
>>28129 >>28189 Хочу взяться за эту задачу в какие-то из выходных, но реализация этого желания постоянно осложняется тем что надо развернуть все заново (и через докер уже тогда бы все сделать) + общими проблемами со временем
>>28153 Сделал BulkDeletePosts, привязал к нему удаления с board.php и удаление по IP с manage.class.php. Другие достижимые (multidel, судя по всему, нет) функции про удаление в manage.class.php — удаление тредов (в частности, в архив), удаление одного поста и quckpurge я не трогал. К похожей функции привязаны report'ы. Захардкодил ограничение к запросу на жалобу/удаление от обычного пользователя 256 IDшниками. Также ограничил максимальное количество несовпадений пароля при удалении до 16 IDшников. Можно потом будет вынести в config.php. Можно, как и раньше, без ограничений, если есть желание оставить возможность запихать все id'шники в один запрос и от-report'ить им всю доску, или массово подбирать пароли. По-хорошему тут либо капча нужна, либо/и некий сложный учёт аномального поведения, который у меня пока писать желания нет. Смотрите, как работает. Патч в архиве.
Содержимое заголовка «server», предваряющаго собою HTTP-отклик сёрвера 410чана, говорит о том, что в роли сёрвера трудится Apache 2.4. Содержимое заголовка «content-encoding», предваряющаго собою HTTP-отклик сёрвера 410чана, говорит о том, что и всѣ джаваскрипты, и всѣ стили CSS, и всѣ HTML-страницы сайта передаются сжатыми по стандарту gzip (и это хорошо), тогда как иллюстрации сжатыми не передаются (и это также хорошо, потому что современные форматы иллюстраций предполагают такую силу сжатия их, к которой доужатие в gzip ничего не смогло бы прибавить, а только напрасно тратило бы усилия процессора на сёрверной стороне и во браузере). Правда, стандарт gzip появился в 1992 году (больше 33 лѣтъ назад), и с той поры появилися чуть болѣе эффективные средства экономии траффика. Я говорю прежде всего о стандарте Brotli, который ещё в 2017 году добрался до поддержки каждою новою версиею каждого из современных браузеров (послѣднимъ из которых поддержал Brotli браузер Safari 11, как о том в таблице https://caniuse.com/brotli пишут). И больше того: в документации по Apache изложен по адресу https://httpd.apache.org/docs/2.4/mod/mod_brotli.html#precompressed тот способ, которым передача файла, сжатого по стандарту Brotli, может быть включена только для готового (предварительно сжатого) содержимого — то есть, напримѣръ, чтобы файл https://410chan.org/lib/javascript/kusaba.js передавался с сёрвера сжатым при помощи Brotli тогда и только тогда, когда на сёрвере рядом с файлом «kusaba.js» лежит готовый файл «kusaba.js.br», из которого-то и берётся передаваемое содержимое. (При этом другим необходимым условием является поддержка Brotli во браузере, но если её нѣтъ, то и это не конец свѣта: Apache просто-напросто откатится ко сжатию gzip.) У подхода с готовыми файлами есть и достоинство, и недостаток. Достоинство состоит в том, что если не тратить процессорное время сёрвера всякий раз при передаче файла, а брать итог готового сжатия, то тогда вообще ничего не мѣшаетъ заранѣе сжать этот файл на максимальных настройках сжатия Brotli. (Не приходится думать «ѽ, это занимает изрядную долю секунды — не быстрѣе было бы ужé передать файл, сжатый чуть хуже, но зато въ болѣе быстром режиме работы?».) Под Windows достаточно вытащить файл «brotli.exe» из архива https://github.com/google/brotli/releases/download/v1.2.0/brotli-x64-windows-static.zip и затѣмъ подать команду наподобие «brotli kusaba.js» (она по умолчанию работает на максимальной степени сжатия) для того, чтобы содержимое файла «kusaba.js» (сейчас это 97 520 байтов) ужать в файл «kusaba.js.br» (22 211 байтов), что экономит дополнительно 13½% траффика по сравнению съ нынѣшним gzip-сжатием файла https://410chan.org/lib/javascript/kusaba.js (при скачивании которого заголовок «content-length: 25698» сообщает об объёме gzip). Недостаток состоит в том, что тогда изготовление br-файла придётся всякий раз дѣлать при обновлении джаваскриптов и CSS на сёрвере, чтобы не осталась в br-файле старая их версия сжатою. (Правда, можно же сочинить и скрипт, который будет пробѣгаться по всѣмъ br-файлам, сравнивать их время со временем рядом лежащих оригиналов и обновлять при необходимости.) На слѣдующемъ шаге и в движке FBE также можно предусмотрѣть настройку, включение которой будет опосля создания файла «циферки.html» запускать команду «brotli --force циферки.html». Стóит того дюжина процентов экономии траффика или не стóит? Сразу скажу, что в близком будущем можно будет ещё далѣе наращивать силу сжатия, заранѣе подготавливая не один только сжатый файл, но и сам словарь повторяющихся кусков файлов, для сжатия используемый — эта возможность по адресу https://httptoolkit.com/blog/dictionary-compression-performance-zstd-brotli/ упомянута — но в настоящее время её поддерживает один только браузер Chrome 130 и новѣе, а также его производные (Edge, Opera и проч.). И в Apache настроить эту возможность пока ещё никак нельзя, насколько я понимаю. Но она сулит в будущем два достоинства: ① Можно увеличить силу сжатия на нѣсколько процентов, если одну из страниц сайта (рѣдко измѣняющуюся) подсунуть браузеру в качестве словаря, подходящего для сжатия всѣхъ остальных страниц (в качестве источника общих подстрок элементов интерфейса сайта). Прямо сейчас файл https://410chan.org/b/res/209918.html (объёмом 558 749 байтов к моменту моей провѣрки) командою «brotli res/209918.html» ужимается до 56 823 байтов, тогда как командою «brotli --dictionary=misc.html res/209918.html» (с использованием страницы https://410chan.org/misc/res/1.html в качестве такого словаря) он же ужимается до 54 631 байтов (на 3,86% сильнѣе). ② Можно увеличить силу сжатия до много большей, если прежнюю версию джаваскрипта или CSS (ужé скачанную, ужé лежащую в кэше браузера у читателя) использовать как словарь для сжатия новой версии. Фактически при этом объём доставляемых новых данных столь мал, что близок к объёму диффа (патча), содержащего разность между новой и старой версиею скрипта или стиля, да ещё и доужатого.
Сразу прибавлю, что ещё сильнѣе радует результат сжатия Brotli, когда в качестве готового словаря используется не одна из страниц сайта «как есть», а дистиллят цѣлой сотни страниц его. Я сегодня составил список URLов, включающий в себя: ① адреса первой двадцатки нитей обсуждения со страницы https://410chan.org/b/catalog.html ② адреса первой двадцатки нитей обсуждения со страницы https://410chan.org/cu/catalog.html ③ адреса первой двадцатки нитей обсуждения со страницы https://410chan.org/dev/catalog.html ④ адреса первой двадцатки нитей обсуждения со страницы https://410chan.org/a/catalog.html ⑤ адреса первой двадцатки нитей обсуждения со страницы https://410chan.org/ts/catalog.html Затѣмъ я зашёл на страницу https://use-as-dictionary.com/generate/ и скормил ей всѣ эти URLы с просьбою изготовить словарь объёмом 12 килобайтов из этих HTML-страниц — и получившийся словарь я сохранил под именем «dictionary410.dcb». Затѣмъ я повторил с ним эксперимент из моего предшествующего сообщения и увидал, что результатом работы команды «brotli --dictionary=dictionary410.dcb 209918.html» теперь является файл, состоящий всего-навсего из 54 309 байтов — это на 4,4% меньше, чѣмъ результат сжатия без словаря, состоящий из 56 823 байтов. (Сразу скажу, что для чистоты эксперимента я наперёд убедился в том, что страница https://410chan.org/b/res/209918.html не попала в двадцатку недавних нитей своего раздѣла, так что сила сжатія ея не может объясняться попаданием уникальных кусков этой страницы в словарь.) При этом сам словарь также можно обработать командою «brotli dictionary410.dcb», ужать до 3277 байтов. По адресу https://uploadbay.net/uploads/OJORMde9G.br я выложил итог этого сжатия на тот случай, если словарь 410чана понадобится в будущем, а генератор https://use-as-dictionary.com/generate/ будет ужé выключен. Нетрудно сосчитать, что такой не очень большой объём сжатого словаря (чуть болѣе 3⅕ тыщщи байтов) окупается экономиею, достигаемою ростом сжатия всего двух таких крупных страниц, как https://410chan.org/b/res/209918.html (чуть болѣе 2½ тыщщи байтов экономии на каждой, как показано тремя абзацами выше), ну или трёх страниц вдвое меньшаго объёма. Поэтому словарь оказывается много экономичнѣе, чѣмъ замысел подсовывать страницу https://410chan.org/misc/res/1.html в кэш каждому читателю, как было бы в наивном примѣрѣ из предыдущего сообщения. Теперешний примѣръ ужé не создаёт возможности всерьёз подозрѣвать, что приход к использованию готовых словарей в будущем — это палка о двух концах, силою которой на раздачу словарей можно потратить больше траффика, чѣмъ затѣмъ сэкономить на использовании этих словарей.
>>28193 Это всё небезынтересно, но в условиях маленького низкопосещаемого сайта как будто бы не имеет особого смысла. Пара-тройка килобайт со страницы в экономическом и техническом смысле будут ощутимы только при большом трафике, которого у нас нет.
Подумал над тем, как можно сделать блок избранных картинок на главной в отсутствие частого оригинального контента. Будем исходить из четырёх ячейки для картинок, как на соседнем сайте. Соответственно, в модерке можно загружать картинки, чтобы они отображались на главной (картинка, ссылка, опциональная подпись). Загруженная картинка на какой-то срок считается «свежей» (можно сделать месяц по умолчанию, и настраиваемый в модерке от любого времени вплоть до бесконечности) и показывается на главной всегда принудительно. И вот сколько в модерке сейчас висит «свежих» из четырёх, столько и показываются всегда, а в незанятых ячейках показываются «несвежие» случайным образом. Очевидно, для экономии трафика надо уменьшенные копии генерить и их выводить. Для архива картинок надо сделать подобие галереи в качестве подстраницы главной. В целом, технически это похоже на задачу https://codeberg.org/FBE410/fbe-410/issues/58 с баннерами, но они-то статически обновляются, а тут вопрос в том, насколько проблематично присобачить динамический показ рандомных картинок к главной. Задачу пока заводить не буду, потому сначала надо сделать https://codeberg.org/FBE410/fbe-410/issues/11 всё равно, а этим никто не хочет заниматься.
Здравствуйте. Мы нашли проблемы в вашем и нашем движке: https://codeberg.org/yakui-lover/fbe-410/issues/6 https://codeberg.org/yakui-lover/fbe-410/issues/9 Стоит заметить, что проблемы искались в ветке kotocafe, но большая их часть затрагивает и вас. Вы заинтересованы в исправлениях от нас?
>>28230 Какой-то странный вопрос. Если вы нашли уязвимости и готовы их чинить, присылайте реквесты, конечно. >function random_appeal Это, скорей всего, делалось для показа случайного обращения основателя, когда их в 2011 году было три. Этот код должен исчезнуть или быть изменён при реализации https://codeberg.org/FBE410/fbe-410/issues/58
>>28231 Единственные «уязвимости» в issue #9. И они не такие серьёзные. Мы пока сами обсуждаем и возимся с ними. Вопрос был в том, заинтересованы ли вы в исправлениях некритичных проблем. Их там много. Если заинтересованы, то как лучше их вам засылать. И насколько вы нам верите, что там действительно какая-то проблема, или же нужно описывать, как воспроизвести на практике.
>>28232 Этот движок пилится (пилился, сейчас почти все умерли) силами сообщества, любой желающий может присылать свой код. Для засылания кода есть репозиторий. Какой там код, и насколько он нужен — будет проверяться по факту его поступления. А потом уже могут быть вопросы по воспроизведению и всему остальному. В целом, по ненужному/заведомо нерабочему коду нужно руководствоваться принципами из https://codeberg.org/FBE410/fbe-410/issues/43, по рабочему, но содержащему ошибки — https://codeberg.org/FBE410/fbe-410/issues/15 Я вот точно пока могу сказать, что «поддержку» СВГ можно смело убирать, потому что она всё равно никогда не работала, и задачи на её доработку не висит (и я не буду её ставить, потому что оно не надо, а велосипед пришлось бы знатный городить, чтобы обойти потенциальные угрозы, если это вообще возможно).
>>28222 Технически это совсем не похоже на задачу с баннерами. Куда больше мороки. Картинкам нужен будет ещё один "thumb" под главную, если не тратить время на регенерацию файлов уменьшенных копий на главной при каждом её изменении. Но вполне реализуемо. Случайные картинки на главной должны меняться по добавлению/удалению поста с картинкой или по каждому F5 страницы? Если автор поста свой пост удаляет, то (закреплённую) картинку из этого поста с главной удалять тоже? > Для архива картинок надо сделать подобие галереи в качестве подстраницы главной ?? В архив добавлять отображаемые на главной картинки по каждому изменению тех картинок или когда?
>>28235 >Технически это совсем не похоже на задачу с баннерами По-моему, тут только джва аспекта отличаются: что баннеры не надо обновлять по F5 и не надо скукоживать при показе на страницах (но в галерее, наверное, надо). >Случайные картинки на главной должны меняться по добавлению/удалению поста с картинкой или по каждому F5 страницы? Очевидно, что по F5. >Если автор поста свой пост удаляет, то (закреплённую) картинку из этого поста с главной удалять тоже? Как сказано: «в модерке можно загружать картинки». Вроде бы самоочевидно. Удаление картинки с главной и архива только через модерку потом. >В архив добавлять отображаемые на главной картинки по каждому изменению тех картинок или когда? Да сколько было загружено картинок, столько и отображается. Смысл в том, чтобы пользователь мог посмотреть все картинки, которые были на главной за всё время.
>>28236 Ясно. В таком случае относительно просто всё. > Вроде бы самоочевидно Я заблудился и «в модерке можно загружать картинки» почему-то понял не как загрузку в буквальном смысле: прочитавше как на соседнем сайте, и глядючи, как там под картинками висят надписи изображение из треда в /b/, подумалось, что добавление картинок на главную осуществляется выбором ID постов с ними: либо случайным, либо в модерке. > Очевидно, что по F5. Не когда подумалось предыдущее и когда написано про схожесть с задачей про баннеры.
Ну, предположим. Какое расположение картинок (пока взял с соседнего сайта) лучше? 1.
2. Совсем в подвал как-то не охота пихать, мне кажется, там должна быть какая-то совсем неинтересная лабуда типа блоков со статистикой или что-то такое. В плане размеров и выравнивания картинок тоже можете предлагать варианты, а то сейчас выглядит не очень.
>>28253 А что если впустить больше света?
Предлагаю даже чуть более радикально.
>>28255 >>28254 Это точно отказ, у нас весь десигн через эти полоски. А так только огромные пустые поля образуются без какой-либо практической пользы.
>>28256 Список "display: flex;" с элементами постоянной высоты с "flex-grow: 1" в теории должен работать как-то так. Если добавить "flex-wrap: wrap;", будет работать примерно как inline-блоки, но края слева и справа у строк будут ровные. https://css-tricks.com/adaptive-photo-layout-with-flexbox/
>>28257 > flex-wrap: wrap Я бы рекомендовал чуть ниже прибавить и «flex-wrap: balance» для браузеров, на Chrome основанных. (А браузеры, не понимающие это свойство, проигнорируют его и останутся на «flex-wrap: wrap».)
>>28257 В теории это прикольная штука, но на практике я не осилил. Попробовал на соседнем сайте, у меня оно всё время выезжает за пределы экрана, а в варианте на мобилках вообще нечто неведомое. Хорошо бы готовую вёрстку на примере блока с главной «Ычана» (я бы её туда и присобачил потом).
>>28259 Чтобы красиво по ширине выравнивалось, придётся жертвовать обрезанием по вертикали. HTML: https://dpaste.com/6B543L7TV CSS: https://dpaste.com/326SX22BD
Темпы обновления браузеров Всемірной Паутины таковы, что подавляющее большинство пользователей обновляет свои браузеры минимум один раз в течение 30 мѣсяцевъ. Больше того: если кто не обновил свой браузер в течение 30 мѣсяцевъ, то нѣтъ большого смысла ждать его дольше с надеждою на то, что обновит — болѣе вѣроятно, что всѣ такие люди находятся в каких-либо ситуациях, властно препятствующих обновлениям браузеров их, и выход из таких ситуаций случается рѣдко и непредсказуемо (напримѣръ, с приобретением новаго компá или новаго мобильнаго устройства черезъ нѣсколько лѣтъ). То и другое мнѣніе сайтом https://web.dev/baseline излагается с опорою на накопленную статистику (прежде всего гугловскую, оттого что и сам сайт этот является гугловским, насколько я понимаю) — и дѣлается вывод, что по прошествии 30 мѣсяцевъ можно считать любую фичу WWW широко доступною (widely available), если во всё это время она поддерживалась всѣми новыми версіями всѣхъ сколько-нибудь популярных браузеров. А вѣдь прошло чуть болѣе 30 мѣсяцевъ с того дня (25 января 2024 года), в котором (как это теперича по адресу https://learn.microsoft.com/en-us/deployedge/microsoft-edge-relnote-archive-stable-channel#version-1210227783-january-25-2024 рассказывается) появилась очередная версия браузера Microsoft Edge, наконец содержавшая поддержку AVIF. И всѣ остальные браузеры ужé содержали поддержку AVIF к тому времени. Поэтому я в очередной раз призываю прибавить к 410чану поддержку AVIF, но теперь уж нифигушеньки не сдерживая себя заботою об обладателях весьма старых браузеров, не способных смотрѣть AVIF. Исходный код подготовлен в 2024 году (>>27746), конкретный практический смысл был изложен в 2025 году (>>28037).
>>28264 А фреймы были выкинуты из актуального стандарта ХТМЛ5 с 2014 года, а устаревшими были признаны ещё во времена ХТМЛ4 в начале 2000-х. Но мы который год сидим с этим дерьмом, несмотря даже на существование задачи на трекере. И хулѣ теперь?
>>28264 А как и чем сохранять AVIF-файлы? Желательно, с окошком предпросмотра. Желательно в стабильных распространённых линуксах.
>>28267 Чтобы сохранить файл AVIF в web-браузере, надобно жмякнуть AVIF правою кнопкою мыши и в выпавшем контекстном меню выбрать пункт «Сохранить», при этом появляется окошко предпросмотра выбраннаго подкаталога файловой системы. Если же подразумевалося пересохранение в AVIF из другого формата файлов, то я не могу ничего рекомендовать, так как сам я пользуюсь для этой цѣли средствами командной строки (либо FFmpeg для сохранений ключевых кадров видео AV1 без потерь в AVIF или для анимированных AVIF, либо avifenc для остальных AVIF).
Поскольку прошлогодняя блокировка окончательно перевела этот проект в состояние «мёртв, но не закрыт», а дальнейшие перспективы сулят лишь отбрасывание частицы «не», для архивных целей напишу, какое у меня было видение развития этого движка. В целом, общий подход всегда озвучивался: у нас всех есть сложившиеся привычки и обычаи, и любые обновления надо по возможности выстраивать вокруг них. Поэтому я стремился в первую очередь заиметь в движке то, что уже основано на существующем опыте. В качестве начального этапа предлагалось избавиться от явно устаревших вещей и недоработок и обзавестись относительно «необременительными» новыми функциями (которые обычно уже давно внедрены на других сайтах). Некоторые вещи были реализованы: быстрый ответ, лимиты сообщений в символах и прочие правки интерфейса. Но при этом повисла без движения такая принципиальная вещи, как отказ от фреймов на главной по умолчанию (https://codeberg.org/FBE410/fbe-410/issues/11 ), которая важна не только сама по себе, но как и отправная точка дальнейшей доработки главной в целом. Среди прочих, менее значительных, задач этого этапа можно упомянуть сворачивание формы постинга (https://codeberg.org/FBE410/fbe-410/issues/54 ), скрытие нитей через каталог (https://codeberg.org/FBE410/fbe-410/issues/48 ), показ темы/номера в заголовке страницы (https://codeberg.org/FBE410/fbe-410/issues/47), человеческую нумерацию страниц (https://codeberg.org/FBE410/fbe-410/issues/1 ) и, возможно, ещё какие-то мелочи типа явной индикации бамплимитов. Отдельно следует упомянуть хотя бы косметическую доработку мобильного интерфейса, который сейчас чисто для галочки. Всё это принципиально не меняет классический облик движка, но сделало бы его чуть более удобным и чуть менее кривым и допотопным по ощущению. При воплощении упомянутых задач можно было бы перейти к следующему этапу. Я бы обозначил это как «функциональность, которая требует пользовательских настроек». Сиречь, те вещи, которые хорошо известны по всяким скриптам и соседним сайтам, но нравятся как будто бы не всем. Вот эти вот все списки ответов, автопроигрывание звука в видосах, автообновление нитей, подсвечивания ответов на твоё сообщение, разворачивание ссылок на «Ютуб», поведение быстрого ответа (чтобы он и по нажатию на цифры работал, а не только по кнопке), кнопки форматирования и предпросмотр в форме постинга и т.п. Все эти штуки за одной кнопкой не спрячешь, поэтому надо делать настройки, что требует большой ревизии всех местных скриптов и того, как они взаимодействуют с движком. Тут же можно учесть взаимодействие со сторонними скриптами и мобильными клиентами (в идеале вообще хорошо иметь «придворный» клиент, в котором всё более менее работает как задумано и советовать его всем, кому оно надо, но это утопия даже на фоне всего остального). Далее можно подумать о расширении возможностей интерфейса. Типа всяких там тегов как системы категоризации нитей (чтобы не плодить доски) >>28160, опросы >>27993 и что-то ещё. Это всё, что касается именно пользовательских возможностей, конечно. Вроде бы ничего такого сложного, но, увы, за все эти годы так и не родился человек, который бы согласился вступить в команду сайта и систематически пилить местный движок. И если даже в более хлебные годы таких не было, то сейчас тем более.
>>28312 Ну, как минимум один человек с руками все еще с вами, хоть ему и постить теперь сложнее, и 54 с 11 он вам таки сделает Как максимум, вывод движка в опенсорс запустил проекты-отпрыски, и в каком-то виде наш проект воспроизвелся и будет воспроизводиться, значит заниматься движком смысл тоже будет!
>>28313 Но конечно же, если здесь есть сэры готовые взяться за перечисленные задачи вот прямо сейчас и сделать их гораздо быстрее, то я вам по джентльменски их уступлю :3
>>28312 Казалось бы, чего такого сложного за полгода отревьювить и применить к сайту фикс про удаление.. Я не буду систематически писать встол. >>28313 Насколько мне известно, есть только два сайта-отпрыска. На первом на текущий момент код, судя по всему, отличается только тем, что при последней попытке КТ обновиться получилось у него криво и в несколько покоцанном виде. Ветка второго же сильно, сильно far ahead 410'ой. Были осуществлены масштабные ремонтные мероприятия, подкапотом и не только. Кодобаза частично очищена от неиспользуемых функций. Код переведён на strict types. Так что тутошние изменения без правок на Якуев сайт не запушить уже. Вообще, я, наверное, бы посоветовал ещё раз подумать над >>28230-вопросом Аобы (автор быстрого ответа, among many other things) и синхронизироваться, за-pull'ив изменения оттуда сюда. Тому есть два препятствия. Во-первых, коммит про значёк-сажу, который Якуй отказался применять; но если сделать сажу настриваемой KU_OLD_STYLE_SAGE флагом в config.php, думаю, он согласится. Во-вторых, >>28081-заплатки про удаление там нет, either, но не проблема добавить.
>>28315 Что вам непонятно во фразе: >Вроде бы ничего такого сложного, но, увы, за все эти годы так и не родился человек, который бы согласился вступить в команду сайта и систематически пилить местный движок. И если даже в более хлебные годы таких не было, то сейчас тем более. ? Да, сейчас буквально некому применять к сайту что-то там, даже готовое. Даже уязвимости чинить. И форки ваши буквально мониторить некому. Вы либо присылаете конкретные реквесты, либо не присылаете. Поэтому я и пишу в прошедшем времени, просто для истории. Никому настолько не всрался этот «410чан» с его движком, что вон кому-то что угодно где угодно пилить интереснее, но лишь бы не здесь, лол.
>>28316 Так объявите набор в применяющие к сайту? Ей-ей, анекдот про еврея и лотерею.
>>28317 Набор объявлен примерно с 2008 года.
>>28318 Не удиветельно, что если вы в последний раз объявляли о наборе незнамо когда незнамо где, то никому не известно ни о наборе, ни о его валидности на сегодняшний день. Попробуйте объявлять систематически и в целом подумать над своим поведением. А то так и останется сидеть в луже, плакать и кидаться сажей в прожих. Но нытьё поднадоело уже.
>>28319 Шли бы вы нахѣръ. Объявляли ему незнамо где, нытьё ему надоело, лол. На-хѣ-ръ. На форки свои или ещё куда, лишь бы здесь больше не появлялись.
>>28320 Что я тут могу сказать. Поделом вам доля.
>>28316 > Да, сейчас буквально некому применять к сайту что-то там, даже готовое. Даже уязвимости чинить. И форки ваши буквально мониторить некому. Вы либо присылаете конкретные реквесты, либо не присылаете. Я правильно понимаю, что даже если конкретные реквесты присылать, то примѣнять некому? (Или общность «что-то там, даже готовое» не включает в себя реквесты, потому что они не «что-то там», они «что-то тут»? Или это сейчас оно некому, но время от времени вдругорядь есть кому?)
>>28322 >даже если конкретные реквесты присылать, то примѣнять некому? В целом, да. Я могу только что-то срочное и при этом простое, чтобы я мог разобраться, как оно работает. Сроков улучшения ситуации у меня нет.
>>28321 У меня уже давно стадия принятия этой доли, потому что лучше уже не станет никогда, а хуже — в любой момент. Но когда я говорю простые и очевидные вещи о проблемах проекта, а мне в ответ заявляют про «нытьё», нервы уже не выдерживают.
