Ычан: [d | au / b / bro / hr / l / m / mu / o / s / tran / tu / tv / vg / x | a / aa / c / fi / jp / rm / tan / to / vn]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить
Имя
Animapcha image [@] [?]
Тема   ( ответ в 26066)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, WEBP, XCF, ZIP размером до 5120 кБ.
  • Ныне 3652 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 500
410.png - (24.25KB, 500×500)
26066
No. 26066  
В сей нити мы упорядочиваем усилия по доработке местного движка.

Репозиторий: https://codeberg.org/FBE410/fbe-410
1. Для ваших предложений предназначена ветка public.
2. Только администрация 410чана решает, что в этом движке надо, а что не надо. Соответственно, не стоит излишне пропихивать всякие там революционные идеи. Одобренные потенциальные изменения перечислены на багтрекере (записи, созданные владельцами репозитория).
3. Тестирование предложенных изменений и развёртывание принятых ведётся при наличии у администрации свободного времени на это. Обычно это делается по выходным.
4. Код выложен как есть. Никаких неопубликованных скрытых функций и частей не существует.

Предыдущая нить: >>20450
No. 26067  
OP2-Uiharu.png - (1.06MB, 1280×720)
26067
Ранее упомянутый пользователями баг с локалью, наконец, настиг и этот сайт.
Кто исправит, тот молодец.
No. 26069  
164559916536.jpg - (794.45KB, 858×1200)
26069
>>26067
Проверьте, стоит ли php-gettext.
Если стоит, отредактируйте lib/gettext/gettext.php: >>25130.
No. 26070  
84192411_p10.jpg - (311.17KB, 900×1200)
26070
А, и если в /b/ с локалью всё нормально, а тут нет, то верные ли значения локалей досок указаны в БД?
No. 26071  
По ѿклику >>/d/2753 нетрудно догадываться (и догадываюсь), что 410чан ѿъѣхалъ на другой сёрверъ.

Это была одна только эвакуация из-под санкций или смѣна тарифа для роста хранилища под архив сообщений? — или при этом заодно появилися и новые возможности для разработки: новая версия PHP, новая версия ImageMagick, etc.?
No. 26073  
>>26071
Переезд на другой сервер никак не влияет на версии пакетов в операционной системе.
No. 26075  
> The uploaded file exceeds the upload_max_filesize directive (2M) in php.ini.
Исправьте, пожалуйста.
No. 26076  
>>26075
Вроде бы да.
No. 26078  
Проблемы >>26075 больше нѣтъ, спасибо.
No. 26098  
Въ подраздѣлѣ уведомлений >>/d/1816 послѣднее сообщение >>/d/2377 доводит до свѣдѣнія пользователей то обстоятельство, что анимированные WebP к моменту появления этого сообщения (в ноябре 2020 года) ещё не поддерживалися.

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

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

18
24
34
41

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

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

Но и не хѣръ бы с ним? — разве что-либо мѣшаетъ уважаемой администрации самостоятельно накатить этот патч его?
No. 26185  
1653275855429.png - (247.47KB, 829×1200)
26185
На мобилке в мобильной «лисе» поменялись шрифты на всех досках. Был serif, стал sans serif.
Так и задумано?
No. 26187  
Ещё, шрифт для темы нити стал сильно больше по размеру и почти сопоставим по нему со шрифтом названия доски.
No. 26188  
>>26185
Да.

>>26187
Это наоборот у названия доски появилась жирность.
No. 26189  
Собираюсь запилить борду на этом движке.
Какие подкаменные воды?
No. 26190  
>>26188
> Это наоборот у названия доски появилась жирность.
Я просто смотрю соседний сайт, который не обновлялся, и там шрифты для тем нитей по-прежнему маленькие и аккуратные.
No. 26191  
1649546290251.jpg - (227.35KB, 1200×887)
26191
>>26189
Нужна либо эрудиция по LAMP, либо опыт накатывания кусабаподобных движков.
Нужны php-mysql, php-gd, php-gettext, imagemagick и ffmpeg.
Важны опыт админивания Кусабы и умение разбираться в чужом коде; все мануалы мертвы, ссылку после “File” и зачем она нужна будете искать самостоятельно.
Может понадобиться не самый-самый новый PHP: какие-то проблемы с тем, что deprecated лабуду, которой в движке по крайней мере было полно, из того нового PHP таки выпилили.
Ещё была какая-то >>22323 проблема с путями. Исправили или нет, не знаю.
Ещё, >>22332.
No. 26192  
>>26189
Движок разрабатывается исключительно в интересах этого сайта, поэтому вам никто не будет тут помогать с техподдержкой и реализовывать ваши хотелки по функциям. Использовать никто не запрещает, но я бы советовал любой другой популярный движок типа «TinyIB» (у небезызвестного Степана со скриптами есть свой форк https://github.com/SthephanShinkufag/TinyIB , например).
No. 26232  
Только что нашёл баг в Авто/б/усе: если сделать в треде один пост с сажей, а потом ещё новый пост с сажей, и тот новый пост с сажей удалить, то тред будет бампнут так, как если бы тот первый пост с сажей не был с ней.
Вангую, какие-то неполадки в защите от stealth bump-ов.
No. 26279  
screenshot.webp - (67.40KB, 950×1118)
26279
Не пройдёт и двух лѣтъ, как условие >>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чанѣ не ждите: её никоим образом не будет!
No. 26287  
(с момента создания нити)
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/ показ полного содержания ОП-постов в каталоге через скрипты

Старые задачи тоже висят.
No. 26542  
>>26287
>47
>показ полного содержания ОП-постов в каталоге через скрипты
На первый взгляд, неплохо справляется уже существующая функция предпросмотра >>ссылок в нитях, достаточно дать соответствующий класс элементу <a> внутри элемента .cataloglist чтобы было типа:
><div class="cataloglist">
>...
><a href="/dev/res/26066.html" class="ref|dev|26066|26066">
И можно невозбранно смотреть ОП-посты прямо из каталога.
Это требует минимальной модификации существующего кода (собственно, вывести этот класс при генерации элементов каталога), вопрос только - подходит ли нам такое поведение и внешний вид, или нет?
No. 26543  
>>26542
Это и подразумевается.
No. 26545  
>>26543
Ок, наверное самая легкая задача из списка тогда.
No. 26646  
В хромоподелиях сломался быстрый ответ. Может кто по-быстрому посмотреть, что там за лабуда или мне задачу на трекере заводить?
No. 26648  
>>26646
УМВР с мака.
No. 26653  
>>26646
Раз сначала работало, а потом сломалось и никто туда не лазил, надо выяснить, какие компоненты механизма быстрого ответа имеют ограниченный ресурс. Может переменные износились, или отверстия для аргументов в функциях засорились.
З.Ы.: Edge Win7 x64 - работает.
No. 26654  
>>26653
У вас точно последняя версия этого браузера? Потому что в нём точно не работает ничерта с последним обновлением, хотя на прошлой неделе работало.
Очевидно, что хромичи у себя что-то сломали.
No. 26656  
Clipboard08.png - (239.15KB, 1440×900)
26656
>>26654
Действительно.
No. 26661  
166284091669.png - (242.27KB, 1440×900)
26661
>>26656
Откуда прозрачности взялись?
No. 26664  
bus_interior.jpg - (80.18KB, 930×620)
26664
>>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, получается.
No. 26665  
Интересно еще, поможет ли вместо >>26664 просто обновить jQuery?
No. 26667  
9074835067_78dacc9f9d.jpg - (68.18KB, 500×281)
26667
>>26661
Новая машина, новая винда — ничего не настроено. Думаешь, перезжать так просто?

>>26664
Мораль сей сказки в том, что нефиг юзать экспериментальные фичи CSS когда Господь дал тебе портабельное Жуквери.
>Выглядит это так будто в новом билде вебкита просто что-то сломали, если честно.
Или же привели в соответствие со стандартом, что больше похоже на правду. По крайней мере в XHTML по другому и не напишешь. И я не стану удивляться, если какого-то существенного значения в мировом масштабе это иметь не будет.
>Или же :has() от нашей версии jQuery в нем работает уже не так хорошо, как раньше.
Жукверя не занимается CSS-селекторами.
>Селекторы износились, или jQuery, получается.
Экспериментальные фичи. Добро пожаловаться в удивительный мир уеб-макакинга. К сожалению, автор сего квикреплюя был слишком юн, самоуверен и верил в людей.
No. 26669  
То ли дело вы, в познании настолько преисполнились что уже и отреклись от бренности любых реализаций, только несете луч чистого знания методом постинга кошкодевочек. Кисленько как-то.
No. 26670  
>>26669
Меня с моими престопроблемами уже послали в сторону, обратную серверу, вылив ушат желчи за то, что я не знаю фич последнего стандарта JS и вообще не моден, не ношу бороду и кеды. Так что я тут только с позиции консультанта мебельного магазина предлагаю следующие товары:
— стул «переписать так, чтобы работало на Престо»: тяжёлый и громоздкий, но работает с любой задницей;
— стул «засунуть параметры в кавычки»: легкий и компактный, но может внезапно развалиться, плюс требует проведения исследовательской работы по выяснению совместимости с задницами разных видов.
No. 26672  
Произошедшее порождается, насколько я понимаю, тѣмъ обстоятельством, что прежде работа 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="циферки"]» повсюду.
No. 26673  
>>26667

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

И именно поэтому использует и содержит https://github.com/jquery/sizzle/ в своём составе, ага-ага, понятно-понятно.
No. 26674  
Столько нафлудили и ни одного пулл-реквеста.
No. 26675  
>>26670
>послали в сторону, обратную серверу,
Не знал, сожалею что так вышло.
No. 26676  
natsume_bus.png - (0.95MB, 721×721)
26676
>>26674
Я думал Соус хочет сам патч ASAP вкрутить, и ему нужен рецепт. Делать пулреквест?
No. 26677  
>>26676
Делайте, конечно.
Вопрос был в том, надо ли задачу (надолго) заводить, или кто-то сейчас есть.
А теперь один хѣръ придётся ждать до следующих выходных.
No. 26678  
>>26677
Жаль что не получилось самостоятельно вкрутить по инструкциям, конечно.
No. 26679  
Вообще, прекрасная иллюстрация того, почему мы так консервативны со скриптовыми свистоперделками.
No. 26680  
>>26679
Только оказалось все же, что виноваты Хромичи, и консервативней им надо быть с билдами. Они там что-то действительно напороли в интерпретации :has()

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

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

Вобщем я хоть и внес все костыли в пулреквест, но теперь кажется что Хромичи могут просто исправиться в следующем билде, и костыли будут не нужны.
No. 26681  
Смочь бы ещё найти что-то на их 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
No. 26682  
>>26681
Вроде и хочется сказать, что да, это их конфликт с jQuery, но с другой стороны - такое странное и непоследовательное поведение испытваем, что не знаю даже.
No. 26683  
Пока выглядит, что полной картины бедствия еще нет.
Пройдя по ссылке с гитхаба, увидел что ребята из jQuery тоже обнаружили что вещи перестали работать внутри :has()
https://github.com/jquery/jquery/issues/5098
но не нашли все.

Если верить гитхабу, jQuery сначала пытается достать элемент штатными средствами браузера, и если браузер выдает на это ошибку - jQuery достает своими средствами. Хромичи из :has() ошибок не выдают, они возвращают пустой массив, jQuery считает что селектор сработал штатно и все хорошо.
No. 26684  
Как бы то ни было, пулреквест у нас уже есть.
No. 26685  
>>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 упоминавшимся.
No. 26686  
>>26680

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

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

Им о нём кто-нибудь сообщил?
No. 26687  
>>26686
Пока не видел, так что вы можете быть первым!
No. 26688  
Завёл там несколько новых задач в связи с.
No. 26690  
>>26688
Можно наделать несколько сменяемых наборов фапчи и ограничение на число прокликиваний - тогда злоумышленнику придется долго и мучительно возиться с расшифровкой (и даже просто выкачиванием) каждого набора.

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

А вообще, судя по нападению на новерь, его прокси можно быстро перебанить и руками
No. 26691  
>>26690
> ударит по пользователям
Можно сделать по несколько разных изображений на одного персонажа, тогда при их смене здоровые люди не будут страдать, но будет страдать бот.
No. 26692  
>>26690
>>26691
Удваиваю, идея с организацией картинок в фапче в формате набора нескольких подменных, не отдаваемых всегда в общем наборе картинок по персонажу звучит очень неплохо. Менять можно индивидуально, если какая-то картинка слишком затребована, а можно и полностью, по критериям постинга, или создания новых фапча-сессий.
No. 26693  
Фапча — это способ защиты от тѣхъ ботов, которые желали бы массово наспамить по нѣсколькимъ имиджбордам (массово не получится, потому что фапча 410чана индивидуальна) и способ защиты от людей, внѣшнихъ по отношению к анимешному сообществу («пробовал, но не угадал ни одной фапчи»).

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

Болѣе разумным инструментом антивайпа может служить, скажем, жёсткий запрет на создание болѣе пяти ѳрэдовъ в течение пяти часов, запрет на создание N сообщений в течение часа (величина N может и должна быть подобрана таким образом, чтобы в разы превосходить темпы реального постинга, но не затруднять администратору стирание итогов вайпания).
No. 26694  
Мы не рассматриваем и не рассматривали фапчу как сколько-нибудь серьёзный способ защиты от чего-либо.
Задачи на трекере, связанные с вайпами, уже висят.
No. 26695  
>>26694
Возможно, стоит рассматривать хотя бы гипотетически? Ну как, вдруг понадобиться, а у нас уже все есть.
No. 26696  
>>26693
На вид у вашей идеи с идеей >>26690 есть общий необходимый компонент: детектор аномалий постинга и движок правил для них.
Получается задача по фильтру злоупотреблений наиболее перспективная?
No. 26717  
>>26690
Так фапча вводится лишь один раз, а потом пости сколько влезет. Так что идея описанная тобой неработоспособна. С таким же успехом, можно ещё скрипт ответного автодудоса подключить.

>>26696
Нельзя "отбить" вайп программно, если соответствующее ПО не может его засечь.
No. 26718  
>>26717
> фапча вводится лишь один раз, а потом пости сколько влезет
Тогда она и удаляется так же легко, по общему проездному. Ерунда полная с такой бороться - это как вайпать с одного айпишника.
No. 26719  
>>26717
> соответствующее ПО не может его засечь
А существует некое ПО, достоверно засекающее ботов? На самом деле - нет.

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

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

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

Но это уже крайние, теоретические меры, конечно. Забежавший сюда вайпер того не стоит.
No. 26720  
>>26717
>Так фапча вводится лишь один раз, а потом пости сколько влезет.
Нет, она позволяет постить в рамках разумного, но если что сессия сбрасывается. Поэтому идея >>26690 работоспособна и покрывает случаи когда фапча вводится ботом заново потенциально может быть каждый раз
No. 26721  
Как починили quick reply? Чем закончилась та эпопея-то?
No. 26722  
>>26721
Выше всё написано.
No. 26728  
>>26066
Возможно, ли создать бордк на этом движке? Как? Извините я сисадмин, по этому не особо разбираюсь в бекенде и архитектуре борды.
No. 26729  
>>26728
*борду
No. 26733  
>>26728
Куда вам борду, если вы даже тред не в состоянии почитать: >>26192
No. 26734  
>>26696
Да хоть бы просто быстрый откат сделали для начала.
No. 26735  
https://bitbucket.org/Therapont/fbe-410/issues/46/ (проблема с двойной сажей) переоткрыт в связи с обнаружением бага.
No. 26737  
>>26733
Спасибо, но я продпочел fukuro в качестве движка
No. 26750  
Чтобы немного поднять всем настроение, сделал пулреквест с превью в каталоге.
No. 26751  
>>26750
Забыл упомянуть, что нужен ребилд доски, чтобы заработало.
No. 26755  
>>26734
Опишите на всякий случай, какие еще сценарии хотелось бы покрыть.
No. 26761  
>>26755
Вот всё думал, да не придумал.
Разве что модерские кнопки добавить, чтобы прямо с доски можно было сносить.
No. 26764  
>>26761
А в чем будет отличие этой кнопки от текущей кнопки B?
No. 26768  
>>26764
Она только с одним сообщением работает.
No. 26787  
screenshot.webp - (45.15KB, 900×272)
26787
Как в первом абзаце в сообщении >>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).

Скриншот прилагаю.
No. 26801  
Если вѣрить изложенным по адресу 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чане? — извѣстны ли сроки?
No. 26815  
https://bitbucket.org/Therapont/fbe-410/issues/52/ редактирование темы нити
https://bitbucket.org/Therapont/fbe-410/issues/53/ убрать показ фрейма по умолчанию
No. 26840  
>>26801
Я помню, что FBE не работал с 8-ой пыхой из-за каких-то deprecate-нутых функций. Не знаю, починили это или нет.
No. 26841  
>>26840
Странно что не оформлено как задача в трекере тогда
No. 26842  
>>26841
А в системе сейчас 7.4, как обновится до 8, так и будем смотреть, работает оно или надо подкручивать.
No. 26866  
screenshot.webp - (73.43KB, 900×762)
26866
Вышел движок PHP версии 8.2:

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

(Как я ужé сообщал мѣсяцъ назад, это первая из версий PHP, полностью поддерживающая в своей графической библиотеке GD графический формат файлов AVIF.)
No. 26867  
Если формат JFIF является тем же JPG, то следует прописать это в движке.
No. 26870  
>>26867
В 84-ой строчке внутри inc/classes/upload.class.php заменить
> if ($this->file_type == 'jpeg') {
на
> if ($this->file_type == 'jpeg' || $this->file_type == 'jfif') {
No. 26874  
Советую всё-таки заняться хоть какими-то инструментами против вайпов, раз пациент упорствует.
No. 26876  
>>26870

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

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

load_receiver.php на строке 91 и 123.
No. 26879  
Тамова постинг WebP отвалился.
> Incorrect integer value: '' for column
410chan
.
posts_b
.
thumb_w
at row 1

No. 26880  
screenshot.webp - (3.85KB, 390×292)
26880
>>26879

Администрация вроде бы пофиксила вот это вот всё.
No. 26881  
php8.webp - (18.00KB, 1036×94)
26881
Там на 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'нутую лабуду.
No. 26882  
>>26881
Если у вас есть силы, было бы клево сделать Dockerfile и добавить его в репозиторий. Чтоб потом одна команда - и едет локальный автобус. Клёво же!
No. 26885  
Дополнил 51 возможным вариантом того, как фильтр мог бы работать и настраиваться.
No. 26886  
>>26880
Только что снова столкнулся, причем с обычным на вид jpg-файлом.
No. 26887  
>>26886
Возможно, ваш жпег на самом деле не жпег.
No. 26888  
>>26887
Пейнт считал что жпег, и даже сохранял в нем изменения >_>
No. 26889  
>>26888
Paint, как и многие другие программы, при открытии файла смотрит на первые его байты и по ним определяет формат картинки. То есть, скорее всего, Paint открыл ваш PNG файл с расширением .jpg, посмотрел на первые его байты, и справедливо посчитал, что он PNG, и сохранил изменения в вашем файле с расширением .jpg как PNG. FBE (Кусаба) написан так, что соответствие расширения файла его фактическому формату необходимо. А Paint нет.
Бывают такие случаи. >>/d/2636

Постовайте файл на https://catbox.moe, посмотрим.
No. 26890  
>>26889
Вы оказались совершенно правы, по сигнатуре файл PNG, а расширение - JPG. Стоило сразу посмотреть, спасибо за разъяснение.
No. 26907  
Посмотрел исходник и сблевал от смеси логики с HTML в виде строк с тегами и ` = ".mysqli_real_escape_string

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

>>26908
Мне кажется, что если желающий не может поставить движок, то он вообще не сильно разбирается в этих технологиях, чтобы что-то там переделывать.
No. 26911  
>>26910
При установке движка есть несколько нюансов, которые нужно соблюсти, и несколько ошибок, которые нужно устранить. Также у нас не указаны необходимые движку PHP-модули, также отсутствуют некоторые миграции. Оно все мелочи, но накопительный эффект от этого есть - получается такое "испытание на входе в древний храм". Нужно иметь некоторый профессиональный опыт, чтобы все правильно интерпретировать, починить, и автобус завелся.
No. 26985  
Добавил забытый баг из предыдущей нити: https://bitbucket.org/Therapont/fbe-410/issues/54/suspend
No. 27043  
Лично моего опыта для рѣшенія проблем >>26911 не хватает, поэтому я просто воздерживаюсь и от установки FBE, и от сочинения такого кода FBE, провѣрка которого требовала бы именно установки FBE, а не подобных >>/dev/20224 средств и не «тут и так понятно, провѣрять нечего».
No. 27058  
Реквестирую https://bitbucket.org/Therapont/fbe-410/pull-requests/77 для учёта возможности неsRGBшной цвѣтности (контуры которой сообщениями >>/b/196588 и >>/b/199138 и их обсуждением намѣчены) примѣнительно к миниатюрам (thumbnails).

Попутно улучшил развёртыватель миниатюр.
No. 27066  
>>27043
А наличие в репозитории докер-файла для поднятия FBE помогло бы?
No. 27067  
>>27066

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

Они ж не ставятся на Windows 7.
No. 27068  
151312326915[1].jpg - (3.60KB, 295×33)
27068
А ни у кого не сохранились скрипты на пикрелейтед?
В старом треде за 2017 год только пастбины протухшие.
No. 27075  
Я рад видѣть запрос >>27058 удовлетворённым недѣлю назад (и исходный код вмёрдженным) — однако, наперёд терпеливо подождав недѣлю, теперь с любопытством поинтересýюсь: а когда эти правки кода собираетеся накатить непосредственно на 410чан? Есть какие-нибудь планы?
No. 27079  
Вижу, что исходный код пошёл въ дѣло.

Спасибо.
No. 27099  
Разработка движка в целом померла, но я завёл новую задачу: https://bitbucket.org/Therapont/fbe-410/issues/55/
No. 27133  
Сообщение >>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чане? — вопрос не риторический, я это всерьёз спрашиваю.
No. 27134  
>>27133
Я предполагаю, что в последующие недели или месяцы на сервере будет обновлён «Дебиан», тогда и будем смотреть, что там поддерживается. Сроков обновления пока нет. Спрашивать их не надо.
No. 27137  
screenshot.webp - (77.74KB, 1280×892)
27137
Чувствую, что для пользы дальнѣйшаго тестирования не помѣшалъ бы примѣръ такого AVIF, который был бы:

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

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

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

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

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

В эту старую ветку (в отличие от ImageMagick 7) ужé никто и никогда не станет впиливать поддержку новых форматов, и это не одного только AVIF впрямую касается, но и JPEG XL также. Никогда, никогда!
No. 27149  
5xdmc0vxqhd21.jpg - (34.23KB, 640×661)
27149
Кажется, fbe на php8.2 который теперь в debian stable по умолчанию, работать не будет.
No. 27150  
https://bitbucket.org/Therapont/fbe-410/issues/56/php-8
Завёл задачу по обновлению движка под ПХП 8.2. Движок оказался совсем неработоспособен, чтобы его своими силами быстро починить, так что помощь не просто приветствуется, но всячески необходима.
No. 27154  
monkey triple facepalm.webp - (7.00KB, 534×534)
27154
https://www.php.net/manual/en/migration80.incompatible.php
No. 27169  
screenshot.webp - (339.75KB, 900×945)
27169
По адресу https://t.me/exploitex/8944 встрѣтилося упоминание того, что вскорѣ «Битбакету» настанет кирдык.

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

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

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

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

Суманъ.
No. 27198  
На данный момент все существующие внутренние наработки по переходу на новую версию ПХП доступны в репозитории. Оно по большей части работоспособно, но нужно тестирование; из известных проблем — сломаны предупреждения. В ближайшее время обновлений не будет, видимо.
Если кто-то соберётся новые пулреквесты по этой теме делать, учитывайте это.
No. 27202  
>>27179
А когда новая версия PHP выйдет и опять что-то сломают, по новой переписывать всё? Вот уж действительно неблагодарная работа. Лучше уж один раз переписать на языке, где заботятся об обратной совместимости.
No. 27206  
>>27202
>на языке, где заботятся об обратной совместимости
C, Common Lisp? Какие ещё варианты?
No. 27208  
>>27206
Приходят на ум JavaScript/TypeScript, Java, Go.

С Python ситуация интересная, в пределах мажорной версии не ломают совместимость, при переходе с 2 на 3, конечно, поломали. Но при этом Гвидо заявляет, что Python 4 может не выйти никогда (https://builtin.com/software-engineering-perspectives/python-4). Поэтому включу в список Python 3.
No. 27210  
>>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 в этом плане ситуация получше, но не знаю, так ли это на самом деле, и насколько лучше.
No. 27211  
>>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
No. 27212  
1260020516120.jpg - (74.07KB, 819×720)
27212
Свалите флудить в другую нить.
No. 27213  
>>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 не будет.
No. 27279  
Поскольку произошло описанное в >>27169, репозиторий переехал на https://codeberg.org/FBE410/fbe-410
No. 27335  
Что за «функция предупреждений», упомянутая в >>/b/205318? Имеется в виду весь механизм предупреждений или какая-то одна функция? Что конкретно там поломано?
No. 27336  
>>27335
Страница предупреждений выдаёт пустую страницу. При этом предупреждаемое через кнопку с доски сообщение удаляется без оставления записи об этом в модлоге.
Основной код тут:
https://codeberg.org/FBE410/fbe-410/src/branch/public/inc/classes/warnings.class.php
No. 27337  
>>27336
Открыл pull request.

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

1. В config.php необходимо было дописать
define('CONGLOMERATE', array());
, иначе была ошибка с несуществующей переменной CONGLOMERATE. Вполне возможно, что вписывать это нужно было в какой-то другой файл.

2. Три PHP-файла содержат ссылку на изображение “410.png”, однако в репозитории есть только “410logo.png”.
No. 27354  
Озабочен я проблемой >>/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 или в этих вызовах всё же есть какой-то тайный смысл?
No. 27355  
>>27354
> Но зачем декодировать URL encoding
https://ru.wikipedia.org/wiki/Красота
No. 27356  
По-хорошему же стоит сделать разбиватель строк, который разбивает строку после декодирования URL по юникодной длине с пропуском тэгов разметки и их атрибутов. У UTF8 вроде чёткий и легко имплементируемый механизм нахождения длины символа по его первому байту.
No. 27359  
Совсѣмъ-то по-хорошему надо бы:

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

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

③ бережно сохранить учёт байтов въ таких мѣстахъ, в которых длина строки реально ограничена количеством байтов (напримѣръ, «в таблице БД величина имени файла не может превосходить столько-то байтов»), но и там не проигнорировать возможную многобайтовость сѵмволовъ (скажем, использовать mb_strcut для обрѣзанія).
No. 27372  
Провёл исследование: на других имиджбордах и форумах проблема длинных слов либо никак не решена, либо решена с помощью свойств CSS “word-break” и/или “overflow-wrap” (оно же “word-wrap”). Принудительное разбиение на слова на уровне движка (CutWord) выглядит каким-то костылём, доставшимся в наследство ещё от кусабы. Есть ли в нём хоть какой-то смысл сейчас, если можно написать в CSS
.postbody {

  word-break: normal;
  overflow-wrap: anywhere;
}
?

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

Ceterum censeo, вызовы urldecode в парсере разметки нужно просто-напросто убрать, т.е. заменить urldecode(x) на (x). В этом и заключается надлежащее решение.
No. 27375  
>>27372
>чтобы горизонтальная прокрутка была только у провинившегося поста, а не у всей страницы
На контейнеры
overflow-x: hidden;
,
width/max-width: 100vw;
/
...: 100%; box-sizing: border-box;
. На сам пост
max-width: 100%; overflow-x: auto
.
No. 27378  
>>27375
Спасибо, похоже на правду, но идеально воспроизвести у меня не получается (остаётся небольшая горизонтальная прокрутка у всей страницы, а “overflow-x: hidden” это костыль). И ещё я не понимаю, про какие контейнеры ты говоришь. Можешь показать пример страницы, где такое сделано?

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

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

Что, дѣлать нечитаемыми URLы, в которых есть японские сѵмволы или кириллица? Ради чего? Чтобы что?
No. 27380  
google_and_cp1251_0xff.png - (63.47KB, 925×558)
27380
>>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, а также другую проблему. Если эти проблемы будут тем или иным образом решены, то вопрос о том, нужно ли декодировать, с моей точки зрения, не будет очень существенным. Просто оно для этого не предназначено.
No. 27381  
Хорошие контраргументы.

(Правда, если ими руководиться, то тогда опосля надо будет передѣлать парсер, насколько я понимаю — чтоб русские буквы принималися в URLы, а не означали конец URLов.)
No. 27382  
>>27381
> опосля надо будет передѣлать парсер
Это не так: и старое, и новое (предложенное yakui-lover в открытом PR) регулярное выражение считают кириллицу частью URL.
No. 27386  
Ну что же, открыл pull request, который реализует надлежащее (по моему мнению) декодирование URL.
No. 27391  
Насколько я понимаю, предположение >>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.

Каждое из этих трёх обстоятельств остаётся и по сей день.
No. 27396  
Если в сообщении >>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 (совершаемого по объёму файла) не очень полезны, потому что могут побуждать похѣрить ещё и их качество ради экономии объёма файла.
No. 27397  
И так как в сообщении >>26066 сказано, что только администрация 410чана принимает рѣшенія, то предлагаю на ея разсмотрѣніе идею >>27396.
No. 27399  
Переход на ПХП8 состоялся, но всякие мелочи ещё остались, поэтому с рассмотрением новых функций и всякого такого пока притормозим.

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

Рекомендую включить показ ошибок в ПХП (https://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors ).
No. 27401  
Предлагаю к теме «Futaba» крашеный скроллбар въ цвѣтахъ логотипа:

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

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

$('html').css('scrollbar-color', '#1b7942 #fdffc7')
No. 27402  
>>27401
Оно должно быть в цветах «Футабы», а не логотипа, никак с ней не сочетающихся. Отказано.
No. 27417  
Я считаю, что ни avif, ни webp, ни jxl не нужны. PNG, APNG, GIF и JPEG прекрасно справляются. А новомодные форматы лишь плодят фрагментацию, выбивают станые версии браузеров и вносят уязвимости в новые. Не так давно RCE в webp была. А что творится в AVIF и JXL — вообще мало кто знает. Лучше отключить, а неадекватными сайтами, сделавшими ставку на смузимусор — не пользоваться.
No. 27420  
Так как файл >>/a/19707 занимает ровнёшенько 5 мегабайтов (5 242 880 байтов), то можно быть совершенно увѣренными в том, что ограничение работает в формулировке «не больше 5120 килобайтов», а не «до 5120 килобайтов», как это сейчас сообщается.

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

В общем-то да, но тогда бы неплохо опосля килобайтов добавить (через пробѣлъ) слово «включительно», которого там по умолчанию нѣтъ.
No. 27436  
Сохраняющиеся после последнего обновления совместимости с ПХП8 проблемы:
https://codeberg.org/FBE410/fbe-410/issues/15#issuecomment-1807945
No. 27447  
NICE BOAT.7z - (59.77KB)
27447
>>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) сегодняшнею версиею кодировщика.
No. 27448  
jxl давно в Firefox поддерживается. Может не полностью, но поддерживатся. А на сжатие мема - я уже сказал, пофиг. Никакие несущественные прибавки в качестве или коэффициенте сжатия не не компенсируют слом совместимости.
No. 27449  
А на флеш плеер вообще пофиг, с 2009 года его не использую. Ну а кто хочет - может жрать.
No. 27450  
>>27448

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

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

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

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

То есть, можно сказать, почти ни у кого не поддерживается.
No. 27451  
110631548_p0.webp - (4.26MB, 3186×4096)
27451
>>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ок. Ещё существенней для архивов.
No. 27452  
>>27451

Несомнѣнно.

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

https://410chan.org/b/arch/res/158687.html#159029
No. 27453  
Пока работа, видимо, в очередной раз встала, напомню, что у нас есть много всяких задач, заведённых от многих месяцев до многих лет назад: 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 также всё ещё актуален.
No. 27454  
112041438_p0.jpg - (1.17MB, 1388×1636)
27454
>>27453
> issues/9
Погляжу на выходных и, скорее всего, кину исправления в тред. Не даёт codeberg по throw-away'ке регаться.
> issues/11
Если нужно, чтоб по https://410chan.org/ показывалось news.php, то достаточно в .htacess поменять DirectoryIndex с kusaba.php на news.php.
No. 27455  
webp.webp - (48.82KB, 2106×1051)
27455
Таки поглядел прямо сейчас, там всё просто.
В строке 4372 у inc/classes/manage.class.php, в if со списком форматов добавить сравнение $line['filetype'] == 'webp'.
No. 27457  
101528376_p0_sample.webp - (4.97MB, 3686×5898)
27457
> issues/15
На выходных тогда посмотрю, много ли там работы по устранению deprecated-ов.

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

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

>>27457
Я не буду кого-то искать неизвестно где. Разве что в /b/ напишу, наверное. Если человек сюда не ходит, ему оно вряд ли интересно. Если автора нет, то кто-то ещё мог бы предложить свою реализацию.
>Иначе ведь действительно ширина менюшки скакать будет.
Да вроде у нас и меню не такое большое, и числа, чтобы это критично было. Вот для мобилок можно было бы альтернативную индикацию попробовать сделать.
No. 27461  
Вослѣдъ >>27455 хорошо бы туда же добавить «'avif'» — так сказать, «на вырост».
No. 27463  
Super Katawa Shoujo - Kenji.webp - (10.14KB, 640×480)
27463
За год и ещё за три недѣли, со дня вопроса >>27068 прошедших, никто не откликнулся.

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

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

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

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

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

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

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

⑤ Должен ли счётчик непрочитанных сообщений обнуляться в тот момент, когда пользователь навѣстилъ подраздѣлъ? — или всё же неплохо бы https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API задѣйствовать для того, чтобы новое сообщение считалося прочитанным тогда только, когда оно реально вплывает в видимую часть окна браузера, причём не началом, а концом своим? — да не стóит ли дополнительно навѣсить таймер и смотрѣть, долго ли новое сообщение остаётся в области видимости, чтобы исключить ложныя срабатыванія во время быстрой прокрутки страницы?
No. 27465  
109929796_p0.webp - (2.67MB, 1000×1778)
27465
>>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 запилить что попроще, а космолёт потом строить, если надо будет.
Таковы мои мысли по этому поводу.
No. 27466  
htaccess_update.webp - (54.89KB, 2365×816)
27466
>>27458
.htaccess, который в KU_ROOTDIR, кусабовскими скриптами, кроме как для добавляния забаненных IP, не меняется. То бишь, этот Apache'шный конфиг до метки "## !KU_BANS:" совершенно статичен и единственное место, где настраивается файл главной.

По замене DirectoryIndex-а в .htaccess скрипт https://410chan.org/kusaba.php будет продолжать работать, можно сделать симлинк f.php, чтобы фанатам было нетрудно набирать. Нужно будет также убрать target="_top" из <a>'шки-домика, иначе по клику на домик во фрейм-контексте человека вернёт на https://410chan.org без фрейма.
No. 27467  
removeframes.webp - (16.96KB, 1916×239)
27467
> Заодно стоит починить скриптовую функцию “Убрать фреймы” во фрейме, которая, кажется, сломана.
Функция эта в текущем варианте меняет ссылки на доски во фреймовом меню так, что при клике на них человек перейдёт на страницу без фреймов. То бишь, «Фреймы убраны» — это про то, что они убраны из ссылок на доски, а не из поля зрения.
No. 27469  
главная.webp - (132.09KB, 2553×939)
27469
Вообще, есть такая идея, как поступить с фреймами.

Само по себе меню со списком разделов слева и news.php в центре выглядит отнюдь не плохо, как дизайн главной. Куда лучше уродливой ичанской главной, например. Может, сделать, чтобы по переходе на доску из фреймового меню переход убирал фреймы по умолчанию, аналогично поступив с ссылками, приведёнными в news.php? И тогда поменять опцию “Убирать фреймы” на “Оставить фреймы”.
No. 27470  
>>27464
Ещё, может быть, надо учесть кейс с несколькими открытыми вкладками и долгоживущими вкладками.
Как ведут себя значения в localStorage читаемые и записываемые из нескольких вкладок. Не придется ли тут синхронизацию какую городить через postMessage.
No. 27471  
>>27465
На самом деле, нам действительно не помешало бы АПИ или что-то такое, дабы оптимизировать работу скриптов и запилить вещи типа https://codeberg.org/FBE410/fbe-410/issues/6
Просто я в этом ничего не понимаю. Надо, чтобы кто-то проанализировал существующие реализации. Я могу только задачу на трекере завести официальную, лол.

>>27469
Этот десигн ничем не лучше ычановского. И вообще пока висит как заглушка, потому что новости не используются из-за https://codeberg.org/FBE410/fbe-410/issues/14
Список досок на главной надо будет сделать, но это уже следующая фаза. И опять же его надо будет делать относительно новостей.
No. 27472  
1542829893169.jpg - (23.38KB, 347×402)
27472
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, то не стоит. Поди разберись, где оно надо, а где надо.
No. 27474  
phpstan.webp - (49.47KB, 2324×1306)
27474
phpstan говорит, что с FBE проблем немножко больше, чем может показаться на первый взгляд. Надо будет поглядеть, на что именно статический анализатор ругается, и пофиксить то, где он ругается не зря.
No. 27477  
board-post_class.webp - (47.12KB, 1945×871)
27477
>>27471
> https://codeberg.org/FBE410/fbe-410/issues/6
> полностью пустое сообщение, к ОП-посту не приложен файл, слишком длинный текст, слишком большой или кривой файл, не введена капча и т.д.
Кривой файл или нет, это пусть проверяет сервер, наверное. Разве что проверять, соответсвтует ли заголовок файла его расширению для некоторых форматов во избежание >>26890-ситуации.
А так, по перечисленному, информация для проверки на стороне клиента вроде вся, кроме максимальной длины текста, есть. Только её вывод в board-post.class.php и добавить рядом с MAX_FILE_SIZE. Что-то радикально новое со стороны сервера тут не нужно.

> Этот десигн ничем не лучше ычановского.
Ещё скажи, что хуже, лол.
No. 27478  
1495319689399.jpg - (39.99KB, 496×375)
27478
>>27477
>Ещё скажи, что хуже, лол.
Я скажу, что тут просто никакого десигна нет. И при появлении блока новостей оно будет вообще выглядеть почти аналогично.
На «Ычане» только надпись надо выравнять, вместо неё картинки были раньше.
No. 27479  
uguu.jpg - (141.55KB, 1280×720)
27479
>>27478
> И при появлении блока новостей оно будет вообще выглядеть почти аналогично.
Ugh. Значит, лучше не приступать.
No. 27480  
>>27479
Можно просто на главную не ходить, если какие-то психологические проблемы. На неё и так никто не ходит, кроме жертв фрейма.
No. 27481  
113599466_p0.webp - (2.25MB, 3508×2480)
27481
>>27480
Сомневаюсь я, что, например, вот этот >>/ci/1605 вот постер набрал https://410chan.org/ci, а не перешёл туда с главной.
Пусть наша приветственная страница выглядит хорошо.
No. 27482  
117002670_p0.jpg - (712.55KB, 1000×1386)
27482
> color: #800000;
> font-weight: bold;
Так и задумано? Или postername-стиль в umnochan.css по ошибке поменялся?
Предыдущие значения были:
color: #310000;

font-family: sans-serif;

No. 27483  
>>27482
Да, теперь во всех стилях имя оформлено одинаково.
No. 27485  
>>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;
}
No. 27486  
У нас здѣсь на имиджборде всё так устроено (и мы так привыкли), что сообщение никак нельзя редактировать опосля отправки.

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

Нешто трудно, пусть и не редактируя давния сообщения, «на лету» (во время обращения по ссылке) прибавлять HTTP-перенаправление (на arch/ перебрасывающее браузер читателя) в таких случаях, когда обсуждения нѣтъ, но архив его зато есть?
No. 27487  
>>27486
Это никак не относится к работе движка.
Удалить сообщение []
Пароль  
[Mod]