Ранее упомянутый пользователями баг с локалью, наконец, настиг и этот сайт.
Кто исправит, тот молодец.

>>26067
Проверьте, стоит ли php-gettext.
Если стоит, отредактируйте lib/gettext/gettext.php: >>25130.

А, и если в /b/ с локалью всё нормально, а тут нет, то верные ли значения локалей досок указаны в БД?

По ѿклику >>/d/2753 нетрудно догадываться (и догадываюсь), что 410чан ѿъѣхалъ на другой сёрверъ.

Это была одна только эвакуация из-под санкций или смѣна тарифа для роста хранилища под архив сообщений? — или при этом заодно появилися и новые возможности для разработки: новая версия PHP, новая версия ImageMagick, etc.?

>>26071
Переезд на другой сервер никак не влияет на версии пакетов в операционной системе.

> The uploaded file exceeds the upload_max_filesize directive (2M) in php.ini.
Исправьте, пожалуйста.

>>26075
Вроде бы да.

Проблемы >>26075 больше нѣтъ, спасибо.

Въ подраздѣлѣ уведомлений >>/d/1816 послѣднее сообщение >>/d/2377 доводит до свѣдѣнія пользователей то обстоятельство, что анимированные WebP к моменту появления этого сообщения (в ноябре 2020 года) ещё не поддерживалися.

Но так как в настоящее время анимированные WebP поддерживаются на 410чанѣ невозбранно (и примѣръ прилагаю), то рекомендую помѣстить там ещё одно уведомление на этот счёт, чтобы новоприходящих не вводить в заблуждение.

Если очень хочется донести до всѣхъ мысль «но лучше не используйте анимированные форматы картиночных файлов (анимированные GIF, анимированные PNG, анимированные WebP), а используйте видеоформаты в контейнерах (AVC в MP4, Theora в OGV, VP8 в WebM, VP9 в WebM, AV1 в MP4, AV1 в WebM), потому что специализированные видеоформаты обеспечивают гораздо лучшѣе качество видео при том же объёме файла», то лучше всего именно так и сказать в том же уведомлении, то есть лучше всего дѣйствовать убеждением, а не умолчанием.

Вижу, что по тикетам

18
24
34
41

Есть вмерженные пулреквесты, но сами тикеты пока не закрыты.
Там еще надо доделывать?

>>26101
24 закрыл.
По 18 было в предыдущем треде:
>В пулл-реквесте с предупреждениями автор добавил экранирование ХТМЛ для модлога, но не учёл, что таким образом ломаются ссылки для просмотра удалённых сообщений. Мы пока вернули эту строку, дабы ссылки работали, но настоятельно рекомендуем найти способ починки этой лабуды, ибо оно не позволяет использовать ХТМЛ в предупреждениях.
Надо проверить эту лабуду.
Там ещё какой-то ненужный апостроф в вёрстке после кнопки «Удалить все посмотренные».

>>26105
Понятно, 34 и 41 пока тоже проверяются?

>>26107
34 закрыл. По 41 непонятно с задачей максимум+, можно и закрыть.

Завёл ещё пару новых задач.

По-видимому, автор патча, по адресу https://bitbucket.org/Therapont/fbe-410/issues/37 предлагавшагося, в конце концов так и не смог разобраться с работоспособностью своего git.

Но и не хѣръ бы с ним? — разве что-либо мѣшаетъ уважаемой администрации самостоятельно накатить этот патч его?

На мобилке в мобильной «лисе» поменялись шрифты на всех досках. Был serif, стал sans serif.
Так и задумано?

Ещё, шрифт для темы нити стал сильно больше по размеру и почти сопоставим по нему со шрифтом названия доски.

>>26185
Да.

>>26187
Это наоборот у названия доски появилась жирность.

Собираюсь запилить борду на этом движке.
Какие подкаменные воды?

>>26188
> Это наоборот у названия доски появилась жирность.
Я просто смотрю соседний сайт, который не обновлялся, и там шрифты для тем нитей по-прежнему маленькие и аккуратные.

>>26189
Нужна либо эрудиция по LAMP, либо опыт накатывания кусабаподобных движков.
Нужны php-mysql, php-gd, php-gettext, imagemagick и ffmpeg.
Важны опыт админивания Кусабы и умение разбираться в чужом коде; все мануалы мертвы, ссылку после “File” и зачем она нужна будете искать самостоятельно.
Может понадобиться не самый-самый новый PHP: какие-то проблемы с тем, что deprecated лабуду, которой в движке по крайней мере было полно, из того нового PHP таки выпилили.
Ещё была какая-то >>22323 проблема с путями. Исправили или нет, не знаю.
Ещё, >>22332.

>>26189
Движок разрабатывается исключительно в интересах этого сайта, поэтому вам никто не будет тут помогать с техподдержкой и реализовывать ваши хотелки по функциям. Использовать никто не запрещает, но я бы советовал любой другой популярный движок типа «TinyIB» (у небезызвестного Степана со скриптами есть свой форк https://github.com/SthephanShinkufag/TinyIB , например).

Только что нашёл баг в Авто/б/усе: если сделать в треде один пост с сажей, а потом ещё новый пост с сажей, и тот новый пост с сажей удалить, то тред будет бампнут так, как если бы тот первый пост с сажей не был с ней.
Вангую, какие-то неполадки в защите от stealth bump-ов.

Не пройдёт и двух лѣтъ, как условие >>25134 окажется исполненным: по адресу https://bugs.webkit.org/show_bug.cgi?id=241904 явствует (скриншот прилагаю) намѣреніе Apple поддержать AVIF во браузере Safari на операционных системах macOS Ventura (она же macOS 13) и iOS 16 — а каждая из этих систем, как можно надѣяться, выйдет на свѣтъ ещё до конца нынѣшняго (2022) года.

Несмотря на это обстоятельство, упомянутая в сообщении >>25735 идиотская ситуация, а именно отсутствие современной (седьмой) версии ImageMagick на том Дебиане, на котором крутится 410чан, практически приводит нас к тому, что работа над поддержкою формата AVIF в движке FBE не может завершиться до появления поддержки формата AVIF в функции getimagesize() языка PHP.

Формально в исходном коде движка PHP такое появление ужé состоялося, но по адресу https://github.com/php/php-src/pull/7711#issuecomment-1013874082 в январе было сказано, что ближайшею новою версиею, эти измѣненія содержащею, станет версия PHP 8.2.0.

Сейчас ожидается, что она выйдет под конец ноября; быть может, её ещё далѣе отложат; и уж во всяком случае нечего и ждать того, чтобы тот Debian, на котором 410чан крутится, тотчас же обзавёлся новою версиею языка PHP.

Поэтому въ нынѣшнемъ году никакой поддержки AVIF на 410чанѣ не ждите: её никоим образом не будет!

(с момента создания нити)
https://bitbucket.org/Therapont/fbe-410/issues/43/ единообразие показа дат во всём интерфейсе
https://bitbucket.org/Therapont/fbe-410/issues/44/ починка кнопки удаления сообщений для уборщиков
https://bitbucket.org/Therapont/fbe-410/issues/45/ ВЕБП не выводятся как картинки в жалобах
https://bitbucket.org/Therapont/fbe-410/issues/46/ вышеупомянутая проблема с двойной сажей
https://bitbucket.org/Therapont/fbe-410/issues/47/ показ полного содержания ОП-постов в каталоге через скрипты

Старые задачи тоже висят.

>>26287
>47
>показ полного содержания ОП-постов в каталоге через скрипты
На первый взгляд, неплохо справляется уже существующая функция предпросмотра >>ссылок в нитях, достаточно дать соответствующий класс элементу <a> внутри элемента .cataloglist чтобы было типа:
><div class="cataloglist">
>...
><a href="/dev/res/26066.html" class="ref|dev|26066|26066">
И можно невозбранно смотреть ОП-посты прямо из каталога.
Это требует минимальной модификации существующего кода (собственно, вывести этот класс при генерации элементов каталога), вопрос только - подходит ли нам такое поведение и внешний вид, или нет?

>>26542
Это и подразумевается.

>>26543
Ок, наверное самая легкая задача из списка тогда.

В хромоподелиях сломался быстрый ответ. Может кто по-быстрому посмотреть, что там за лабуда или мне задачу на трекере заводить?

>>26646
УМВР с мака.

>>26646
Раз сначала работало, а потом сломалось и никто туда не лазил, надо выяснить, какие компоненты механизма быстрого ответа имеют ограниченный ресурс. Может переменные износились, или отверстия для аргументов в функциях засорились.
З.Ы.: Edge Win7 x64 - работает.

>>26653
У вас точно последняя версия этого браузера? Потому что в нём точно не работает ничерта с последним обновлением, хотя на прошлой неделе работало.
Очевидно, что хромичи у себя что-то сломали.

>>26654
Действительно.

>>26656
Откуда прозрачности взялись?

>>26646
>>26661
Посмотрел.
>Couldnt find target thread to attach quick reply, aborting quick reply.

Ошибка предусмотрительно вылетает тут:
>if (threadId && !targetThread.length) {
> throw Error('Couldnt find target thread to attach quick reply, aborting quick reply.');
>}

За переменную targetThread отвечает вот этот селектор:
>var targetThread = $('.'+threadClass+':has(a[name='+threadId+'])');
Он собираться во что-то типа
> $('.thrdcntnr:has(a[name=26066])')
И казалось бы, что тут может быть криминального?
В Фаерфоксе работает, в Опере работает, в Хроме постарше работает.
А в новом Хроме и Эдже он не срабатывает и возвращает пустой массив!

Но! Если значению аттрибута дать кавычек вот так:
> $('.thrdcntnr:has(a[name="26066"])')
То селектор снова начнет работать.
И быстрая проверка показывает что работает и в браузерах постарше, и в браузерах поновее.

Выглядит это так будто в новом билде вебкита просто что-то сломали, если честно.
Или же :has() от нашей версии jQuery в нем работает уже не так хорошо, как раньше.

Чтобы подкостылить, надо добавить кавычек в те селекторы в kusaba.js, у которых есть конструкция типа
> :has(tag[attribute=value])
Чтобы стало
> :has(tag[attribute="value"])

Конкретно такие конструкции используются в этих строчках быстрого ответа:
>1451 var targetFormFieldRows = $('tr:has(input[name][type!=hidden])', targetForm);
>1517 var threads = targetThreadId ? $('.'+threadClass+':has(a[name='+targetThreadId+'])') : $('.'+threadClass);
>1566 var targetThread = $('.'+threadClass+':has(a[name='+threadId+'])');
>1568 var targetPost = targetThread.find('.'+replyClass+':has(a[name='+postId+'],a[data-name='+postId+'])');

Но могли отвалиться еще вот эти, напрямую не связанные с быстрым ответом вещи:
>102 var $postform = formid ? $('#'+formid) : $('.postform:has(textarea[name=message]):first');
>197 var numReplyPostForm = $('form:has(>[name=replythread]):visible:last');

Справитесь?

>>26653
Селекторы износились, или jQuery, получается.

Интересно еще, поможет ли вместо >>26664 просто обновить jQuery?

>>26661
Новая машина, новая винда — ничего не настроено. Думаешь, перезжать так просто?

>>26664
Мораль сей сказки в том, что нефиг юзать экспериментальные фичи CSS когда Господь дал тебе портабельное Жуквери.
>Выглядит это так будто в новом билде вебкита просто что-то сломали, если честно.
Или же привели в соответствие со стандартом, что больше похоже на правду. По крайней мере в XHTML по другому и не напишешь. И я не стану удивляться, если какого-то существенного значения в мировом масштабе это иметь не будет.
>Или же :has() от нашей версии jQuery в нем работает уже не так хорошо, как раньше.
Жукверя не занимается CSS-селекторами.
>Селекторы износились, или jQuery, получается.
Экспериментальные фичи. Добро пожаловаться в удивительный мир уеб-макакинга. К сожалению, автор сего квикреплюя был слишком юн, самоуверен и верил в людей.

То ли дело вы, в познании настолько преисполнились что уже и отреклись от бренности любых реализаций, только несете луч чистого знания методом постинга кошкодевочек. Кисленько как-то.

>>26669
Меня с моими престопроблемами уже послали в сторону, обратную серверу, вылив ушат желчи за то, что я не знаю фич последнего стандарта JS и вообще не моден, не ношу бороду и кеды. Так что я тут только с позиции консультанта мебельного магазина предлагаю следующие товары:
— стул «переписать так, чтобы работало на Престо»: тяжёлый и громоздкий, но работает с любой задницей;
— стул «засунуть параметры в кавычки»: легкий и компактный, но может внезапно развалиться, плюс требует проведения исследовательской работы по выяснению совместимости с задницами разных видов.

Произошедшее порождается, насколько я понимаю, тѣмъ обстоятельством, что прежде работа CSS-селектора «:has()» костылировалася в jQuery, однако же с недавних пор (во Chrome и в Edge — съ нынѣшней сто пятой версии, в Safari — с версии 15.4) этот селектор обрёл непосредственную поддержку во браузерах, как о том табличка https://caniuse.com/css-has сообщает нам.

И, по-видимому, синтаксис этой поддержки оказался чуть другим, чѣмъ синтаксис костыля. 🩼

В чём заключается отличие? — в большей строгости по отношению к ошибкам синтаксиса, я это так понимаю.

CSS-селектор атрибутов в форме «[названиеАтрибута=значение]» может в качестве значения содержать либо идентификатор (без кавычек), либо строку (в кавычках), как нам о том документ https://www.w3.org/TR/selectors-4/#attribute-representation говорит в абзаце, предшествующем двадцать первому из тамошних примѣровъ.

Но циферки «26066» въ примѣрѣ «:has(a[name=26066])» в сообщении >>26664 не могут (в строгом смысле) служить идентификатором, потому что по стандарту https://www.w3.org/TR/css-syntax-3/#ident-token-diagram идентификатор не может начинаться с цифры.

Вот ѿвѣтъ на вопрос «И казалось бы, что тут может быть криминального?»

Логический вывод таков: о работоспособности селекторов «[name=message]» или «[name=replythread]» можно и впредь не беспокоиться (даже и дух перевести можно, если кто вдруг затаил дух), тогда как селектор «[name=циферки]» по необходимости придётся замѣнить селектором «[name="циферки"]» повсюду.

>>26667

> Жукверя не занимается CSS-селекторами.

И именно поэтому использует и содержит https://github.com/jquery/sizzle/ в своём составе, ага-ага, понятно-понятно.

Столько нафлудили и ни одного пулл-реквеста.

>>26670
>послали в сторону, обратную серверу,
Не знал, сожалею что так вышло.

>>26674
Я думал Соус хочет сам патч ASAP вкрутить, и ему нужен рецепт. Делать пулреквест?

>>26676
Делайте, конечно.
Вопрос был в том, надо ли задачу (надолго) заводить, или кто-то сейчас есть.
А теперь один хѣръ придётся ждать до следующих выходных.

>>26677
Жаль что не получилось самостоятельно вкрутить по инструкциям, конечно.

Вообще, прекрасная иллюстрация того, почему мы так консервативны со скриптовыми свистоперделками.

>>26679
Только оказалось все же, что виноваты Хромичи, и консервативней им надо быть с билдами. Они там что-то действительно напороли в интерпретации :has()

Вот такой селектор в обновленных браузерах не работает:
> $('tr:has(input[name][type!="hidden"])')
И его приходится костылять:
> $('tr:has(input[name]):not([type="hidden"])')
Просто потому что != больше не отрабатывает внутри :has()

На проблемы конкретно с :has() также указывает, что номерные значения атрибутов вне :has() у Хромичей работают как ни в чем не бывало:
> $('a[name=26066]')

Вобщем я хоть и внес все костыли в пулреквест, но теперь кажется что Хромичи могут просто исправиться в следующем билде, и костыли будут не нужны.

Смочь бы ещё найти что-то на их https://crbug.com/

https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>CSS&can=2

Вот что-то похожее на обсуждают
https://github.com/w3c/csswg-drafts/issues/7676
https://crbug.com/1340873
https://crbug.com/1359396

>>26681
Вроде и хочется сказать, что да, это их конфликт с jQuery, но с другой стороны - такое странное и непоследовательное поведение испытваем, что не знаю даже.

Пока выглядит, что полной картины бедствия еще нет.
Пройдя по ссылке с гитхаба, увидел что ребята из jQuery тоже обнаружили что вещи перестали работать внутри :has()
https://github.com/jquery/jquery/issues/5098
но не нашли все.

Если верить гитхабу, jQuery сначала пытается достать элемент штатными средствами браузера, и если браузер выдает на это ошибку - jQuery достает своими средствами. Хромичи из :has() ошибок не выдают, они возвращают пустой массив, jQuery считает что селектор сработал штатно и все хорошо.

Как бы то ни было, пулреквест у нас уже есть.

>>26682

Это не конфликт Хрома и jQuery.

Создатели Chrome дѣйствовали в полном соѿвѣтствіи со спецификациею CSS, авторы которой рѣшили (и прописали в ней), что селектор «:has(:невѣрныйСелектор, :невѣрныйСелектор)» не должен выдавать ошибку, а для чего? — для того, чтобы в CSS-правилах наподобие «main.class, div.class:has(:невѣрныйСелектор, :невѣрныйСелектор) {…тут стили…}» (примѣръ, по адресу https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1238995108 приводящийся) всё-таки работал тот селектор, который до запятой.

Создатели jQuery, не располагая машиною времени, уж конечно не могли предвидѣть, что невѣрные селекторы когда-нибудь перестанут выдавать ошибку и начнут выдавать тупо пустой массив. Поэтому во всѣхъ версиях jQuery, начиная от первѣйшихъ, непоявление ошибки при работе селекторов наподобие 410чановского «:has(a[name=26066])» (и даже селекторов наподобие «:has(:contains)» с собственными jQuerийными заморочками) означало, что костылировать не нужно и что браузер сам справится.

Авторы спецификации CSS в результате обнаружили себя перед выбором из трёх зол, по адресу https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235773031 упоминаемых десять дней тому назад:

① Можно подарить имя «:has» возможностям jQuery, а в стандарте CSS использовать какой-нибудь другое имя селектора. (Это ужасно, потому что под именем «:has» этот селектор ужé поддерживается многими браузерами — даже в Safari, новую версию которого придётся ждать примѣрно полгода-год даже в сáмом лучшем случае. Сайтостроители сайтостроят на основе существующего имени, а затѣмъ на их головы в 2023 году придёт переименование и сломает работу селектора?!)

② Отказаться от дорогой их сердцу идеи о том, что нѣкоторые селекторы могут отваливаться тихо-мирно, не создавая ошибок.

③ Положить хѣръ на jQuery, пусть ломается.

По адресу https://github.com/w3c/csswg-drafts/issues/7280 склонились к той мысли, что хотя бы внутри @supports на идею простительности ошибок надо подзабить.

Тем временем по адресу https://crbug.com/1340873 видим, что во Chrome добавили такой патч (по адресу https://chromium.googlesource.com/chromium/src/ /e2a70f09eb5a1b2c626d720b18a855917f0f479c расположенный), который «ломает :has» — позволяет этому селектору всё же выдать ошибку, когда он вызывается без аргументов внутри скобок.

По-видимому, каким-то образом эта ошибка позволяет jQuery на ранней стадии воспринять (обманувшись) этот селектор как неподдерживаемый и включить собственную (jQuerийную) поддержку его.

Лично моё мнѣніе склоняется к тому, что сама идея селекторов, которые ошибку не выдают, но и не работают, была малопродуманною. (То есть из тѣхъ трёх зол я выбрал бы второе.) Что не ѿмѣняетъ собою необходимость заключать атрибуты-цифры в кавычки в коде 410чана.

>>26680

> $('a[name=26066]')

По аналогии со всѣми вышеизложенными обстоятельствами я могу и в сём случае небезосновательно подозрѣвать (и подозрѣваю, хотя и не провѣрялъ), что как раз во Хроме этот селектор вызывает ошибку незакавыченности, которую ловит jQuery и затѣмъ костылирует работоспособность этого селектора собственным движком Sizzle, в сообщении >>26673 упоминавшимся.

>>26680

> != больше не отрабатывает внутри :has()

А вот это да, явный баг.

Им о нём кто-нибудь сообщил?

>>26686
Пока не видел, так что вы можете быть первым!

Завёл там несколько новых задач в связи с.

>>26688
Можно наделать несколько сменяемых наборов фапчи и ограничение на число прокликиваний - тогда злоумышленнику придется долго и мучительно возиться с расшифровкой (и даже просто выкачиванием) каждого набора.

Либо иметь только один большой набор изображений, но установить динамическое "окно", выдающее всем пользователям в каждый момент времени только некоторое подмножество этого набора, и постепенно сменяющееся от количества новых постов/тредов, либо при аномальном их числе за короткое время. Это не даст злоумышленнику возможности навайпать слишком много, и его вайпалка автоматически станет бесполезной и нуждающейся в настройке. Хотя, конечно, ударит по пользователям, привыкшим прокликивать до Юички.

А вообще, судя по нападению на новерь, его прокси можно быстро перебанить и руками

>>26690
> ударит по пользователям
Можно сделать по несколько разных изображений на одного персонажа, тогда при их смене здоровые люди не будут страдать, но будет страдать бот.

>>26690
>>26691
Удваиваю, идея с организацией картинок в фапче в формате набора нескольких подменных, не отдаваемых всегда в общем наборе картинок по персонажу звучит очень неплохо. Менять можно индивидуально, если какая-то картинка слишком затребована, а можно и полностью, по критериям постинга, или создания новых фапча-сессий.

Фапча — это способ защиты от тѣхъ ботов, которые желали бы массово наспамить по нѣсколькимъ имиджбордам (массово не получится, потому что фапча 410чана индивидуальна) и способ защиты от людей, внѣшнихъ по отношению к анимешному сообществу («пробовал, но не угадал ни одной фапчи»).

В случае с вайпером, способным угадывать капчу и затѣмъ передавать свой «проѣздной билет в Автобусе» своей же вайпалке (или, если проѣздные выключены, — поручать ей перебор фапч), фапча — это негодный инструмент антивайпа, ужесточение которого ударяет по благожелательным пользователям (особенно лично не смотрѣвшимъ конкретное полюбившееся Ѳерапонту Соусову сёдзё) не слабѣе, чѣмъ по вайперу, поскольку они-то перебирают фапчу руками, а вайпалка — автоматически. Получится отыгрыш притчи «хакер в столовой».

Болѣе разумным инструментом антивайпа может служить, скажем, жёсткий запрет на создание болѣе пяти ѳрэдовъ в течение пяти часов, запрет на создание N сообщений в течение часа (величина N может и должна быть подобрана таким образом, чтобы в разы превосходить темпы реального постинга, но не затруднять администратору стирание итогов вайпания).

Мы не рассматриваем и не рассматривали фапчу как сколько-нибудь серьёзный способ защиты от чего-либо.
Задачи на трекере, связанные с вайпами, уже висят.

>>26694
Возможно, стоит рассматривать хотя бы гипотетически? Ну как, вдруг понадобиться, а у нас уже все есть.

>>26693
На вид у вашей идеи с идеей >>26690 есть общий необходимый компонент: детектор аномалий постинга и движок правил для них.
Получается задача по фильтру злоупотреблений наиболее перспективная?

>>26690
Так фапча вводится лишь один раз, а потом пости сколько влезет. Так что идея описанная тобой неработоспособна. С таким же успехом, можно ещё скрипт ответного автодудоса подключить.

>>26696
Нельзя "отбить" вайп программно, если соответствующее ПО не может его засечь.

>>26717
> фапча вводится лишь один раз, а потом пости сколько влезет
Тогда она и удаляется так же легко, по общему проездному. Ерунда полная с такой бороться - это как вайпать с одного айпишника.

>>26717
> соответствующее ПО не может его засечь
А существует некое ПО, достоверно засекающее ботов? На самом деле - нет.

Одной из моих рабочих задач было прикрутить к сервису рубильник, который при необходимости (если мы внезапно не держим нагрузку) банит потенциальных ботов. Для того, чтобы понять, бот перед нами или нет, отдельная команда "Антиробота" из очень крупной компании прикручивала к входящим к нам запросам специальный хедер Is-Suspicious: 1, должный этого бота помечать. При этом, чтобы "надежно" пометить всех ботов, эту метку вешали примерно на 20% пользователей, не считаясь с потерями и массовыми ложноположительными срабатываниями.

Знаешь, что показал эксперимент? То, что даже если перебанить 20% "подозрительных" пользователей, некоторые боты все равно пролазят как к себе домой.

Так что единственное, что может остановить решительно настроенного бота - это либо бан всех проксей бдящим живым человеком, либо закрытие доски (как мы уже видели), либо изменение фапчи на незнакомую боту - с учетом того, что он постепенно обучается на видимых ранее картинках, и менять их набор нужно постоянно.

Но это уже крайние, теоретические меры, конечно. Забежавший сюда вайпер того не стоит.

>>26717
>Так фапча вводится лишь один раз, а потом пости сколько влезет.
Нет, она позволяет постить в рамках разумного, но если что сессия сбрасывается. Поэтому идея >>26690 работоспособна и покрывает случаи когда фапча вводится ботом заново потенциально может быть каждый раз

Как починили quick reply? Чем закончилась та эпопея-то?

>>26721
Выше всё написано.

>>26066
Возможно, ли создать бордк на этом движке? Как? Извините я сисадмин, по этому не особо разбираюсь в бекенде и архитектуре борды.

>>26728
*борду

>>26728
Куда вам борду, если вы даже тред не в состоянии почитать: >>26192

>>26696
Да хоть бы просто быстрый откат сделали для начала.

https://bitbucket.org/Therapont/fbe-410/issues/46/ (проблема с двойной сажей) переоткрыт в связи с обнаружением бага.

>>26733
Спасибо, но я продпочел fukuro в качестве движка

Чтобы немного поднять всем настроение, сделал пулреквест с превью в каталоге.

>>26750
Забыл упомянуть, что нужен ребилд доски, чтобы заработало.

>>26734
Опишите на всякий случай, какие еще сценарии хотелось бы покрыть.

>>26755
Вот всё думал, да не придумал.
Разве что модерские кнопки добавить, чтобы прямо с доски можно было сносить.

>>26761
А в чем будет отличие этой кнопки от текущей кнопки B?

>>26764
Она только с одним сообщением работает.

Как в первом абзаце в сообщении >>26279 было сказано, так оно и вышло: по адресу https://webkit.org/blog/13399/webkit-features-in-safari-16-1/#animated-avif объявили 24 октября, что браузер Safari (начиная от версии 16.1) теперь поддерживает оба варианта графических файлов стандарта AVIF: и статические, и анимированные AVIF — во всѣхъ новѣйшихъ эппловских операционных системах (iOS 16, iPadOS 16, macOS Ventura).

Скриншот прилагаю.

Если вѣрить изложенным по адресу https://php.watch/versions/8.2 свѣдѣніямъ, то тогда всего-навсего пара недѣль остаётся до выхода того движка PHP версии 8.2, который я упоминал в сообщении >>26279 в контексте поддержки формата AVIF в функции getimagesize() ввиду того, что по адресу https://github.com/php/php-src/pull/7711#issuecomment-1013874082 эту поддержку в этой версии ждут с января.

Двѣ недѣли скоро пройдут, но опосля них как скоро эта версия PHP объявится в Debian и затѣмъ на 410чане? — извѣстны ли сроки?

https://bitbucket.org/Therapont/fbe-410/issues/52/ редактирование темы нити
https://bitbucket.org/Therapont/fbe-410/issues/53/ убрать показ фрейма по умолчанию

>>26801
Я помню, что FBE не работал с 8-ой пыхой из-за каких-то deprecate-нутых функций. Не знаю, починили это или нет.

>>26840
Странно что не оформлено как задача в трекере тогда

>>26841
А в системе сейчас 7.4, как обновится до 8, так и будем смотреть, работает оно или надо подкручивать.

Вышел движок PHP версии 8.2:

https://www.php.net/archive/2022.php#2022-12-08-1

(Как я ужé сообщал мѣсяцъ назад, это первая из версий PHP, полностью поддерживающая в своей графической библиотеке GD графический формат файлов AVIF.)

Если формат JFIF является тем же JPG, то следует прописать это в движке.

>>26867
В 84-ой строчке внутри inc/classes/upload.class.php заменить
> if ($this->file_type == 'jpeg') {
на
> if ($this->file_type == 'jpeg' || $this->file_type == 'jfif') {

Советую всё-таки заняться хоть какими-то инструментами против вайпов, раз пациент упорствует.

>>26870

Движок FBE помнит про различия JPEG и JPG и в паре других мѣстъ:

inc/func/posts.php на строке 244,

load_receiver.php на строке 91 и 123.

Тамова постинг WebP отвалился.
> Incorrect integer value: '' for column

410chan

.

posts_b

.

thumb_w

at row 1

>>26879

Администрация вроде бы пофиксила вот это вот всё.

Там на bitbucket кто-то было просил guide по поднятию движка.

1. Поднимаете LAMP, ставите ffmpeg (видео), imagemagick (картинки), а также php-gd (тоже картинки), php-gettext (локаль) и php-mysql — если они идут отдельными пакетами;
2. Создаёте базу данных, которую будете использовать для инстанции движка;
2.1. Инициализируете её, используя 410chan.sql;
2.2. В таблице пользователей для строчки с именем пользователя root меняете MD5 пароля на MD5 того пароля, который будете использовать;
3. Путём редактирования __config-sample.php создаёте в директории с инстанцией движка config.php. Если та директория не корень сервера, прочтите >>22323.
4. Enjoy.

З.Ы. С 8-ой пыхой у FBE действительно проблемы. Попробуйте 7-ую, если нет желания переписывать deprecate'нутую лабуду.

>>26881
Если у вас есть силы, было бы клево сделать Dockerfile и добавить его в репозиторий. Чтоб потом одна команда - и едет локальный автобус. Клёво же!

Дополнил 51 возможным вариантом того, как фильтр мог бы работать и настраиваться.

>>26880
Только что снова столкнулся, причем с обычным на вид jpg-файлом.

>>26886
Возможно, ваш жпег на самом деле не жпег.

>>26887
Пейнт считал что жпег, и даже сохранял в нем изменения >_>

>>26888
Paint, как и многие другие программы, при открытии файла смотрит на первые его байты и по ним определяет формат картинки. То есть, скорее всего, Paint открыл ваш PNG файл с расширением .jpg, посмотрел на первые его байты, и справедливо посчитал, что он PNG, и сохранил изменения в вашем файле с расширением .jpg как PNG. FBE (Кусаба) написан так, что соответствие расширения файла его фактическому формату необходимо. А Paint нет.
Бывают такие случаи. >>/d/2636

Постовайте файл на https://catbox.moe, посмотрим.

>>26889
Вы оказались совершенно правы, по сигнатуре файл PNG, а расширение - JPG. Стоило сразу посмотреть, спасибо за разъяснение.

Посмотрел исходник и сблевал от смеси логики с HTML в виде строк с тегами и ` = ".mysqli_real_escape_string

Мало того, что это вредит стилю и читаемости кода, так это ещё вредит безопасности и производительности.

>>26907
Современные IDE умеют такое конвертировать в темплейт + набор переменных, а логику потом можно вынести отдельно. Но это долгая, неблагодарная и кропотливая работа, результатов которой еще и не видно, и за которую потенциальному желающему еще и тяжело будет взяться, потому что он может устать еще на этапе поднятия локального инстанса FBE.

>>26907
Блевать все умеют, а переписывать код — никто.

>>26908
Мне кажется, что если желающий не может поставить движок, то он вообще не сильно разбирается в этих технологиях, чтобы что-то там переделывать.

>>26910
При установке движка есть несколько нюансов, которые нужно соблюсти, и несколько ошибок, которые нужно устранить. Также у нас не указаны необходимые движку PHP-модули, также отсутствуют некоторые миграции. Оно все мелочи, но накопительный эффект от этого есть - получается такое "испытание на входе в древний храм". Нужно иметь некоторый профессиональный опыт, чтобы все правильно интерпретировать, починить, и автобус завелся.

Добавил забытый баг из предыдущей нити: https://bitbucket.org/Therapont/fbe-410/issues/54/suspend

Лично моего опыта для рѣшенія проблем >>26911 не хватает, поэтому я просто воздерживаюсь и от установки FBE, и от сочинения такого кода FBE, провѣрка которого требовала бы именно установки FBE, а не подобных >>/dev/20224 средств и не «тут и так понятно, провѣрять нечего».

Реквестирую https://bitbucket.org/Therapont/fbe-410/pull-requests/77 для учёта возможности неsRGBшной цвѣтности (контуры которой сообщениями >>/b/196588 и >>/b/199138 и их обсуждением намѣчены) примѣнительно к миниатюрам (thumbnails).

Попутно улучшил развёртыватель миниатюр.

>>27043
А наличие в репозитории докер-файла для поднятия FBE помогло бы?

>>27066

Мнѣ — нѣтъ, не помогло бы.

Они ж не ставятся на Windows 7.

А ни у кого не сохранились скрипты на пикрелейтед?
В старом треде за 2017 год только пастбины протухшие.

Я рад видѣть запрос >>27058 удовлетворённым недѣлю назад (и исходный код вмёрдженным) — однако, наперёд терпеливо подождав недѣлю, теперь с любопытством поинтересýюсь: а когда эти правки кода собираетеся накатить непосредственно на 410чан? Есть какие-нибудь планы?

Вижу, что исходный код пошёл въ дѣло.

Спасибо.

Разработка движка в целом померла, но я завёл новую задачу: https://bitbucket.org/Therapont/fbe-410/issues/55/

Сообщение >>26279 отправлено в прошлом году, сейчас вдругорядь июнь, а воз и нынѣ тамъ.

Во-первых, всё ещё нѣтъ новой AVIF-понимающей версіи ImageMagick на сёрверѣ 410чана.

Во-вторых, всё ещё нѣтъ упомянутой в сообщении >>26866 новой версіи GD в новой версіи PHP на сёрверѣ 410чана. Но кабы и была, то проблемы из постскриптума к сообщению >>26881 повылазили бы на свѣтъ Божій.

Что же в-третьих тогда? Можно оперѣться на возможности FFmpeg. Однако я вижу, что у FFmpeg примѣрно такие же проблемы с утратою прозрачности AVIF при создании миниатюр файлов, какие в сообщении https://410chan.org/dev/res/20450.html#20573 наблюдалися (1 сентября 2018 года, без мáлого подесятка лѣтъ назадъ!) с утратою прозрачности GIF.

Можно ли разсудить дѣло такъ, что «на безрыбье»-то «и так сойдёт», или никоим образом нельзя пренебречь утратою прозрачности миниатюр AVIF на 410чане? — вопрос не риторический, я это всерьёз спрашиваю.

>>27133
Я предполагаю, что в последующие недели или месяцы на сервере будет обновлён «Дебиан», тогда и будем смотреть, что там поддерживается. Сроков обновления пока нет. Спрашивать их не надо.

Чувствую, что для пользы дальнѣйшаго тестирования не помѣшалъ бы примѣръ такого AVIF, который был бы:

① анимированным,

② с частичною прозрачностью.

По адресу https://take-me-to.space/iKlueGf.avif примѣръ такого AVIF прилагаю.

Ѿдѣльно сообщаю, что в сообщении >>27133 машинально записал «оперѣться», но правильно записывать «опереться» без «Ѣ».

На обновление «Дебиана» не возлагаю значительных надежд, так как по адресу https://packages.debian.org/search?keywords=imagemagick вижу ImageMagick 6 (скриншот прилагаю).

В эту старую ветку (в отличие от ImageMagick 7) ужé никто и никогда не станет впиливать поддержку новых форматов, и это не одного только AVIF впрямую касается, но и JPEG XL также. Никогда, никогда!

Кажется, fbe на php8.2 который теперь в debian stable по умолчанию, работать не будет.

https://bitbucket.org/Therapont/fbe-410/issues/56/php-8
Завёл задачу по обновлению движка под ПХП 8.2. Движок оказался совсем неработоспособен, чтобы его своими силами быстро починить, так что помощь не просто приветствуется, но всячески необходима.

https://www.php.net/manual/en/migration80.incompatible.php

По адресу https://t.me/exploitex/8944 встрѣтилося упоминание того, что вскорѣ «Битбакету» настанет кирдык.

Если это правда, то тогда эвакуируйте репу.

Скриншот упоминания прилагаю.

>>27169
Лично мне такая лабуда не приходила пока.

На всякий случай проясню мою реакцию >>27154 словесно. Так как по адресу https://www.php.net/manual/en/migration80.incompatible.php упоминается изрядное количество несовмѣстимыхъ отличий восьмой версии PHP от седьмой, то я:

① вижу, что задача потребует установки FBE (поэтому я от её рѣшенія по причине >>27043 воздержусь) и послѣдующаго пристального вглядывания в появляющиеся ошибки, так как просто перелопатить кучу кода в поисках несовмѣстимостей за один присест и безупречно не представляется возможным (часть их притом не поддастся простому поиску или даже поиску с использованием регулярных выражений, тут будет нужен либо синтаксический анализатор, либо отладка, либо готовность читать всѣ файлы глазами), так что ошибки повылазят непремѣнно,

② заблаговременно выражаю сочувствие и одобрение 410чанькам, готовым взяться за это непростое дѣло.

Суманъ.

На данный момент все существующие внутренние наработки по переходу на новую версию ПХП доступны в репозитории. Оно по большей части работоспособно, но нужно тестирование; из известных проблем — сломаны предупреждения. В ближайшее время обновлений не будет, видимо.
Если кто-то соберётся новые пулреквесты по этой теме делать, учитывайте это.

>>27179
А когда новая версия PHP выйдет и опять что-то сломают, по новой переписывать всё? Вот уж действительно неблагодарная работа. Лучше уж один раз переписать на языке, где заботятся об обратной совместимости.

>>27202
>на языке, где заботятся об обратной совместимости
C, Common Lisp? Какие ещё варианты?

>>27206
Приходят на ум JavaScript/TypeScript, Java, Go.

С Python ситуация интересная, в пределах мажорной версии не ломают совместимость, при переходе с 2 на 3, конечно, поломали. Но при этом Гвидо заявляет, что Python 4 может не выйти никогда (https://builtin.com/software-engineering-perspectives/python-4). Поэтому включу в список Python 3.

>>27208
>Go
Да, пока что обещания по поводу обратной совместимости выполняются, иногда в ущерб всему остальному. Разработчики оставили за собой право всё кардинально переломать в версии 2, но её может и не быть, по крайней мере в ближайшие годы.
>JavaScript/TypeScript
Скорее да, чем нет - если не обрастать зависимостями на сторонние библиотеки/фреймворки.
>Python
Совсем, совсем нет. В каждой новой версии что-то меняется или вообще убирается в самом языке и стандартной библиотеке, ломая обратную совместимость. Раз в год точно нужно будет что-то переделывать по мелочи, если пытаться быть всегда на свежайшей версии.
>С Python ситуация интересная
Нет, ломаются вещи именно что в пределах 3-й версии. Ломались небольшие вещи от 3.9 к 3.10, от 3.10 к 3.11, известно, что будут поломки от 3.11 к 3.12 - и уже сейчас видно, что будут ещё более серьёзные поломки обратной совместимости к 3.13.
Грядут изменения для языка в технической плане, самое серьёзное из которых - уход от global interpreter lock. С одной стороны всё это очень хорошо, с другой стороны - про обратную совместимость кода, написанного сейчас и следующую пару лет, в перспективе на 5-7 лет можно забыть.
>Java
Не знаком, но что-то мне подсказывает, что если бы с обратной совместимостью там было всё хорошо, то много людей не сидело бы до сих пор на Java 8 (актуальны сейчас Java 17 LTS и Java 20).
Слышал, что с C#/.NET в этом плане ситуация получше, но не знаю, так ли это на самом деле, и насколько лучше.

>>27210
> Совсем, совсем нет. В каждой новой версии что-то меняется или вообще убирается в самом языке и стандартной библиотеке, ломая обратную совместимость
Примеры?

> Грядут изменения для языка в технической плане
Например, кроме «ухода от GIL»?

> уход от global interpreter lock
Там же явно написано, что будут соблюдать обратную совместимость:
https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474
> We want to be very careful with backward compatibility. We do not want another Python 3 situation, so any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds

Свалите флудить в другую нить.

>>27211
>Примеры?
Вот тебе потешный пример, когда багфикс-релизы (одновременно сразу для целого ряда 3.X версий: 3.10, 3.9, 3.8, 3.7) поломали людям библиотеки для научных вычислений.
https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889
Почитай заметки к релизам, погугли "Python 3.X breaking changes".
https://github.com/wazuh/wazuh/issues/13365
https://github.com/python/cpython/issues/100458
https://github.com/aalavender/OilPrice/issues/9
После этого ответь себе, насколько стабильным тебе кажется Python 3.

>Там же явно написано, что будут соблюдать обратную совместимость:
Обсуждение вокруг этого свелось к тому, что выкатывать не-GIL Python они будут стараться мягко и нежно, но обратной совместимости по многим вещам между текущими и ближайшими версиями и "полноценным" не-GIL Python через лет 5 не будет.

Поскольку произошло описанное в >>27169, репозиторий переехал на https://codeberg.org/FBE410/fbe-410

Что за «функция предупреждений», упомянутая в >>/b/205318? Имеется в виду весь механизм предупреждений или какая-то одна функция? Что конкретно там поломано?

>>27335
Страница предупреждений выдаёт пустую страницу. При этом предупреждаемое через кнопку с доски сообщение удаляется без оставления записи об этом в модлоге.
Основной код тут:
https://codeberg.org/FBE410/fbe-410/src/branch/public/inc/classes/warnings.class.php

>>27336
Открыл pull request.

При развёртывании столкнулся со следующими проблемами:

1. В config.php необходимо было дописать

define('CONGLOMERATE', array());

, иначе была ошибка с несуществующей переменной CONGLOMERATE. Вполне возможно, что вписывать это нужно было в какой-то другой файл.

2. Три PHP-файла содержат ссылку на изображение “410.png”, однако в репозитории есть только “410logo.png”.

Озабочен я проблемой >>/d/3043. Путём экспериментов я выяснил, что она вызвана наложением двух особенностей движка:

(1) Насильным разбиением переводом строки последовательностей, которые длиннее 150 юникодных codepoint’ов и не содержат пробелов или переводов строки.

(2) Тем, что парсер разметки зачем-то пытается декодировать URL encoding в ссылках.

В результате после (1) из этой ссылки получается

https://ru.wikipedia.org/wiki/%D0%AF%D0%B7%D1%8B%D0%BA%D0%BE%D0%B2%D1%8B%D0%B5_%D1%83%D0%BD%D0%B8%D0%B2%D0%B5%D1%80%D1%81%D0%B0%D0%BB%D0%B8%D0%B8_%D0%


(перевод строки)

93%D1%80%D0%B8%D0%BD%D0%B1%D0%B5%D1%80%D0%B3%D0%B0

Первую строку затем парсер пытается декодировать. Получается, конечно же, невалидный UTF-8, который невозможно вставить в БД.

Почему в движке есть (1), ещё можно понять: если какой-нибудь умник запостит очень длинное слово, то страница поломается (появится горизонтальная прокрутка).

Но зачем декодировать URL encoding? Вот что мне непонятно. Просто убрав вызовы функции urldecode в обоих местах в файле inc/classes/parse.class.php, я решил проблему с невозможностью запостить ссылку. Какие новые проблемы появятся от этого изменения, не могу придумать. Открывать pull request или в этих вызовах всё же есть какой-то тайный смысл?

>>27354
> Но зачем декодировать URL encoding
https://ru.wikipedia.org/wiki/Красота

По-хорошему же стоит сделать разбиватель строк, который разбивает строку после декодирования URL по юникодной длине с пропуском тэгов разметки и их атрибутов. У UTF8 вроде чёткий и легко имплементируемый механизм нахождения длины символа по его первому байту.

Совсѣмъ-то по-хорошему надо бы:

① пройтись по полному списку строковых функций PHP, предназначенных для работы с Unicode (этот список по адресу https://www.php.net/manual/en/ref.mbstring.php располагается), и систематически одну из них (наиболѣе подходящую) использовать вмѣсто каждой такой строковой функции, которая игнорирует возможную многобайтовость сѵмволовъ,

② в таких мѣстахъ, в которых длина строки ограничивается дѣйствительно количеством сѵмволовъ (напримѣръ, «нам надо бы эту строку разбавить пробѣлами, чтобы ширину страницы не растаращило до степени появления полосы прокрутки и затруднения чтения»), подумать ещё и об использовании функции mb_strimwidth (или ея аналога, болѣе подходящаго) для учёта отличия полноширинных сѵмволовъ от полуширинных,

③ бережно сохранить учёт байтов въ таких мѣстахъ, в которых длина строки реально ограничена количеством байтов (напримѣръ, «в таблице БД величина имени файла не может превосходить столько-то байтов»), но и там не проигнорировать возможную многобайтовость сѵмволовъ (скажем, использовать mb_strcut для обрѣзанія).

Провёл исследование: на других имиджбордах и форумах проблема длинных слов либо никак не решена, либо решена с помощью свойств CSS “word-break” и/или “overflow-wrap” (оно же “word-wrap”). Принудительное разбиение на слова на уровне движка (CutWord) выглядит каким-то костылём, доставшимся в наследство ещё от кусабы. Есть ли в нём хоть какой-то смысл сейчас, если можно написать в CSS

.postbody {

  word-break: normal;

  overflow-wrap: anywhere;

}

?

Ещё можно как-то с помощью CSS сделать, чтобы горизонтальная прокрутка была только у провинившегося поста, а не у всей страницы. Но я не смог нагуглить, как это сделать.

Ceterum censeo, вызовы urldecode в парсере разметки нужно просто-напросто убрать, т.е. заменить urldecode(x) на (x). В этом и заключается надлежащее решение.

>>27372
>чтобы горизонтальная прокрутка была только у провинившегося поста, а не у всей страницы
На контейнеры

overflow-x: hidden;

,

width/max-width: 100vw;

/

...: 100%; box-sizing: border-box;

. На сам пост

max-width: 100%; overflow-x: auto

.

>>27375
Спасибо, похоже на правду, но идеально воспроизвести у меня не получается (остаётся небольшая горизонтальная прокрутка у всей страницы, а “overflow-x: hidden” это костыль). И ещё я не понимаю, про какие контейнеры ты говоришь. Можешь показать пример страницы, где такое сделано?

Ну и ждём вердикта Соуса.

>>27372

> В этом и заключается надлежащее решение.

Что, дѣлать нечитаемыми URLы, в которых есть японские сѵмволы или кириллица? Ради чего? Чтобы что?

>>27379
Против urldecode в парсере разметки у меня есть три возражения:

(1) Эта функция попросту не предназначена для того, чтобы ей скармливали целый URL (а не некую подстроку URL). Она может исказить его (из URL с одним параметром запроса получится URL с двумя):

$ php -r 'printf("%s\n", urldecode("https://example.org/path?query=x%26y%3Dz"));'

https://example.org/path?query=x&y=z

(2) Вызов этой функции может привести к тому, что корректная с точки зрения стандарта ссылка не сможет быть запощена:

https://example.org/path?query=%FF

является корректной ссылкой, ибо нигде не сказано, что URL encoded-сегменты обязаны быть валидным UTF-8. Более того, и по сей день существуют серверы, которые принимают запросы в кодировках, отличных от UTF-8: например, поиск Google по адресу

https://www.google.com/search?q=%FF

у меня (ваш результат может отличаться) интерпретирует этот один байт 0xFF как букву «я» в кодировке cp1251 (скриншот прилагаю). А в результате декодирования получается невалидный UTF-8, который невозможно вставить в БД.

(3) Это браузер пользователя делает URLы читаемыми или же нечитаемыми: можно запостить

https://ru.wikipedia.org/wiki/Красота

, а можно и

https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B0%D1%81%D0%BE%D1%82%D0%B0

. Я всего лишь предлагаю отображать ссылки так, как их запостил пользователь. То, что ваш браузер вставляет «%D0%9A%D1%80%D0%B0%D1%81%D0%BE%D1%82%D0%B0» вместо «Красота» при копировании URL, так это особенность вашего браузера, которую, скорее всего, можно решить его настройкой.

На практике декодирование вызывает (вместе с принудительным разбиением на слова) проблему >>/d/3043, а также другую проблему. Если эти проблемы будут тем или иным образом решены, то вопрос о том, нужно ли декодировать, с моей точки зрения, не будет очень существенным. Просто оно для этого не предназначено.

Хорошие контраргументы.

(Правда, если ими руководиться, то тогда опосля надо будет передѣлать парсер, насколько я понимаю — чтоб русские буквы принималися в URLы, а не означали конец URLов.)

>>27381
> опосля надо будет передѣлать парсер
Это не так: и старое, и новое (предложенное yakui-lover в открытом PR) регулярное выражение считают кириллицу частью URL.

Ну что же, открыл pull request, который реализует надлежащее (по моему мнению) декодирование URL.

Насколько я понимаю, предположение >>27134 превратилось въ нынѣшнемъ мѣсяцѣ въ увѣренность: теперь 410чан дѣйствуетъ на новом PHP и притом ещё, кажется, на новой версии операционной системы.

Настаёт время вдругорядь возвратиться к содержимому сообщения >>27133 и разсмотрѣть его под таким углом: если сёрвер 410чана всё ещё не обзавёлся AVIF-понимающею версіею ImageMagick, то как там хотя бы с наличием поддержки AVIF в GD в PHP?

Собрали ли PHP с поддержкою AVIF?

Сразу скажу ещё, что вглядывание в содержимое трёхлѣтней давности коммита https://github.com/libgd/libgd/commit/f2aa2836ed910ca3510585a47a8a064b5140e148 в репе GD открывает в нём (а именно в коде файла src/gd_avif.c) ряд небезынтересных обстоятельств.

Во-первых, в коде GD жёстко прописана цвѣтовая субдискретизация для AVIF в том случае, когда желаемое качество изображения, измѣряемое баллами от 0 (минимальное качество) до 100 (максимальное качество), указано меньше 90. На мой личный взгляд это жестковато, я бы поставил 80 пороговым значением.

Во-вторых, качество 100 включает, по-видимому, режим сжатия без внесения потерь в изображение.

В-третьих, в коде libavif качество задаётся величиною так называемого квантователя: чѣмъ эта величина больше, тѣмъ качество хуже, а доходить она может до 63. Поэтому в коде GD предусмотрена формула для перевода значений качества (0…100) в значения квантователя (0…63).

Формула эта вот какова: из значения максимального качества (100 баллов) вычитается значение указанного качества, а результат умножается на частное отъ дѣленія максимальнаго квантователя (то есть 63) на максимальное качество (то есть 100), опосля чего округляется. В итоге должна получаться вот какая таблица соѿвѣтствія между баллами качества и величинами квантователей:

0 → 63
1 → 62
2 → 62
3 → 61
4 → 60
5 → 60
6 → 59
7 → 59
8 → 58
9 → 57
10 → 57
11 → 56
12 → 55
13 → 55
14 → 54
15 → 54
16 → 53
17 → 52
18 → 52
19 → 51
20 → 50
21 → 50
22 → 49
23 → 49
24 → 48
25 → 47
26 → 47
27 → 46
28 → 45
29 → 45
30 → 44
31 → 43
32 → 43
33 → 42
34 → 42
35 → 41
36 → 40
37 → 40
38 → 39
39 → 38
40 → 38
41 → 37
42 → 37
43 → 36
44 → 35
45 → 35
46 → 34
47 → 33
48 → 33
49 → 32
50 → 32
51 → 31
52 → 30
53 → 30
54 → 29
55 → 28
56 → 28
57 → 27
58 → 26
59 → 26
60 → 25
61 → 25
62 → 24
63 → 23
64 → 23
65 → 22
66 → 21
67 → 21
68 → 20
69 → 20
70 → 19
71 → 18
72 → 18
73 → 17
74 → 16
75 → 16
76 → 15
77 → 14
78 → 14
79 → 13
80 → 13
81 → 12
82 → 11
83 → 11
84 → 10
85 → 9
86 → 9
87 → 8
88 → 8
89 → 7
90 → 6
91 → 6
92 → 5
93 → 4
94 → 4
95 → 3
96 → 3
97 → 2
98 → 1
99 → 1
100 → 0

Впрочем, эта послѣдняя строка ея остаётся фактически недосягаемою ввиду вышеупомянутаго переключения в режим lossless.

Каждое из этих трёх обстоятельств остаётся и по сей день.

Если в сообщении >>27391 правильно угадано положение дѣлъ (то есть если поддержка AVIF есть в GD в PHP, однако ея нѣтъ въ ImageMagick), то тогда оснащать FBE поддержкою AVIF придётся как-нибудь вот как:

① приподнять в файле inc/func/posts.php условие «elseif (KU_THUMBMETHOD == 'gd')» (и послѣдующія инструкціи GD-обработки изображений) до того уровня, на котором сейчас находится условие «elseif (KU_THUMBMETHOD == 'imagemagick')» (и послѣдующія инструкціи IM-обработки изображений), да притом ещё дополнить это условие «elseif (KU_THUMBMETHOD == 'gd')» до состояния «elseif (KU_THUMBMETHOD == 'gd' || $filetype == 'avif')» для того, чтобы оно всегда срабатывало насчёт файлов AVIF;

② в функции «gd_create_thumbnail» прибавить к вызовам «gif_gd_create» и «jpg_gd_create» и «png_gd_create» вызов функции «avif_gd_create» для файлов AVIF;

③ только что упомянутую функцию «avif_gd_create» сочинить по образцу функции «png_gd_create» как-нибудь вот как:

function avif_gd_create($source, $destination, $resize_x, $resize_y) {
   $avif = imagecreatefromavif($source);
   $thumbnail = gd_resize(
      $avif, $resize_x, $resize_y, $source, $destination, true, true
   );
   imageavif($thumbnail, $destination, 90, 3);
   imagedestroy($thumbnail);
   imagedestroy($avif);
   return true;
}

При этом в вызове функции «imageavif» я в явном виде прописываю третью скорость, поскольку при создании очень небольших изображений (миниатюр) не слишком важно экономить время (то есть не слишком важно наращивать скорость работы) за счёт качества.

При этом в вызове функции «imageavif» я в явном виде прописываю качество 90, поскольку это позволит подавить субдискретизацию цвѣта.

Сразу скажу, что если миниатюры такого качества всё же окажутся неприемлемо крупными по объёму, то можно будет обсудить дальнѣйшее снижение качества. Но напомню, что 6 ноября 2020 года (при добавлении в FBE поддержки WebP) обнаружил, что миниатюры WebP с указуемым качеством 85 получаются по объёму меньше, чѣмъ миниатюры JPEG с указуемым качеством 80, а визуально — лучше. Поэтому тут жду примѣрно того же, только ещё +5 баллов.

Предупреждаю, что движок FBE при работе с ImageMagick (то есть въ послѣдніе годы) создаёт миниатюры JPEG с указуемым качеством 80 (и это сносно), но при работе с GD создаёт миниатюры JPEG с качеством по умолчанию, которое (как это по адресу https://www.php.net/manual/en/function.imagejpeg.php говорится) равно 75 — этакие миниатюры и сами собою не так хороши, и как отправная точка для сравнения с миниатюрами AVIF (совершаемого по объёму файла) не очень полезны, потому что могут побуждать похѣрить ещё и их качество ради экономии объёма файла.

И так как в сообщении >>26066 сказано, что только администрация 410чана принимает рѣшенія, то предлагаю на ея разсмотрѣніе идею >>27396.

Переход на ПХП8 состоялся, но всякие мелочи ещё остались, поэтому с рассмотрением новых функций и всякого такого пока притормозим.

Тут я описал некоторые известные проблемы:
https://codeberg.org/FBE410/fbe-410/issues/15#issuecomment-1655734

Рекомендую включить показ ошибок в ПХП (https://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors ).

Предлагаю к теме «Futaba» крашеный скроллбар въ цвѣтахъ логотипа:

html { scrollbar-color: #1b7942 #fdffc7; }

Чтобы предпросмотрѣть, введите в отладочную консоль:

$('html').css('scrollbar-color', '#1b7942 #fdffc7')

>>27401
Оно должно быть в цветах «Футабы», а не логотипа, никак с ней не сочетающихся. Отказано.

Я считаю, что ни avif, ни webp, ни jxl не нужны. PNG, APNG, GIF и JPEG прекрасно справляются. А новомодные форматы лишь плодят фрагментацию, выбивают станые версии браузеров и вносят уязвимости в новые. Не так давно RCE в webp была. А что творится в AVIF и JXL — вообще мало кто знает. Лучше отключить, а неадекватными сайтами, сделавшими ставку на смузимусор — не пользоваться.

Так как файл >>/a/19707 занимает ровнёшенько 5 мегабайтов (5 242 880 байтов), то можно быть совершенно увѣренными в том, что ограничение работает в формулировке «не больше 5120 килобайтов», а не «до 5120 килобайтов», как это сейчас сообщается.

Отсюда возникает предложение строку интерфейса привести к виду «не больше ░▓▒ килобайтов», чтобы она адекватно описывала собою дѣйствительность.

>>27420
«До» не обязательно исключающее же.

>>27421

В общем-то да, но тогда бы неплохо опосля килобайтов добавить (через пробѣлъ) слово «включительно», которого там по умолчанию нѣтъ.

Сохраняющиеся после последнего обновления совместимости с ПХП8 проблемы:
https://codeberg.org/FBE410/fbe-410/issues/15#issuecomment-1807945

>>27417

Если повторявшиеся много сотен раз обнаружения чудовищных уязвимостей движка Flash (по адресу https://en.wikipedia.org/wiki/Adobe_Flash_Player#Security и https://en.wikipedia.org/wiki/Adobe_Flash#Security упоминаемые) всё же ничуть не помѣшали существовать имиджбордам, поощрявшим употребление Flash (по адресу http://boards.swfchan.net/13147/ перечислявшимся шесть лѣтъ назад), то тѣмъ болѣе всего-навсего одна-единственная (пускай громадная) уязвимость декодировщика WebP, найденная болѣе чѣмъ за десятокъ лѣтъ его жизни, не должна отвратить нас собою от употребления этого формата со всеми его достоинствами (по адресу https://t.me/readMithgol/760 перечислявшимися), тѣмъ болѣе что исходный код декодировщика всегда открыт мириадам глаз, с недавних пор много болѣе внимательным и придирчивым.

Что творится в AVIF — не неизвѣстно, а очень хорошо извѣстно, потому что этот формат является нехитрою переупаковкою видеокадров AV1, употребляющихся с 2019 года (а не то и ранѣе) цѣлою кучею видеосайтов, начиная от крупнейших (Netflix, YouTube и проч.) и заканчивая краткими видеоцитатами на 410чанѣ. За это время всякая сколько-нибудь крупная уязвимость была бы обнаружена с высокою вѣроятностью. Для сравнения я напоминаю, что та крупная уязвимость в WebP, которой посвящён предшествующий абзац, обнаружена была не в обработчике той части формата, которая создана нехитрою переупаковкою видеокадров VP8, употреблявщихся с 2008 года (по лицензии On2) и с 2010 года (когда компания Google объявила неотзывный отказ от требования патентных отчислений) цѣлою кучею видеосайтов. Нѣтъ! — обнаружена она была в другой части формата, а именно в новинках WebP 2011 года, служащих для сохранения изображений без потерь, совершаемого по другому алгоритму, ужé никак на видеокодеке VP8 не основанному. Однако же в формате AVIF никаких таких невидеодополнений не существует, так что разрѣшеніе использовать AVIF — это всего только разрѣшеніе использовать видеокадры AV1 (которых и без того вдоволь на 410чанѣ) под другим заголовком. (Оборотной стороною желания неуклонно обходиться в AVIF без подобных невидеодополнений сдѣлалася малоэффективность такого сохранения изображений, которое совершается без потерь, так что в сравнении с AVIF формат WebP лучше подходит для такой задачи, когда и если пикселы не болѣе чѣмъ двадцатичетырёхбитны. Но это ужé не вопрос безопасности формата.)

Поддержка формата JPEG XL движком 410чана пока ещё не может служить предметом обсуждения, потому что формат этот поддерживается только браузерами Safari компании Apple, да и то не в полном объёме (без анимации). Господин Соусов долгие годы здѣсь воздерживался от дозволения таких форматов, которые браузерами Safari ещё не поддерживалися (несмотря на небольшую распространённость таковых браузеров) — слѣдовательно, ужъ тѣмъ болѣе рановатым должны быть признан всякий такой формат, который одними только браузерами Safari поддерживается покамѣстъ.

Чтобы нынѣшнее положеніе дѣлъ со сжатием изображений не осталося непроиллюстрированным, я прилагаю здѣсь небольшой архив (7-Zip) с тремя файлами, продолжающими собою челлендж 2021 года, по адресу https://410chan.org/b/arch/res/158687.html#158725 начатый — иными словами, прилагаю итог сжатия тутошнего мема «NICE BOAT» до величины чуть меньше 20 260 байтов. Один из файлов показывает итог сжатия в формате AVIF (при помощи libavif v1.0.4, то есть сáмой свѣжей релизной версии), два других — в формате JPEG XL, достигнутом двумя вариантами сжатия (модульным и VarDCT) сегодняшнею версиею кодировщика.

jxl давно в Firefox поддерживается. Может не полностью, но поддерживатся. А на сжатие мема - я уже сказал, пофиг. Никакие несущественные прибавки в качестве или коэффициенте сжатия не не компенсируют слом совместимости.

А на флеш плеер вообще пофиг, с 2009 года его не использую. Ну а кто хочет - может жрать.

>>27448

> jxl давно в Firefox поддерживается. Может не полностью, но поддерживается.

Поддерживается-то поддерживается, но здѣсь необходимо сдѣлать как минимум два важных уточнения:

① только в nightly-сборках Файерфокса,

② и притом ещё только у таких пользователей, которые загодя заглянули на страницу «about:config» и вручную перекинули там переключатель «image.jxl.enabled» в значение «true».

То есть, можно сказать, почти ни у кого не поддерживается.

>>27448
В случае с lossless JXL они там весьма существенные. -50% от PNG-шного размера анимешных картинок не редкость. Под -20% для JPEG-ов с возможностью реконструкции.
Исходник этой вот картинки 9 019 028 байт. Если дожать с zopflipng -m, то получится 6 234 680. А если воспользоваться cwebp, то оно без проблем и потерь пролезает в /b/ (4 461 710). Размер lossless JXL-ки с некоторыми параметрами: 3 360 511.
Существенно оно для мелкочанов с маленьким пределом на размер файла и для дешёвых VPSок. Ещё существенней для архивов.

>>27451

Несомнѣнно.

Вообще же существование таких картинок, которые (при сжатии, без внесения потерь совершаемом) оказываются способными на 410чанъ помѣщаться только в новом формате (оттого что старый недостаточно сжимает), было показано больше трёх лѣтъ назад:

https://410chan.org/b/arch/res/158687.html#159029

Пока работа, видимо, в очередной раз встала, напомню, что у нас есть много всяких задач, заведённых от многих месяцев до многих лет назад: https://codeberg.org/FBE410/fbe-410/issues

Отдельно отмечу https://codeberg.org/FBE410/fbe-410/issues/11 — хотелось бы уже избавиться от избыточного фрейма по умолчанию.

Также до сих пор не завершена работа с переходом на ПХП8: https://codeberg.org/FBE410/fbe-410/issues/15

Любители пофлудить за форматы могли бы допилить поддержку ВЕБП уже, наконец: https://codeberg.org/FBE410/fbe-410/issues/9

Вопрос >>27068 также всё ещё актуален.

>>27453
> issues/9
Погляжу на выходных и, скорее всего, кину исправления в тред. Не даёт codeberg по throw-away'ке регаться.
> issues/11
Если нужно, чтоб по https://410chan.org/ показывалось news.php, то достаточно в .htacess поменять DirectoryIndex с kusaba.php на news.php.

Таки поглядел прямо сейчас, там всё просто.
В строке 4372 у inc/classes/manage.class.php, в if со списком форматов добавить сравнение $line['filetype'] == 'webp'.

> issues/15
На выходных тогда посмотрю, много ли там работы по устранению deprecated-ов.

> Вопрос >>27068 также всё ещё актуален.
Думаю, можно попробовать спросить у по https://bulochka.org/b/. Есть подозрение, что автор скриптов нынче где-то там. Ну, или на Ичане. Или в /b/.
Но если добавлять, не лучше ли в суперскрипт вместо количества постов ставить какую-нибудь ✿-пометку, если новые посты есть? Иначе ведь действительно ширина менюшки скакать будет.

>>27454
Если движок штатными средствами назначает главной kusaba.php, то он штатными средствами должен назначать news.php. Кому-то следует изучить этот вопрос.
Тем более, что в задаче требуется оставить рабочие опции с использованием фрейма для его фанатов.

>>27455
Ок, попробую добавить.

>>27457
Я не буду кого-то искать неизвестно где. Разве что в /b/ напишу, наверное. Если человек сюда не ходит, ему оно вряд ли интересно. Если автора нет, то кто-то ещё мог бы предложить свою реализацию.
>Иначе ведь действительно ширина менюшки скакать будет.
Да вроде у нас и меню не такое большое, и числа, чтобы это критично было. Вот для мобилок можно было бы альтернативную индикацию попробовать сделать.

Вослѣдъ >>27455 хорошо бы туда же добавить «'avif'» — так сказать, «на вырост».

За год и ещё за три недѣли, со дня вопроса >>27068 прошедших, никто не откликнулся.

Руководясь этим, предлагаю впредь предполагать, что вообще никто не сохранил этот скрипт — и что было это оттого только, что у того скрипта было мало и недостаточно пользователей. Спрос был невелик и не пережил груза лѣтъ.

Исходя из этого, если сейчас необходим аналогичный скрипт, то тогда поневоле придётся отказаться от приятной мысли о возможности разыскать его в готовом виде, а вмѣсто того придётся сочинить его с нуля, а для того хотя бы заново попробовать сформулировать желаемое, чтобы был понятен объём возможной работы и прояснилася конечная цѣль ея.

Навскидку малопрояснёнными выглядят вот эти четыре самых начальных группы вопросов:

① Должен ли это быть юзерскрипт (для ViolentMonkey или аналогичнаго расширения во браузере)? — или же это должен быть сайтовый скрипт (часть движка FBE)?

② Как часто он должен стучаться на сайт, не заставляя опасаться того, что пара-тройка-другая десятков пользователей скрипта, одновременно эдак стучась, перегрузит сайт собою? (Раз в минуту? Нѣсколько раз в минуту? Один раз въ нѣсколько минут?)

③ Должен ли этот скрипт скачивать и сканировать заглавную страницу каждаго раздѣла в поисках номеров сообщений, превосходящих запомненный номер? — или же можно нифигушеньки не сканировать, а использовать какой-нибудь готовый API, нарочно для этой цѣли в движке FBE заготовленный?

④ Достаточно ли (как это предложил нам автор сообщения >>27457) ограничиваться демонстрациею однобитного флага «есть новыя сообщенія», или всё же необходимо их количество? Если их количество необходимо, то достаточно ли руководиться разностью между номером свѣжайшаго сообщенія, существующего въ подраздѣлѣ, и номером ранѣе запомненнаго сообщенія, пользователем прочитаннаго при заходе въ подраздѣлъ? — или же этого одного не достаточно, а скрипт должен нѣкоторымъ способомъ провѣрить промежуточныя сообщения на стёртость, чтобы при необходимости уменьшить показываемую разность на ту величину, которая равна количеству стёртых сообщений? (А для той провѣрки в FBE есть ли API чуть лучше, чѣмъ обращение по AJAX на адрес «ku_boardspath + '/expand.php'» для получения текста каждого сообщения?)

Кстати вот ещё:

⑤ Должен ли счётчик непрочитанных сообщений обнуляться в тот момент, когда пользователь навѣстилъ подраздѣлъ? — или всё же неплохо бы https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API задѣйствовать для того, чтобы новое сообщение считалося прочитанным тогда только, когда оно реально вплывает в видимую часть окна браузера, причём не началом, а концом своим? — да не стóит ли дополнительно навѣсить таймер и смотрѣть, долго ли новое сообщение остаётся в области видимости, чтобы исключить ложныя срабатыванія во время быстрой прокрутки страницы?

>>27463
>>27464
① Судя по всему, речь о внесении изменениний в FBE;
② Пока вполне можно захардкодить проверку раз в 5 минут и не париться. Доски у нас не очень быстрые. Потом можно вынести это дело в config.php или на страницу управления. Ещё можно запилить динамический интервал, с умножением его по каждой проверке на какой-то коэффицент до достижения потолка: сначала проверяется через 1 минуту, через n не обнаруживших изменения проверок - раз в 5 минут;
③ Вроде там никакого API для этого нет. Вместо скачивания нулевой можно скачивать https://410chan.org/b/rss.xml. Но проще по-быстрому PHPшку написать, которая select max(id) from posts_(?) будет отдавать;
④ Судя по всему, не достаточно. Можно отдавать разницу меж максимальным ID и текущим записанным в печеньки/local storage. Вряд ли уж сильно критично, если количество новых постов получаемое таким образом иногда будет не очень точным. Чтобы сильно ссылки на борды не скакали, когда разница та больше 9, можно вместо +9 отображать +∞ или >9;
⑤ Пока в качестве MVP запилить что попроще, а космолёт потом строить, если надо будет.
Таковы мои мысли по этому поводу.

>>27458
.htaccess, который в KU_ROOTDIR, кусабовскими скриптами, кроме как для добавляния забаненных IP, не меняется. То бишь, этот Apache'шный конфиг до метки "## !KU_BANS:" совершенно статичен и единственное место, где настраивается файл главной.

По замене DirectoryIndex-а в .htaccess скрипт https://410chan.org/kusaba.php будет продолжать работать, можно сделать симлинк f.php, чтобы фанатам было нетрудно набирать. Нужно будет также убрать target="_top" из <a>'шки-домика, иначе по клику на домик во фрейм-контексте человека вернёт на https://410chan.org без фрейма.

> Заодно стоит починить скриптовую функцию “Убрать фреймы” во фрейме, которая, кажется, сломана.
Функция эта в текущем варианте меняет ссылки на доски во фреймовом меню так, что при клике на них человек перейдёт на страницу без фреймов. То бишь, «Фреймы убраны» — это про то, что они убраны из ссылок на доски, а не из поля зрения.

Вообще, есть такая идея, как поступить с фреймами.

Само по себе меню со списком разделов слева и news.php в центре выглядит отнюдь не плохо, как дизайн главной. Куда лучше уродливой ичанской главной, например. Может, сделать, чтобы по переходе на доску из фреймового меню переход убирал фреймы по умолчанию, аналогично поступив с ссылками, приведёнными в news.php? И тогда поменять опцию “Убирать фреймы” на “Оставить фреймы”.

>>27464
Ещё, может быть, надо учесть кейс с несколькими открытыми вкладками и долгоживущими вкладками.
Как ведут себя значения в localStorage читаемые и записываемые из нескольких вкладок. Не придется ли тут синхронизацию какую городить через postMessage.

>>27465
На самом деле, нам действительно не помешало бы АПИ или что-то такое, дабы оптимизировать работу скриптов и запилить вещи типа https://codeberg.org/FBE410/fbe-410/issues/6
Просто я в этом ничего не понимаю. Надо, чтобы кто-то проанализировал существующие реализации. Я могу только задачу на трекере завести официальную, лол.

>>27469
Этот десигн ничем не лучше ычановского. И вообще пока висит как заглушка, потому что новости не используются из-за https://codeberg.org/FBE410/fbe-410/issues/14
Список досок на главной надо будет сделать, но это уже следующая фаза. И опять же его надо будет делать относительно новостей.

Deprecated: Optional parameter $thread_id declared before required parameter $time is implicitly treated as a required parameter in lib/search.php on line 43
> lib/search.php 43: function create_search_record($post_id, $thread_id = 0, $board, $message, $time)
Вроде используется оно только в board.php и только в одном месте, где при вызове $thread_id указан.
> board.php 553: create_search_record($post_id, $thread_replyto, $post['board'], $raw_message, $time);
Поэтому значение по умолчанию для $thread_id из объявления функции в search.php можно спокойно убрать.

Deprecated: Optional parameter declared before required parameter $note is implicitly treated as a required parameter in inc/classes/bans.class.php on line 84
> inc/classes/bans.class.php 84: function BanUser($ip, $modname, $globalban, $duration, $boards, $reason, $appealat=0, $type=0, $allowread=1, $note)
Везде, где оно используется, аргументы для параметров, у которых значения по умолчанию, передаются явно.
Можно смело убирать присваивания, но после того, как будет указан недостающий $note аргумент тут
> inc/classes/manage.class.php
> 2999: $bans_class->BanUser($ban_ip, mysqli_real_escape_string($tc_db->link, $_SESSION['manageusername']), $ban_globalban, 0, $ban_boards, mysqli_real_escape_string($tc_db->link, $_POST['reason']), 0, 0, 1);
И тут
> board.php
> inc/classes/posting.class.php
> 235: $bans_class->BanUser($_SERVER['REMOTE_ADDR'], 'SERVER', '1', $results[0]['bantime'], '', 'Posting a banned file.<br>' . $results[0]['description'], 0, 0, 1);

Там местами по коду, когда $note брать неоткуда, в качестве $note пихается то, что запихано в $reason, так что указанные строки можно по аналогии поменять на
> $bans_class->BanUser($ban_ip, mysqli_real_escape_string($tc_db->link, $_SESSION['manageusername']), $ban_globalban, 0, $ban_boards, mysqli_real_escape_string($tc_db->link, $_POST['reason']), 0, 0, 1, mysqli_real_escape_string($tc_db->link, $_POST['reason']));
И
> $bans_class->BanUser($_SERVER['REMOTE_ADDR'], 'SERVER', '1', $results[0]['bantime'], '', 'Posting a banned file.<br>' . $results[0]['description'], 0, 0, 1, 'Posting a banned file.<br>' . $results[0]['description']);
Соответственно. Но можно и тупо пустую строку '' запихать.

Сделать это, убрать дефолтные значения для параметров, и deprecated-ы на странице входа в management оно не пишет. Warning-а при переходе на страницу управления банами, кажется, нет. Может, из-за этих изменений.

Also, там по вызовам то стоит mysqli_real_escape_string, то не стоит. Поди разберись, где оно надо, а где надо.

phpstan говорит, что с FBE проблем немножко больше, чем может показаться на первый взгляд. Надо будет поглядеть, на что именно статический анализатор ругается, и пофиксить то, где он ругается не зря.

>>27471
> https://codeberg.org/FBE410/fbe-410/issues/6
> полностью пустое сообщение, к ОП-посту не приложен файл, слишком длинный текст, слишком большой или кривой файл, не введена капча и т.д.
Кривой файл или нет, это пусть проверяет сервер, наверное. Разве что проверять, соответсвтует ли заголовок файла его расширению для некоторых форматов во избежание >>26890-ситуации.
А так, по перечисленному, информация для проверки на стороне клиента вроде вся, кроме максимальной длины текста, есть. Только её вывод в board-post.class.php и добавить рядом с MAX_FILE_SIZE. Что-то радикально новое со стороны сервера тут не нужно.

> Этот десигн ничем не лучше ычановского.
Ещё скажи, что хуже, лол.

>>27477
>Ещё скажи, что хуже, лол.
Я скажу, что тут просто никакого десигна нет. И при появлении блока новостей оно будет вообще выглядеть почти аналогично.
На «Ычане» только надпись надо выравнять, вместо неё картинки были раньше.

>>27478
> И при появлении блока новостей оно будет вообще выглядеть почти аналогично.
Ugh. Значит, лучше не приступать.

>>27479
Можно просто на главную не ходить, если какие-то психологические проблемы. На неё и так никто не ходит, кроме жертв фрейма.

>>27480
Сомневаюсь я, что, например, вот этот >>/ci/1605 вот постер набрал https://410chan.org/ci, а не перешёл туда с главной.
Пусть наша приветственная страница выглядит хорошо.

> color: #800000;
> font-weight: bold;
Так и задумано? Или postername-стиль в umnochan.css по ошибке поменялся?
Предыдущие значения были:

color: #310000;

font-family: sans-serif;

>>27482
Да, теперь во всех стилях имя оформлено одинаково.

>>27477

> проверять, соответствует ли заголовок файла его расширению для некоторых форматов во избежание >>26890-ситуации

Чтобы было нѣкоторое понимание того, какъ дѣлаются такие штуки, я здѣсь оставлю ряд замѣтокъ.

Сперва получаем список файлов (а поскольку параметра «multiple» у тега нѣтъ, то там либо один файл, либо ни одного):

const flist = $('[name=imagefile]')[0].files;

if( flist.length < 1 ) return;

Там может быть «[1]», если обрабатывается плавающая формочка быстраго ѿвѣта.

Затѣмъ надо достать ArrayBuffer оттудова, причём процесс это асинхронный:

const freader = new FileReader();
freader.onload = function(evt){
   const fBuffer = evt.target.result;
};
freader.readAsArrayBuffer(flist[0]);

Внутри обработчика события onload мы можем вызывать буферу провѣрку на заголовок графического файла как-нибудь так (в хронологическом порядке форматов):

function whatImageFile( fileBuffer ){
   const view = new DataView(fileBuffer);

   if(
      view.getUint32(0) === 0x47494638
   ) return 'GIF';

   if(
      view.getUint16(0) === 0xFFD8
   ) return 'JPEG';

   if(
      view.getUint32(0) === 0x89504E47 &&
      view.getUint32(4) === 0x0D0A1A0A
   ) return 'PNG';

   if(
      view.getUint32(0) === 0x52494646 &&
      view.getUint32(8) === 0x57454250
   ) return 'WebP';

   if( view.getUint32(4) === 0x66747970 && (
      view.getUint32(8) === 0x61766966 ||
      view.getUint32(8) === 0x6176696F ||
      view.getUint32(8) === 0x61766973
   )) return 'AVIF';

   return false;
}

У нас здѣсь на имиджборде всё так устроено (и мы так привыкли), что сообщение никак нельзя редактировать опосля отправки.

Но в результате получается примѣрно так (и нерѣдко), что поставлена гиперссылка, на https://410chan.org/b/res/156266.html#156266 ведущая (этот примѣръ в сообщении >>/b/194168 взят), а нифигушеньки не работает, потому что тема обсуждения ужé оказалася заархивированною и оттого по адресу https://410chan.org/b/arch/res/156266.html располагается.

Нешто трудно, пусть и не редактируя давния сообщения, «на лету» (во время обращения по ссылке) прибавлять HTTP-перенаправление (на arch/ перебрасывающее браузер читателя) в таких случаях, когда обсуждения нѣтъ, но архив его зато есть?

>>27486
Это никак не относится к работе движка.

>>27474
Поглядел. Ошибки, вызыванные переходом на новые версии, поправил. Разницу меж файлами можно проверить через diff current-fbe-dir corrected-dbe-dir.

Частично нереализованные с неизвестно каких времён функции допиливать не стал. В частности, не стал заморачиваться с котобавским mark.php, он всё равно нигде не используется, кроме как в закоментированном коде. Поправил где-то ≈2 мелких ошибки, не относящиеся к переходу на новые версии, но все из них трогать не стал. Может быть, стоит обновить smarty, хотя вроде с ним проблем нет. С /issues/15, наверное, всё, если по ходу дела какие-то менее очевидные вещи не обнаружатся.

Могу взяться за проверку корректности формы постинга на клиенте или за проверку новых сообщений.

Файл с более подробным описанием изменений и комментариями к выводу phpstan тут.

>>27486
Всё просто, если просто по ссылке на несуществующий тред переходим. В отвечающем за 404 PHP-файле, если 404 получилось из-за перехода по URL типа https://410chan.org/b/res/156266.html#156266, то смотрим, есть ли такой HTML в /arch/res, и перенаправляем в /b/arch/res/156266.html#156266, если есть. Ну, это если ErrorDocument — PHP файл; кто знает, что там. Не находится текст «Страница, к которой вы обратились, отсутствует на данном сервере» или «alt="404"» по файлам в репе. «Никаких неопубликованных скрытых функций и частей не существует», лол. Возможно, поэтому, не относится к работе движка.

Чтобы по наводке курсора на >>/b/156266 подгружался пост из архива, с этим сложнее, потому что тут HTML надо парсить, и вёрстка там местами немножко разная. Но можно точно также проверять, есть ли тред в архиве, и если есть, то выводить, мол, перемещено в архив, перейдите по ссылке для просмотра.

>>27488
На странице manage_page.php?action=bans так и остался
>Warning: Undefined variable $count in /inc/classes/manage.class.php on line 2485
Ещё при удалении текстового сообщения без картинки варнинги вылазят (см. скриншот).

>>27495
> Warning: Undefined variable $count in /inc/classes/manage.class.php on line 2485
Поставить $count = 0; перед foreach-ем, который строчкой выше.
> board-post.class.php
В if-е на 2571-ой изменить проверку на $thumb_filetype || $this->allowed_file_types[$thumb_filetype][0] == 'video'

Упомянутые warning-и это решает.

BTW, судя по всему, так, как оно реализовано, для тредов с ОПом без файла или с удалённым файлом оно при удалении в режиме архивации пытается копировать несуществующий файл-приложение к посту и пишет в модлог Couldn't archive file x in post y. Но это надо проверить, и переход на PHP8 тут не при чём.

>>27498
Вы либо зарегистрируйтесь-таки в репозитории, или хотя бы патчи присылайте.

>>27500
Поскольку изменения тривиальные, мне с телефона проще отправить пост, а тебе посмотреть и скопипастить. Или так мне подумалось. BTW, там у меня в >>27498 && вместо || должно было быть.

git apply путь_к_патчу

Или вот архив с новыми версиями файлов из inc/classes. Как тебе удобнее?

На будущее дописываю, что в исходном коде >>27485 опредѣлитель JPEG XL выглядѣлъ бы вот как:

if( view.getUint16(0) === 0xFF0A || (
   view.getUint32(0) === 0x0000000C &&
   view.getUint32(4) === 0x4A584C20 &&
   view.getUint32(8) === 0x0D0A870A
)) return 'JXL';

Если возвращаться к теме счётчика новых сообщений, то в модерке уже есть страница со статистикой разделов за последний час.
Возможно, можно что-то на этой основе сделать?

Но в целом, конечно, хорошо было бы, если бы кто-то изучил возможность оптимизации работы скриптов. АПИ не АПИ, но что-то такое, дабы работало по уму.

>>27513
С переходом на PHP8 больше проблем не обнаружено? Тогда, наверное, могу заняться.

> Возможно, можно что-то на этой основе сделать?
Вряд ли. Я думаю добавить PHP-файл, который будет отдавать JSON, где для каждой из досок, попадающих в navbar, будет номер последнего поста. Сделать это нетрудно. Остальная работа больше по фронту: HTML и JS.

>>27518
>С переходом на PHP8 больше проблем не обнаружено? Тогда, наверное, могу заняться.
Новых проблем с ПХП8 пока не выявлено по крайней мере, да.

Так как состояние >>27537 вроде как означает, что приостановление >>27399 завершилося, то теперь прилагаю копию файла inc/func/posts.php, патченного по соображениям >>27396.

Прошу втащить в репу.

(Но перед запуском AVIF потребуется ещё, как минимум, >>27461.)

>>27539
> inc/func/posts.php
Там ещё как минимум в kusaba.js есть форматоспецифичный код.

>>27540

Да.

(Там однострочник: достаточно добавить 'avif' в массив imageExtensions через запятую.

Сейчас он на строке 652.)

>>27518
>Вряд ли. Я думаю добавить PHP-файл, который будет отдавать JSON, где для каждой из досок, попадающих в navbar, будет номер последнего поста. Сделать это нетрудно. Остальная работа больше по фронту: HTML и JS.
Звучит приемлемо.
Давайте обсудим, как эта лабуда должна себя вести. Мне кажется, должно быть что-то в таком духе: когда пользователь впервые заходит на сайт, эта штука начинает отсчёт и раз в N минут обновляет счётчик, когда пользователь заходит в раздел, счётчик этого раздела сбрасывается. На мобилках, вероятно, действительно, стоит просто пометку ✿ вместо чисел выводить, когда есть новые сообщения, чтобы меню не расползалось.

>>27543
> Я думаю добавить PHP-файл, который будет отдавать JSON
Изменение. Я посмотрел, как там создаётся https://410chan.org/b/rss.xml, и пишу создание JSON-файла одномоментно с RSSом. Также как и с RSSом, будет файл на сервере, обновляющийся по любой отправке нового поста, скажем, https://410chan.org/navbar_last_posted.json.

> На мобилках, вероятно, действительно, стоит просто пометку ✿ вместо чисел выводить, когда есть новые сообщения, чтобы меню не расползалось.
OK.

> Мне кажется, должно быть что-то в таком духе: когда пользователь впервые заходит на сайт, эта штука начинает отсчёт и раз в N минут обновляет счётчик, когда пользователь заходит в раздел, счётчик этого раздела сбрасывается
Да. Единственно что, вкладок с одним разделом в браузере может быть открыто несколько. Поэтому видимый счётчик для ныне открытого во вкладке раздела будет именно сбрасываться только по обновлению той вкладки.

Ещё у меня есть мысль сделать срок обновления счётчкика рандомизированным меж 0 и N, чтобы по timing-у было сложнее отслеживать.

Ещё есть вариант в браузере запоминать время последних M отправленных постов, и динамически определять срок обновления по частоте постинга.

Если у меня не поменяются планы, где-то к субботе будет готово.

Мне будет удобно, если выложишь пример свёрстанного HTML, где в navbar'е для некоторых ссылок на доски есть счётчик в желаемых цветах/стилях.

Кажется, оно работает. Прошу, поглядите.

Чтобы поставить, скопировать файлы и в конфиг добавить KU_NAVBARCOUNTERS и KU_MAXNAVBARCHECKDELAY так, как это показано в __config_sample.php, и перегенерировать все страницы.

У sup-ов счётчиков классы desktop-navbar-counter и mobile-navbar-counter. Стили я не делал, в img_global.css прописан только display.

>>27550

Я вижу, что за недѣлю замысл совмѣстить >>27539 + >>27461 + >>27542 (чтоб на этой почве запустить поддержку AVIF) не добрался до репы даже краешком.

Поэтому предлагаю считать его отложенным далеко в сторону до того времени, когда у администрации всё же возникнут нѣкоторыя такія искры практическаго энтузиазма, которыя готовы будут проявиться именно в этом направлении (что даже в сáмом лучшем случае произойдёт ни минутою раньше, чѣмъ состоится запуск счётчиков).

>>27548
>писать жсон
Конечно, не моё дело, так как не я это пишу и мне лень это писать, но я свою версию для Ычана так писал потому что жсон для Степана у меныя уже есть. А так можно и текущий xml парсить.

>>27553
> А так можно и текущий xml парсить.
Можно. Только, тут не XML, а несколько XMLов. Или несколько запросов к XMLам, каждый где-то по 15 килобайт, каждый надо parse-ить, или один готовый JSON-файл на 100 байт. Чем пилить parsing первого на front-е, мне показалось разумней и проще сделать второе на back-е, раз уж доступ к нему есть.

>>27554
Парсится оно один раз, благо всё по одному шаблону. Нормальный браузер ещё и кешировать будет, так что без лишних телодвижений большую часть времени.
Ну да что так, что так, нагрузка на сервер не должна быть высока.

Чтобы парсить JSON, достаточно JSON.parse вызвать.

Расскажите, чѣмъ предлагаете парсить XML?

>>27556
let resp;
function reqListener() {
resp = this.responseText;
}

const req = new XMLHttpRequest();
req.addEventListener("load", reqListener);
req.open("GET", "http://410chan.org/dev/rss.xml");
req.send();
const parser = new DOMParser();
const xmlDoc = parser.parseFromString(resp,"text/xml");
const lastpost = xmlDoc.getElementsByTagName('title')[1].innerHTML;

В таком случае я пока ещё не увидал, на чём основывалося мнѣніе «один раз» в утверждении «Парсится оно один раз, благо всё по одному шаблону» в сообщении >>27555.

Вы предполагаете во браузере способности к машинному обучению и послѣдующему пониманию сходства строк, в метод parseFromString передаваемых?

>>27560
Это про то, что за одну проверку парсится каждый XML только один раз: только, чтобы из построенного DOM-а взять содержимое первого title-элемента, где находится ID последнего поста. Или про то, что достаточно код parsing-а написать лишь для одного rss.xml и что этот код для каждого rss.xml работает, ибо «всё по одному шаблону». Было бы не по одному шаблону, parsing бы пришлось писать разный для разных форматов.

Спасибо за пояснение.

Присоединяюсь ко мнѣнію >>27554.

Переработан код счётчиков на front-е, пофикшены некоторые (потенциальные) мелкобаги, заголовкам GET-реквеста к JSONу сделано похудение.

Поскольку IDшники постов в JSONе теперь числа, а не строки, для обновления будет необходимо перегенерировать JSON. Можно сделать, отправив пост или выполнив любое действие, остающееся в modlog-е. Если в localStorage браузера хранятся данные со старой версии counter-ов, для обновления затем стоит либо удалить переменные latest_posts и navbar_offsets из localStorage, либо посетить каждую видимую в navbar-е доску.

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

>>27565
> + <Files *.html)>`
Ц, опечатка: в .htaccess скобку после “.html” забыл убрать. Стоит поправить после применения патча или копирования файлов.

Запуск счётчиков выглядит состоявшимся.

Причастных поздравляю и благодарю за усердие.

Однако два вопроса:

① Как насчёт >>27552 теперь, а?

② Отправка моего собственного сообщения, по-видимому, наращивает счётчик на единицу. Нехорошо!

>>27568
>① Как насчёт >>27552 теперь, а?
Мне оно не особо надо, и большого спроса со стороны я на это не вижу. Если восприятие ВЕБП за годы его существования остаётся ограниченным, то тут тем более. У нас куча задач висят годами, а тут даже пулреквеста в репозитории нет, чтобы по-быстрому можно было накатить.
>② Отправка моего собственного сообщения, по-видимому, наращивает счётчик на единицу. Нехорошо!
Счётчик обновляется, если вкладка/окно является неактивным в момент отправки сообщения. Он не проверяет, чьё это было сообщение. Если вы отправили, и начинаете куда-то переключаться, пока оно грузится, счётчик может посчитать его.

>>27568
Сейчас для каждой страницы доски по открытии заводится своя собственная offset переменная.

Поэтому, если, скажем, было открыто две вкладки с /b/, но была F5-нута только одна из них, у другой вкладки с /b/ для /b/ отображаемый счётчик не обнулится, свидетельствуя о возможной неактуальности содержимого той вкладки.

Аналогично, если открыта вкладка с /b/ и вкладка с тредом в /b/, а пост был отправлен через вкладку с тредом, то на вкладке с /b/ для /b/ увеличится счётчик. Поведение ожидаемое.

Если же, скажем, открыта одна вкладка с /b/, через эту вкладку был отправлен пост, то отображаемый счётчик для /b/ увеличиваться не должен. Случилось именно это или что-то из описанного выше?

>>27570
Судя по всему, случилось именно это: для JSONа сервер не отдаёт заголовок "Cache-Control: no-cache".
Видимо, нужно перезапустить Apache

systemctl restart httpd

>>27571
Вроде, что-то подкрутили, смотрите теперь.

>>27572
Теперь работает верно, но загловки почему-то удвоенные, чего не должно быть.

У меня это выглядит так.
Мой .htaccess вроде не отличается от текущего в репе.

Как обрабатывается случай с множеством открытых вкладок чана?
Счетчики в них будут устревать или как-то синхронизироваться/обновляться?

>>27575
> Синхронизироваться/обновляться
Это.

В local storage, который для вкладок общий, хранится JSON {доска:id-шник последнего поста} и JSON с offset-ами {доска:id-шник последнего поста при последней загрузки страницы доски}. При загрузке страницы доски, offset в этом JSONе обновляется соответствующим значением из первого JSON-а. Скачивание и обновление первого JSONа try-ится:

• При загрузке страницы;
• Через случайное время — если document visible;
• Если document становится visible.

Для вкладки, её видимые счётчики обновляются разницей по тем двум JSON-ам в тех же случаях. Если вкладка — вкладка со страницей доски, то для этой доски на ней заводится своя offset-переменная и разница считается с ней. Страница доски не страница треда.

>>27576

> Страница доски не страница треда.

То есть достаточно поставить галочку напротив «nöko» для того, чтобы собственным сообщением нарастить счётчик на единицу?

>>27577
Да, на странице треда достаточно. Значит, всё-таки нужно обрабатывать успешную отправку поста. По ней в board.php тогда redirect-ить на URL с параметром, на наличие которого потом смотреть в JS, и при наличии инкрементировать offset.

>>27579
Я думаю, что можно на это забить. Вряд ли много оригиналов используют ноко с нашей медленной скоростью, лол. Даже на «Ычане» это было бы неактуально.

>>27488
>Могу взяться за проверку корректности формы постинга на клиенте
Если речь была про № 6, то там надо учитывать, что оно должно работать как можно более нативно и не парсить лишнее. Возможно, вообще придётся глобально разбираться, как эти проверки работают, и что-то оптимизировать.

>>27580
На Ычане ноко не то что бесполезна, а скорее бесмывсленна, ибо неработает.

>>27581
Переключатель «Перейти к» сломался, что ли?

>>27569

> большого спроса со стороны я на это не вижу

Со стороны — это откудова?

В качестве иллюстрации прилагаю скриншот сообщения https://desuarchive.org/g/thread/101425833/#101426846 на Форчане.

1) Счётчики больше не увеличиваются по отправке собственного поста;
2) Запилена настоящая синхронизация через BroadcastChannel:

• Если открыто несколько окон, содержимое счётчиков у них будет меняться одновременно;
• Polling-ом JSONа занимается только одна вкладка — даже в случае, когда открыто несколько visible страниц (в случае, когда открыто несколько окон).

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

>>27580
Про №6. №6 — это про что-то типа того, что на картинке, верно ли я понимаю? Хочу узнать, как оно внешне должно выглядеть, ибо у нас форма постинга от 4чанской отличается.

> Возможно, вообще придётся глобально разбираться
С технической стороны тут нет ничего сложного, мне кажется. Сделать, чтобы ограничения на содержимое поста писались в:

1. JS-переменные;
2. HTML-элементы (на страницах по какой-то причине уже есть скрытый input с MAX_FILE_SIZE);
3. JSON, который потом fetch-ить — но не будет случая, когда ограничения в модерке поменялись, а ограничения на страницах, которые забыли перегенерировать, старые.

Лучше, наверное, в JSON.

В kusaba.js по клику на «Отправить» смотреть на соответстие поста этим ограничениям, выводить надпись или диалоговое «окно» в случае, если что-то не так. Но лучше надпись, как по мне. Хотя сейчас пустой ответ на текстовую капчу ведёт к появлению dialog-а. Но поменять не трудно.

>>27569
AVIF лучше WebP для анимированных картинок, но вместо них у нас постят видео. AVIF лучше для тяжёлых рисунков и фотографий, которые без потерь не пролазят. AVIF хуже, чем WebP, в сжатии без потерь.

Думаю, можно ввести на пробу и убрать, если вскоре кто-то потом как с WebP заругается.

Худшее, что может случиться, наверное, это если поддержку AVIF через N лет из браузеров вообще выпилят: если вдруг Google снимет крест с JPEG XL, у AVIF будет куда меньше usecase-ов. В Palemoon автор было не стал добавлять поддержку AVIF под похожим предлогом и, наверное, так и не добавил. Хотя пользуется ли им тут кто?

Наверное, лучше в /b/ спросить, надо/не надо, и потом решить.

Also, SauceNAO поддерживает WebP. Но не AVIF. Если кто-то решит найти источник запощенного с потерями, ему придётся искать, чем это дело перешакалить. Именно перешакалить, потому что lossless AVIF практически бесполезен. С другой стороны, обычно по имени файла и так понятно, откуда оно есть. Но Google-поиск тоже AVIF не понимает. Ну и ни на одну неFBEшную борду без перешакаливания AVIF с 410 не запостишь, наверное.

>>27590
Или же не делать клиентскую валидацию вообще, а просто добавить на сервер отдельный эндпоинт, который будет возвращать ошибки постинга в компактном JSON-виде, вместо текущей HTML-страницы. Затем отправлять на этот эндпоинт запрос из формы аяксом. Если в JSONе возвращаются ошибки, то выводить в форму ошибки, а если успех - перезагружать страницу, как раньше. Просто и элегантно. Мимо автор текущей формы

>>27593
Там оно сейчас по любой неправильности из разных мест делает exitWithErrorPage, на остальные ошибки не смотрит. Так что всё равно придётся как-то дублировать/менять логику проверок, пусть и на сервере, пытаться эти проверки вычленить.

Есть некий минус в том, что при таком варианте потенциально инвалидный пост шлётся на сервер целиком: как и сейчас, вместе с файлом. Отправлять на поезде с мобилки длиннопост, только чтобы через несколько минут оказалось, что собщение слишком длинное…

Тем не менее, если ошибки выводить не все, выглядит действительно заманчиво:

1. В misc.php для функции exitWithErrorPage делаем обработку случая, когда запрос пришёл с Accept: text/plain.
2. Пришёл код отличный от 200? Выводим на странице в ошибкоместо пришедший text/plain; иначе переренаправляем на содержимое Location заголовка.
3. Да и всё.

Но, наверное, по-хорошему всё-таки стоит делать совместно с проверкой на клиенте того, что пересылки содержимого формы не требует: например, той самой длины текста. Кстати о ней, доколе она будет считатся в байтах, а не в символах? Стоит поменять ту проверку на проверку с mb_strlen.

>>27588
>2)
https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel#browser_compatibility
Может, fallback стоит оставить, если возможно.
У меня тут на нескольких сайтах уже всё или почти не работает, а в консоли ошибка Object.hasOwn is not a function. Ещё было с window.crypto.randomUUID и чем-то вроде i18n. Вот берут свежие API, а где их хваленые траспилеры, полифилы и бабелы?.. Браузер не 2016 года, но и не настолько древний, даже не 5 лет тухлости.

>>27590
> Хочу узнать, как оно внешне должно выглядеть, ибо у нас форма постинга от 4чанской отличается.
Тут либо как на «4чане», чтобы плашка появлялась в форме, либо как на некоторых других сайтах где-то в углу (и сама пропадала). Не знаю, кому как, на самом деле.

>>27591
>>27592
Вот поэтому я не вижу пока смысла торопиться с АВИФами, потому что реальная поддержка формата в Интернете пока очень кислая.

>>27595
>например, той самой длины текста. Кстати о ней, доколе она будет считатся в байтах, а не в символах?
Да я в принципе не против, тогда можно счётчик оставшихся символов сделать, и просто не давать послать. Вроде ж нет подводных камней?

>>27596
Показ счётчиков не влияет на работу сайта, следовательно, никакого смысла усложнять и раздувать код, делая костыли для поддержки неназванных древних браузеров, тут нет.

>>27595

> с проверкой на клиенте того, что пересылки содержимого формы не требует: например, той самой длины текста. Кстати о ней, доколе она будет считатся в байтах, а не в символах? Стоит поменять ту проверку на проверку с mb_strlen.

>>27599

> Да я в принципе не против, тогда можно счётчик оставшихся символов сделать, и просто не давать послать. Вроде ж нет подводных камней?

Сам я ещё не смотрѣлъ, но если в базе данных длина поля сообщения ограничивается по числу его байтов (а чаще всего именно это случается), то лучше этим же числом ограничивать его и в интерфейсе, чтобы не сооружать своими руками нехилый подводный камушек, приводящий либо к попытке записывать больше, чѣмъ реально сохранится, либо к попытке чрезмѣрно ограничить текст, состоящий из однобайтовых (а иногда и двухбайтовых) сѵмволовъ в пользу ложно понимаемой комфортности многобайтовых.

(Окромя того, каким количеством ограничивается в базе, заодно поглядите и используемую там кодировку: UTF-8? UTF-16? или, может быть, нѣчто ещё болѣе неразумное и неэффективное, а поддерживать придётся вѣчно? или разумное и эффективное, но то и другое понятно не с первого взгляда и не со второго?)

>>27600
Там нет никаких ограничений, UTF-8.

>>27596
Но и это ещё не всё! Ещё там mutex через navigator.locks.request (Firefox 96, January 11, 2022), async/await вместо callback-ов (Firefox 52, March 7, 2017) и fetch (Firefox 39, July 2, 2015), в то время как BroadcastChannel был добавлен ещё в Firefox 34. В принципе, async/await меняемо на callback-и, fetch на AJAX, BroadcastChannel — наверное, можно поменять на window.postMessage, но на что менять mutex? async/await же был и в первой версии счётчиков.

>>27599
Конкретно async/await ведёт к SyntaxError, если в браузере оно не реализовано. SyntaxError ведёт к прекращению обработки скрипта. Таким образом, текущая версия kusaba.js вообще не работает на браузерах старше где-то 2017-ого.

>>27599
> и просто не давать послать
Пользователь может просто отключить скрипты, так что ещё поменять в posting.class.php на 120-ой strlen на mb_strlen.

>>27604
Да, интересно. И правда top-level await и только в этом участке. А ведь jQuery подключен. В принципе обычный транспилер это может переделать сам, думаю. Но раз уж Соус говорит не заморачиваться то и ладно.
В Firefox 88, например, navigator.locks нет.

>В случае с lossless JXL они там весьма существенные.

Сказано же - НИКАКИЕ. Ни 50%, ни 99%, ни 99.9%. Толку мне от JXL, AVIF, WEBP, если в моём браузере они не открываются?

>>27607
Сказано было не никакие, а никакие несущественные, не ври.

>>27599
Если делать, чтобы плашка появлялась в форме, то как-то так?

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

>>27611
Как-то плашка посреди формы не очень смотрится, особенно когда большая. И моноширинный шрифт не нужен.
Наверное, лучше действительно исчезающую фитюльку где-нибудь сбоку показывать.

>>27612
При отправке можно просто заменять текст кнопки «Отправить» на «Отправка…», мне кажется. Или обработка, проверка и т.п.

Просто пришел сюда написать, что новый счетчик это офигительно удобно, оказывается, в наших медленнореалиях, сразу видно когда написали на не очень активную доску, сразу видно если где-то внезапный движ. Круто!

>>27604

> kusaba.js вообще не работает на браузерах старше где-то 2017-ого

Ну вот так как к нам ожидаемо заходят нѣкоторые господа даже с браузерами, в которых WebP ещё не открывается (>>27607), то слѣдовало замѣсто fetch использовать https://api.jquery.com/jQuery.ajax/ и тѣмъ тотчас же избавить себя заодно и от необходимости употребления как асинхронных функций, так и высокоуровневого ожидания (top-level await).

>>27606

> Соус говорит не заморачиваться

Господин Соусов в сообщении >>27599 высказался в том смысле, что если отвалится один только показ счётчиков, то тогда и пёс с ним, потому что счётчики — это украшательство, без которого можно прожить. Но я не думаю, что он приуготовил себя заодно и к отпадению работоспособности всего джаваскрипта на всём сайте за счёт того, что какой-нибудь старый браузер увидит непонятное ему словечко «async» или «await» и начнёт сходить с ума.

>>27604

> на что менять mutex?

Сейчас этот мьютэкс предотвращает каждой второй-третьей вкладке сайта (открытой параллельно с первою) возможность дѣлать чтó? — если одну только возможность пополлить JSON (как это вроде бы предполагает сообщение >>27588), то тогда, я думаю, мы можем просто-напросто понадѣяться на то, что сёрвер невозбранно переживёт кратный рост траффика во всѣхъ случаях отсутствия объекта «navigator.locks» на стороне клиента.

>>27619
В случае отсутствия объекта navigator.locks не будет за-scedule’н и очередной polling json’а. Таким образом, там, где такого объекта нет, обновление счётчиков наступит только по обновлению вкладки или по появлению у неё visibility. Наверное, стоит попробовать запилить-таки polling в отдельном файле-скрипте, который регистрировать как ServiceWorker, и который для всех вкладок вроде будет общий, тогда и необходимость изолировать polling до одной вкладки отпадёт.

> даже с браузерами, в которых WebP ещё не открывается
Ну, в Firefox’е async/await появился раньше поддержки WebP, а fetch появился на 4 года её раньше. Чтобы пользоваться fetch-ем, async/await не обязателен, но с async/await удобнее писать, а жалоб на сломавшееся что-то не было пока. Но объявился, похоже, пользователь Firefox 88. Попробую как-нибудь сделать polling в ServiceWorker-е, наверное.

>>27615
> Как-то плашка посреди формы не очень смотрится, особенно когда большая.
Вот что-то такое есть. В текущем примере, по крайней мере. Только, если делать фитюльку где-то с боку, как она должна выглядеть и где с боку её показывать? Я вот не очень представляю пока, хочу увидеть пример.

> При отправке можно просто заменять текст кнопки «Отправить» на «Отправка…»
Пожалуй.

Запилено:

• Promise chaining вместо async/await;
• Polling через SharedWorker там, где оно поддерживается: где не поддерживается — например, на мобильном Хроме — поведение polling-а, как сейчас на сайте;
• Счётчики больше не увеличиваются по отправке собственного поста;
• Если открыто несколько окон, содержимое счётчиков у них будет меняться одновременно.

>>27588-пост тогда игнорировать.

Изменения от текущего public-а.

>>27592

> Also, SauceNAO поддерживает WebP. Но не AVIF. Если кто-то решит найти источник запощенного с потерями, ему придётся искать, чем это дело перешакалить. Именно перешакалить, потому что lossless AVIF практически бесполезен. С другой стороны, обычно по имени файла и так понятно, откуда оно есть. Но Google-поиск тоже AVIF не понимает. Ну и ни на одну неFBEшную борду без перешакаливания AVIF с 410 не запостишь, наверное.

С одной стороны, здѣсь проблема в духе курицы и яйцá: кому-то нужно же сдѣлаться первыми, а не то эдак и разработчики https://saucenao.com/ могут сидѣть прямо сейчас и думать «ну зачѣмъ мы будем запускать поиск по AVIF, если поддержки этого формата ещё нѣтъ ни на одной имиджборде — поглядите, даже 410чан ею не обзавёлся». Такого рода рассуждения могут вѣчно ходить по одному и тому же порочному кругу. А чтобы разорвать его, ну почему бы и не нам сдѣлаться первыми.

С другой стороны, ну почему непремѣнно «перешакалить» придётся? — можно же декодировать из AVIF в PNG без внесения дополнительных потерь в изображение, а затѣмъ этот PNG скормить поисковой системе.

С третьей стороны, ну да, перепостить AVIF на другую борду — это проблема. Но и просто ≈пятимегабайтовый файл JPEG (напримѣръ, >>/b/207992) иногда никак нельзя перепостить на другую борду, причём даже если она позволяет постить файлы в формате JPEG — скажем, на борду https://iichan.hk/b/ не получится оттого, что она принимает до трёх мегабайтов. Но мы не закрыли лицо руками в непреоборимом отчаянии — и не отказалися от пятимегабайтовости. И это правильно. Так что и невозможность перепостить AVIF мы переживём.

С четвёртой стороны, ну да, гуглопоиск не принимает AVIF. Ну дык гуглоперевод даже и WebP не принимает (скриншот прилагаю). Но мы не закрыли лицо руками в непреоборимом отчаянии — и не отказалися от поддержки WebP. И это правильно. Так что и невозможность гуглообработки AVIF мы переживём.

Кто будет прикладывать AVIF к своему сообщению, тот ужé должен продѣлывать это с полным сознанием того, что картинка не будет видною в старых браузерах. По сравнению с этим дополнительные трудности перепощивания и визуальнаго поиска не так уж значительны.

>>27607

Пожалуйста, сообщите название браузера и номер его версии.

>>27620

> Ну, в Firefox’е async/await появился раньше поддержки WebP, а fetch появился на 4 года её раньше. Чтобы пользоваться fetch-ем, async/await не обязателен, но с async/await удобнее писать, а жалоб на сломавшееся что-то не было пока.

Да, это правда! — причём не только в Файерфоксе, но также и в Safari (трудностями в котором прежде оправдывалася задержка с внедрением того же WebP) мы видим асинхронные функции появившимися в 2017 году, а возможность fetch раньше них. Къ нынѣшнему времени браузеры должны быть новѣе тогдашних.

Я наивно думал, что проблемы могут возникать ещё и у таких пользователей, которые по техническим причинам (от непреоборимой привязанности къ нѣкоторому расширению Файерфокса) прекратили обновлять браузер опосля появления движка Firefox Quantum (произошедшаго в ноябре 2017 г., то есть как бы къ столѣтію россійской революціи), а вмѣсто того пересѣли на Pale Moon или ещё куда. К несчастью, такие пользователи ещё есть среди наших читателей и не раз с гордостью заявляли о себѣ в качестве способных год за годом обходиться без новинок браузера Mozilla Firefox. (Напримѣръ, https://410chan.org/b/arch/res/158687.html#159005 в 2021 году.)

Но теперь я возобновил в памяти информацию со страницы https://en.wikipedia.org/wiki/Firefox_version_history#Firefox_52_through_59 и ясно вижу, что за прошедшие годы я слегка подзабыл (как страшный сон), что Firefox Quantum — это версия 57, так что предшествующая версия (послѣдняя доквантумная) — это версия 56, а предшествующая ESR-версия (для поклонников обновлений безопасности) — это версия 52. Слѣдовательно, даже появление поддержки асинхронных функций в Firefox 52 не прошло мимо таких пользователей (хотя и едва-едва успѣло состояться одновременно с выходом очередной ESR-версии!), а уж тѣмъ болѣе появление нормального fetch в Firefox 40 мимо них не прошло.

Признавая свою неправоту, снимаю и прежние возражения против использования async и await и fetch. Дополнительно в явном виде выражаю сожаление насчёт того, что принудил резолвить промисы.

Появились ли какие-нибудь идеи по дизайну плашки?

Как вариант, можно в div, где сейчас topmenu писать.

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

Или в div над постформой, затирая replymode или нет.

>>27632
С формой быстрого ответа можно сделать что-то похожее, но тогда надо придумать, как ограничить ширину tr-а, если сообщение об ошибке длинное.

> ограничить ширину tr-а, если сообщение об ошибке длинное
А, через width:min-content.

>>27630
Так там какие-то проблемы есть с тем, чтобы просто прямоугольная фитюлька в углу (например, верхнем правом) выплывала, а потом уплывала обратно через несколько секунд? >>27631 бы тоже покатило, но мы в теории можем когда-нибудь сделать настраиваемую прилипчивость верхнего меню, а эта штука всегда должна быть видна.

В целом, можно не торопиться: работа, видимо, опять встала. Она шла бы быстрее, если бы вы осилили зарегистрироваться в репозитории, лол.

>>27635
Технически нет. Но хочется увидеть пример, чтобы понять внешний вид и её оптимальные размеры относительно остальных элементов.

Мои проблемы с фитюлькой в правом верхнем углу:

1. Ассоциация с please accept cookies, пусть такое обычно в левый нижний угол пихают. Topmenu-вариант больше похож на статусную строку, хотя статус обычно снизу;
2. Сообщение релевантное содержимому формы постинга может далековато от неё оказаться. Может понадобиться переводить взгляд с левого нижнего угла экрана, где форма быстрого ответа, на противоположный. Более проблематично на большом мониторе. У topmenu-решения та же проблема, но оно во всю ширь экрана/браузера, сразу не заметить сложнее;
3. У нас сейчас документ идёт строка за строкой, кроме когда пользователь решает перетащить форму постинга, и кроме div-а с избранными нитями (Которым кто-то пользуется?). Теряется alignment.

> но мы в теории можем когда-нибудь сделать настраиваемую прилипчивость верхнего меню, а эта штука всегда должна быть видна
Проблем нет совместить, если потом когда-нибудь делать.

BTW, вариант для быстрого ответа, как на картинке, точно совсем не подходит?

>>27636
Уведомления в интерфейсах обычно вылазят поверх содержимого, а не встраиваются в него, меняя размеры объектов. Тем более, что внутри нитей содержимое форм дублируется, и нет никакого смысла к конкретной форме что-то прилеплять.
>Ассоциация с please accept cookies, пусть такое обычно в левый нижний угол пихают.
Эти штуки и во всю ширину бывают. В любом случае, с ними пользователь должен взаимодействовать, а наше уведомление должно само появляться и пропадать через некоторое время (впрочем, кнопку закрытия можно и приделать).

>>27674
Раз >>27631-версия подходит, сделаю её тогда. Скорее всего, patch будет где-то в конце августа.

> внутри нитей содержимое форм дублируется
Кажется, там дублируется только содержимое input-ов и textarea.
> кнопку закрытия можно и приделать
OK.

Запилено >>27631 в ≈>>27593 виде. Можно тестировать. Стилеспецифичный CSS statusbar'а только для Умночана написан.

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

>>27592

> Но Google-поиск тоже AVIF не понимает.

С прошлой пятницы (30 августа) начал понимать: https://developers.google.com/search/blog/2024/08/happy-avifriday

(Скриншот прилагаю.)

В lib/javascript/kusaba.js на 573-ей заменить

fetch('/board.php?' + board + "&fetch-call=1", {

На

fetch('/board.php?' + e.target.form.elements.board.value + "&fetch-call=1", {

Sorry.

>>27731
К чему это хоть?

>>27732
К >>27697.

>>27569

> даже пулреквеста в репозитории нет, чтобы по-быстрому можно было накатить.

Теперь есть: https://codeberg.org/FBE410/fbe-410/pulls/38

Дополнительно предупреждаю ещё, что перед накатыванием пуллреквеста >>27746 неплохо бы провѣрить ещё разок, была ли собрана новая версия PHP (по умолчанию) таким образом, чтобы у ней в GD работали функции imagecreatefromavif и imageavif.

А не то, мало ли, вдруг окажется, что как раз на поддержке AVIF и сэкономили. И тогда упсъ.

Документация по адресу https://www.php.net/manual/en/image.installation.php говорит нам, что для того потребным оказывается параметр «--with-avif» при конфигурировании сборки PHP.

Словосочетание «по умолчанию» в сообщении >>27749 означало, что я считаю (предположительно) версию PHP на сёрвере поставленною из такого готового пакета, при сборке которого параметр поддержки AVIF был уж включённым, если сборщики пакета знали своё дѣло.

Что ж, давайте вернёмся к отказу от фрейма по умолчанию, и подумаем, что можно засунуть на главную кроме новостей (кстати, с ними связана задача https://codeberg.org/FBE410/fbe-410/issues/14 ) и списка досок.
Какие-то избранные картинки по типу соседнего сайта у нас, как мне кажется, не покатят по очевидным причинам. Что там ещё может быть? Наша скорбная статистика активности?

>>27753
Избранные посты, например, свежее из Онгоинг-треда? Рекомендованные нити, как-то недавнее Тестирование микрофона, Витрина Супермаркета, Унтара-кантара или нити Общих вопросов? "Этот день в чаносфере" со ссылкой на Нубтайп-вики? Цитаты?

Наверное не стоит забывать и про кнопку "Оплатить проезд"

>>27754
Это та же лабуда, что и избранные картинки. У нас на сайте не так много контента и активности, чтобы такое делать.
Была ещё старая идея мутить что-то ко дням рождения анимешных персонажей, которую можно было бы использовать тут, но тоже как-то сомнительно.

>>27756
>У нас на сайте не так много контента и активности, чтобы такое делать.
Вот кстати, у нас может быть не очень много контента и активности сейчас, но достаточно контента в архиве. Может было бы интересно в доступной форме, без необходимости вручную ходить по файлам, показывать что-то из архивных нитей? Технически очень даже реализуемо.

И еще, а насколько фантастично разместить на главной что-нибудь интерактивное, например какую-нибудь не очень сложную, но вовлекающую в сообщество коллективную игру для пассажиров?

Что-нибудь относительно простое, хтмлное, но веселое и главное в близкой тематике? Можно даже какой-то отложенный мультиплеер, где один ход делает любой пассажир, а один ход - кто-то из Супермаркета. Слишком круто для нас?

Возможно даже что-то во что можно играть через постинг в специальную нить, и на главной отображать собственно состояние игрового поля, относительно результатов парсинга этой нити

Соусу по поводу https://codeberg.org/FBE410/fbe-410/issues/33#issuecomment-2370914: будет, но чуть позже. Жив, но сейчас неотложные дела, не имеют даже возможности войти в аккаунт на codeberg.

И этот issue не про документацию, а про переписывание всего движка на использование escape_sql и другие задачи. О таком issue просил Якуй (подробности и ссылки см. в тексте issue).

>>27757
Я вообще хотел бы что-то простое и автоматическое. Поэтому и предложил статистику. Главная — не то, чтобы сильно нужная страница на чане, на неё мало кто ходит из завсегдатаев, и удерживать на ней новых людей тоже смысла нет, чтобы там интерактивы мутить какие-то.

>>27759
Ок. Удачи с делами. Документация нужна для того, чтобы другие разработчики понимали, что происходит.

>>27760
Так а как тогда насчет ОП-поста случайной нити из архива на главной, с указанием даты и ссылкой на архив? Слишком скучно?

Это мне кажется, и автоматизируется, и не должно быть слишком тяжело, хотя конечно придется HTML кусать на стороне сервера.

>>27761
Во-первых, действительно надо ХТМЛ дёргать, что не очень. Во-вторых, а зачем? В архивах всякое от балды лежит, а не избранная коллекция, лол.

>>27756
>Была ещё старая идея мутить что-то ко дням рождения анимешных персонажей, которую можно было бы использовать тут, но тоже как-то сомнительно.

А что если сделать это с небольшим твистом?
1. Добавляем массив персонажей с их днями рождения
2. Пишем скрипт, который от текущей даты находит ближайший день рождения
3. Выводим где-нибудь на главной обратный отсчет "До Дня Рождения Юи Хирасавы 2 дня 11 часов 59 минут 10 секунд", с портретом
4. В день рождения выводим короткое поздравление и приглашаем пассажиров отпраздновать в /a/ или /ts/, в зависимости
5. Если дни рождения совпадают, или через день, можно даже устраивать мультименины

Вроде бы и просто, и не совсем пресно.

>>27763
Я думал просто нарисовать картинки и вывешивать где-нибудь на день.
Но во-первых, я сделаю подборку на своих предпочтениях, и кто-то будет недоволен, что его любимых персонажей не поставили, лол. Хотя даже по своей подборке я не вполне уверен, какие лучше критерии использовать.
Во-вторых, какие-то отсчёты и нарочитый интерактив в этой затее не нужны, мне кажется. Даты могут подряд идти, а отмечать не факт, что кто-то будет (как на соседнем сайте всем плевать на смену имён).

>>27764
Моя имха, по собственному экспириенсу. У меня вот, что на Ычан, что на Автобус, что на некоторых других форумах, стоят закладки и они ведут не на главную, а сразу в часто посещаемый и любимый раздел. Что там на главной, я годами не вижу. А вот новые посетители, скорее всего, зайдут на главную, если не из поиска в гугле по конкретной теме. Потому, мне кажется, там должна быть ещё инфа актуальная и полезная для новичков.

>>27765
Информация там есть уже. Даже ссылка на вики, лол.

>>27764
>кто-то будет недоволен, что его любимых персонажей не поставили
>я не вполне уверен, какие лучше критерии использовать
А если открыть реквесты на пиксиве, и вдобавок к своим картинкам, за пожертвования в Супермаркет рисовать картинки с любимыми персонажами пассажиров?

Ну и раз уж зашел разговор про пожертвования, может попробовать устанавливать какую-то прогрессирующую цель сбора (уровень 1 - продление доменов, уровень 2 - хостинг, уровень 3 - связь, уровень 4 - файлы 10 Мб), и затем на главной показывать прогрессбар?

Или это все не в нашем духе?

>>27767
>и вдобавок к своим картинкам, за пожертвования в Супермаркет рисовать картинки с любимыми персонажами пассажиров
Это уже коммерческие заказы какие-то, я не готов таким заниматься.
>может попробовать устанавливать какую-то прогрессирующую цель сбора
Я думал сделать полоску с максимальной на данный момент суммой (за 2018 год, кажется), но когда я изучал этот вопрос, там по-простому нельзя было сделать, и я пока забил.
Но это для Соус.нета всё, зачем оно тут? Тут ссылки бы хватило.

>>27769
Кажется, пока идеи у меня закончились ._.

https://sushigirl.us/
Как тебе сушичановская главная, Соус?

>>27773
Просто список досок, из которого вообще непонятно, что за сайт? Не очень, если честно.

>>27774
>вообще непонятно, что за сайт
Ну почему вообще, сразу понятно что виабу!

По поводу главной, кроме уже сказанного, пока ничего предложить не могу, но есть пара предложений по улучшению механизма отправки.

1. Вместо Отправка... выводить Отправка... 34%, то бишь выводить прогресс;
2. Сделать предварительную проверку на клиенте длины поста и прочего, что не требует пересылки всего сообщения. Проверяем пост на соответствие сохранённому в local storage boards.json или boardname/settings.json. Если соответствует, отправляем на сервер. Если не соответствует, на всякий случай скачиваем свежий boards.json, проверяем, и если и свежему boards.json пост не соответствует, выводим ошибку. Если соответствует, отправляем на сервер.

Соус, а как тебе идея на главную ретранслировать свой твиттер, чтобы люди без аккаунта были в курсе происходящих вещей без регистрации и смс?

>>27778
Чтобы люди были в курсе всех Fgsfds’ов, надо устроить бложик админа на главной, лол.

У меня сайт >>27773 просто-напросто отказывается открываться.

>>27595
>доколе она будет считатся в байтах, а не в символах
Завёл задачу: https://codeberg.org/FBE410/fbe-410/issues/41

Счётчик, наверное, навроде такого.

И ещё задача на чистку кода от ненужной лабуды для старого кусабовского сайта.
https://codeberg.org/FBE410/fbe-410/issues/43

>>27801

Отпилил.

Реквестирую https://codeberg.org/FBE410/fbe-410/pulls/45 на основании >>/d/3128.

Новая задача: https://codeberg.org/FBE410/fbe-410/issues/47
Засовывание темы или номера нити в заголовок страницы для удобства работы с вкладками.

Ещё есть мысль провести ревизию разметки для кода.
Текущий тег оставить для чистого моноширинного текста (без переносов строки) и добавить какой-нибудь [code][/code] с подсветкой синтаксиса как в /g/ «4чана». Насколько сложно это провернуть?

>>27811
> (без переносов строки)
Одну-две строчки в parse.class.php поменять.
> добавить какой-нибудь [code][/code] с подсветкой синтаксиса как в /g/ «4чана»
Dunno.

https://codeberg.org/FBE410/fbe-410/issues/48
Скрытие нитей через каталог. А то на «Ычане» есть, а у нас нет.

Думаю ещё над заменой индикатора сажи. Чтобы вместо сомнительно выглядящего засовывания стрелки в тему прикреплять к сообщению значок в формате СВГ. С другой стороны, а нужен ли вообще индикатор сажи? А то из возможности просто не поднимать нить (по любым причинам) получается какой-то эрзац-дислайк.

Немного менѣе 4⅚ года назад (то есть в феврале 2020 г.) мы разсмотрѣли по адресу https://410chan.org/dev/arch/res/20450.html#24001 вопрос о том, полезно ли использовать появившийся тогда в Mozilla Firefox (а до того и в Google Chrome) механизм, позволявший подзадержать полную загрузку страницы для экономии траффика, а именно откладывать момент начала скачивания миниатюр (thumbnails) до прокрутки страницы к ним.

Тогда эта идея была отвергнута в интересах пассажиров метро (и вообще всѣхъ пользователей нестабильнаго Интернета, желающих сперва скачать страницу цѣликомъ, а затѣмъ читать её со всѣми миниатюрами в вынужденном оффлайне).

Сейчас предлагаю разсмотрѣть болѣе новый, но также ужé изрядно давно существующий механизм обмѣна в диаметрально противоположном направлении (то есть такой механизм, которым обмѣнивается не скорость на траффик, а как раз наоборот — траффик на скорость), который позволяет немного ускорить загрузку страниц за счёт того, что начинать их предзагрузку ещё до перехода по гиперссылкам, то есть не тогда, когда гиперссылка окажется жмякнутою, а чуть раньше — когда палец надавил на гиперссылку (но ещё не отпустил её) на сенсорном экране, или когда кнопка мыши ужé нажата (но ещё не отпущена) на гиперссылке, или когда мышь была наведена на гиперссылку на 200 миллисекунд (или дольше), но в каждом из этих случаев рост наблюдаемой скорости открытия страниц (за счёт предзагрузки их) обмѣнивается на дополнительный расход траффика в том смысле, что сёрвер ужé отдал страницу, а пользователь мог и передумать на неё заходить (и тогда траффик был израсходован зря) в трёх частных случаях:

➊ Пользователь мог жмякнуть пальцем по гиперссылке не для перехода по ней (краткое нажатие), а для вызова контекстного меню (долгое нажатие), но это не извѣстно тогда, когда он ещё только надавил пальцем.

➋ Пользователь мог жмякнуть мышóю по гиперссылке не для перехода по ней (краткое нажатие), а намѣреваясь drag-and-droпнуть гиперссылку, но это не извѣстно тогда, когда он ещё только надавил пальцем на кнопку.

➌ Пользователь мог задержать указатель мыши на гиперссылке для предпросмотра (410чан показывает сообщение при наведении на гиперссылку) без намерения перейти по гиперссылке, чтобы открыть всю страницу. А зачѣмъ ему открыть всю страницу? — ну, напримѣръ, чтобы открыть спойлеры (при предпросмотре не видные), или чтобы погрузиться в контекст обмѣна репликами вокруг сообщения, им увиденного.

Этот механизм называется Speculation Rules API и существует единственно во хромоподобных браузерах (то есть в Google Chrome, в Microsoft Edge, в Opera и проч.). На сайте «Can I use…» пишут, что механизм этот начал появляться с августа 2022 года, а свою теперешнюю форму (с необязательностью параметра «source») приобрёл с конца февраля нынѣшняго (2024) года, так что её поддержка достигла уровня 70,12% от общего числа браузеров теперича.

(По адресу https://caniuse.com/mdn-html_elements_script_type_speculationrules можно посмотрѣть на первую из этих двух дат, а по адресу https://caniuse.com/mdn-html_elements_script_type_speculationrules_source_optional на вторую.)

Конкретно можно было бы для начала добавить на каждую страницу такой скрипт:

<script type=speculationrules>
{ "prerender": [
   {
      "eagerness": "conservative",
      "where": { "href_matches": "/:board/res/(\\d+).html#(i?\\d+)" }
   },
   {
      "eagerness": "moderate",
      "where": {
         "and": [
            { "href_matches": "/:board/res/(\\d+([+-]\\d+)?).html" },
            { "not": { "href_matches": "/:board/res/(\\d+).html#(i?\\d+)" } }
         ]
      }
   }
] }
</script>

Гиперссылки для дальнѣйшаго чтенія про эту фичу прилагаю:

① Общий обзор: https://developer.chrome.com/docs/web-platform/prerender-pages

② Обзор записи правил: https://developer.chrome.com/blog/speculation-rules-improvements

③ Документация по API: https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API

④ Документация по записи скрипта: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/speculationrules

⑤ Документация по записи шаблона URL-адресов: https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API

>>27820
Мало того, что оно не во всех движках, так ещё и трафик жрёт? Я думаю, это отказ.

Чувствую неопредѣлённость.

Раньше у нас не было поддержки AVIF во браузерах — теперь она у нас есть во всѣхъ новых версиях всѣхъ сколько-нибудь популярных браузеров вот ужé дольше десятка мѣсяцевъ.

Раньше у нас не было поддержки AVIF в PHP — теперь она у нас есть.

Раньше у нас не было поддержки AVIF гуглолинзою поиска по картинкам в Интернете — теперь она у нас есть.

Раньше у нас не было пуллреквеста с готовым кодом для поддержки AVIF в FBE — теперь он у нас есть.

Поэтому думаю: да есть ли нѣкоторое опредѣлённое препятствие, которым ещё сдерживается обеспéчение возможности выкладывать AVIF на 410чан (но тогда почему для поддержки WebP такого препятствия вроде б не было), или есть только неопредѣлённое чувство недостаточности спроса («ну очень не хочется наливать воду в сухой бассейн, потому что год за годом видно, что в нём никто не торопится прыгать с вышки», «ну очень не хочется строить мост через крупную рѣчку въ этомъ мѣстѣ, потому что меньше десятка автомашин в год пытаются попасть вброд на тот берег именно здѣсь» и проч.)?

>>27817
Видимо, всем плевать на индикатор сажи.

Поотвечать/запиливать пока руки не доходят.

>>27817
Почему бы и да. Надо будет сделать отдельный столбец в posts_$boardname.

> получается какой-то эрзац-дислайк.
А мы точно хотим лишить людей уже, наверное, традиционной возможности выразить своё недовольство таким образом? Но чисто лично я не сильно против отмены индикатора, хотя на наших скоростях сажу всё равно можно будет иногда, а то и чаще, заметить, и посчитать downvote-ом.

Закончилася поддержка Theora во браузерах: https://caniuse.com/ogv

Не отпилить ли её и здѣсь?

Думаю в качестве значка сажи использовать шалфей, лол. Пока как-то так.

>>27829
Можно. Я так понимаю, с точки зрения расширения «Ѳеора» = ОГВ, и нам уже сейчас следует убрать его из разрешённых к загрузке?

>>27831

Да.

Ужé послѣ того, как загрузка перестанет быть разрѣшённою, можно будет и из кода FBE выкинуть строчку специальной обработки таких загрузок («if( $expectedFormat === 'ogv' ) $expectedFormat = 'ogg';»).

>>27831
Как-то с шалфеем вы меня потеряли, в чем суть?

>>27833
Sage (сажа) — не только мудрец, но и растение.
https://www.nccih.nih.gov/health/sage

>>27833
А ведь обо всём написано здесь:
https://noobtype.ru/wiki/Sage

>>27836
Читайте и тщательно конспектируйте Нубтайп...

Завёл задачу про значок сажи:
https://codeberg.org/FBE410/fbe-410/issues/51

Файл приложен сюда, но следует преобразовать его, как описано здесь: https://codeberg.org/FBE410/fbe-410/src/branch/public/icons

На мобилке, может, вернуть старый размер шрифта для topmenu? У меня не влезает и не красиво. A52.

>>27842
Скукожили обратно.

>>27842
Алсо, смотрю я на этот скрин с формой постинга на весь экран, и думается, а не стоит ли нам сделать сворачивание формы создания нити как на «4чане»?