>>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, вариант для быстрого ответа, как на картинке, точно совсем не подходит?