>>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чане»?

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

>>27851
Но верхнюю нить (начало её) и так сразу видно.
>>27847
Не на весь.

>>27852
Да всё равно, на пол-экрана форма что на мобилках, что на ПК.

>>27543

> Давайте обсудим, как эта лабуда должна себя вести.

Предлагаю, окромя счётчиков слѣва (у букв досок), помѣстить ещё один счётик справа (у кнопки «Главная»), который бы показывал наличие новостей на главной, а то они ж теперь нифигушеньки не появляются сообщениями на доске d/ (потому что >>/d/3126).

В общем, добавил задачу на сворачивание формы постинга: https://codeberg.org/FBE410/fbe-410/issues/54

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

Год.

Цѣлый год каждая новая версия каждого сколько-нибудь популярнаго web-браузера выходит с поддержкою AVIF, но 410чан остаётся без оной.

>>27793
>>27794
Сделано. Счётчик отображается, если набранное наполовину подобралось к ограничению по длине. При превышении ограничения, кнопка отправить не disable'ится, но по клику на неё показывается сообщение о превышении без его отправки на сервер. Стилеспецифичный CSS не делал.

Побочка. Надо будет перегенерировать страницы. Поскольку максимальная длина для скрипта передаётся ему через template, их надо будет перегенерировать при любом её изменении в настройках доски. Так что по-хорошему это надо бы не в template-ы, а во что-то наподобие https://a.4cdn.org/boards.json, которое перед отправкой сообщения читать и проверять его длину и другие параметры на соответствие.

Но такой JSON, наверное, потом вместе с улучшением фоновой проверки в целом стоит запилить. Запилив, скажем >>27485. Ещё, сейчас отправка идёт через fetch, но если сделать через XMLHttpRequest, можно будет вместо Отправка... отображать Отправлено 78%.

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

>>27873
Судя по всему, не работает и продолжает проверять размер в байтах.

>>27875
Странно, УМВР. Новый posting.class.php точно был скопирован?

Аа, вижу. На 122-ой там забыл strlen на mb_strlen поменять.
> exitWithErrorPage(sprintf(_gettext('Sorry, your message is too long. Message length: %d, maximum allowed length: %d'), mb_strlen($_POST['message']), $board_class->board_messagelength));
Но всё равно странно. До exitWithErrorPage оно не должно было дойти: условие в if-е верное.

Судя по всему, проблема в том, что internal_encoding у PHP на сервере, где производилась проверка, стоит не UTF-8.

Стало быть, проблема решается либо редактированием php.ini и перезапуском Apache, либо указанием для mb_stlen кодировки: заменить mb_strlen($_POST['message']) в posting.class.php/CheckMessageLength() на mb_strlen($_POST['message'], 'UTF-8').

С этим posting.class.php сейчас должно работать, но по-хорошему стоит посмотреть, что в настройках сервера.

>>27883
Да, это работает, но, судя по всему, оно включает имя файла в длину сообщения.

Так как идея https://codeberg.org/FBE410/fbe-410/issues/41 состояла в том, чтобы сосчитать сѵмволы (а не двухбайтовики UTF-16), то свойство «.length» в джаваскрипте не годится в диапазоне U+010000…U+10FFFF (то есть для многих эмоджи — напримѣръ, сѵмволъ «🕸️» состоит из кодов U+1F578 и U+FE0F), а считать придётся как-нибудь так:

const countCharacters = textStr => {
   var strLen = textStr.length;
   if( strLen < 1 ) return 0;

   var total = 0;
   var curr = 0;
   var code;
   while( curr < strLen ){
      code = textStr.codePointAt(curr);
      if( typeof code == 'number' ){
         total++;

         if( code < 0x10000 ){ // Basic Multilingual Plane
            curr++;
         } else curr += 2; // UTF-16 surrogate pair
      } else return total;
   }
   return total;
};

>>27890
Спасибо, исправил.
> cостоит из кодов U+1F578 и U+FE0F
Но разве для кодирования '🕸' не достаточно одного UTF-16 символа, пусть и из двух юнитов?
https://www.compart.com/en/unicode/U+1F578

Также учёл конвертацию "\n" в "\n\r" браузером при отправке.

Видимо, действительно не достаточно: в >>27891 паутинка отображается только на десктопе, а в >>27890 и на мобилке, тоже.

>>27891

> Также учёл конвертацию «\n» в «\n\r» браузером при отправке.

Лучше всего было бы не наращивать счётчик на 2 при каждом переводе строки, а замѣнять «\r\n» на сёрверной стороне единичным «\n» перед подсчётом числа сѵмволовъ.

Основание этой мысли вижу в том, что формат «\r\n» свойственен системе Windows, тогда как пользователи системы macOS или Linux (а также Android, FreeBSD и проч.) ничѣмъ двухсѵмвольную оцѣнку перевода строки не заслужили — но тогда и пользователей системы Windows проще перетащить на тот же уровень во имя единообразия.