>>1000483
Спасибо. Может, к воскресенью что-то уже готово будет.

>>1000477
Сделал через '<img class="spoiler-holder" src="' . TimestampToSpoiler() . '"></img>'. Патч в архиве. Варианты добавлять в директорию css/spoilers. По изменению вариантов, перегенерировать страницы.

> image(attr())
MDN говорит, что url(attr()) нельзя.
https://developer.mozilla.org/en-US/docs/Web/CSS/attr#limitations_and_security

Можно было бы, наверное, выкрутиться через background-image: if(mod(attr(), --spoiler_count), ..., ...) но писать-тестировать толпу вложенных if-ов мне лениво: насколько я понимаю, array'ев, switch'ев и map'ов в CSS нет. Как и нет substr, так что всё равно board-post.class.php менять пришлось бы.

Чтобы только через CSS, можно выкрутиться через селекторы.

.catalogpic.spoiler-image:has(:is(img[src*="0s."],img[src*="1s."]))::after,
.spoiler-image.imglink:is(a[data-full-src*="0."],a[data-full-src*="1."])::after {
  background-image: url('/css/spoilers/spoiler-koromo.png');
}

.catalogpic.spoiler-image:has(:is(img[src*="2s."],img[src*="3s."]))::after,
.spoiler-image.imglink:is(a[data-full-src*="2."],a[data-full-src*="3."])::after {
  background-image: url('/css/spoilers/sp-test-gold-cyr.png');
} …и так далее.

С одной стороны, централизованно всё и в случае добавления/удаления спойлеров не нужно тратить время на регенерацию всех HTML досок и тредов. С другой, не знаю, скажем, 11 разных спойлеров и 100 таких правил… Convoluted это несколько. Хотя если helper скрипт сделать, который такой spoilers.css по содержимому директории spoilers автоматически генерит, наверное, не страшно. Если CSS-only вариант нравится больше, думаю, стоит при генерации HTML добавлять отдельный attribute с timestamp'ом: поддержке :has вроде всего два года как.

>>/b/1004675
Думаю, стоит повесить баннер.

>>1000486
>>1000487
Обновлено, спасибо.
>MDN говорит, что url(attr()) нельзя.
Да, тогда ттолько оверлеем через css.

>TimestampToSpoiler()
Я попробую сделать что-нибудь поинтереснее, чтобы картинки не менялись от количества спойлеров. Да, базу править конечно, но щито поделать.

>>1000488
> Да, базу править конечно, но щито поделать.
Ну, можно отсортировать файлы-заглушки по дате-времени их создания в ФС, и выбирать по модулю только из тех заглушек, которые созданы не позже прикрепляемой картинки. Но лучше, наверное, всё-таки отдельную таблицу для этого, сделав timestamp заглушки unique. А можно никаких миграций не делать и выкрутиться, как с баннерами: заведя отдельную закртыдоску под них, скажем, spoilers. Хотя вот для баннеров Соус призывает отказаться от такого подхода.

Альтернативно, можно позволить заглушкам для старых картинок обновляться и воспользоваться consistent hashing, тогда от добавления одной новой заглушки к N имеющимся вероятность того, что заглушка у картинки поменяется будет circa 1/N. Но это при условии, что порядок файлов в выдаче scandir() от добавления не поменялся.

Скажем, https://arxiv.org/pdf/1406.2294
int32_t JumpConsistentHash(uint64_t key, int32_t num_buckets) {
    int64_t b = 1, j = 0;
    while (j < num_buckets) {
        b = j;
        key = key * 2862933555777941757ULL + 1;
        j = (b + 1) * (double(1LL << 31) / double((key >> 33) + 1));
    }
    return b;
} O(ln num_buckets) в среднем.

>>/b/1004760
> За-escape'ить тильдой объявление списка в данном случае нельзя. Точнее, нельзя за-escape'ить только его: вместе с ним за-escape'ится и конец цитаты. Всё-таки стоило разделить "\r\n- " и иже на два mark'а. Позволило бы более интуитивно-потятно escape'ить списки заодно, хотя, возможно, и усложнило бы код
Внезапно, всё оказалось достаточно просто. Даже проще, чем было. Теперь можно escape-ить окончание (пункта) списка и его объявление отдельно. Что позволяет escape-ить список тильдой на той же строке.
>>1000411
…И что, судя по всему, без особой возни и без ввода новых элементов разметки позволяет запилить вложенные списки. Надо или нет?

>>1000457
Починено.

>>/b/1004763
Парсер теперь понимает и одиночные CR и LF. Надо проверить, решит ли проблему.

Патч в архиве.

BTW, стоит ли вернуть GetCWebpath в inc/func/paths.php? У нас, скорее всего, из-за этого https://014chan.org/news.php ошибку 500 сейчас возвращает. Кажется, меня с manage.php тоже возникла какая-то похожая проблема, но я уже не помню точно.

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

This is a test.

>>1000494
Я импортировал >>1000491 но не предложенные изменения на 410.

>>1000494
Должно быть починено.

Подумываю вот переделать JS posting с fetch'а на XMLHttpRequest, чтобы прогресс отображался (текстом и/или цветом а-ля progress bar). Заодно несколько расширить проверку на клиенте того, что можно: размер файла, соответствие формата файла содержимому.

В связи с чем хочу несколько поменять способ, которым разные свойства передаются клиенту. Сейчас это делается через smarty, который пишет script'ы с ними в head — кроме MAX_FILE_SIZE, который в скрытом input'е под postform'ой. Под бордоинвариантные из этих свойств завести общий channel.json в KU_WEBPATH. Под бордоспецифичные — свой board.json для каждой доски. И в head тогда писать link'и к ним.

Проблема с channel.json в том, что не совсем ясно, как trigger'ить его регенерацию. В config.php сравнивать дату изменения этого config.php с датой изменения channel.json? Но captcha_message вот не по config.php генерируется, а из gettext-овских файлов. Его оттуда в kusaba.js ко strings убрать?

И как быть с magic numbers для форматов. Вообще, схожие определения/перечисления для типов файлов у нас сейчас распиханы по разным местам: kusaba.js, posts.php, manage.php, таблица filetypes. Хотелось бы неким образом это централизовать. Наверное, отчасти это происходит из-за нежелания делать целый запрос в базу, чтобы проверить, скажем, является ли файлорасширение картинкой или, скажем, является ли тип картинки анимируемым. Так что если генерить channel.json по config.php, наиболее простым вариантом видится выпилить таблицу filetypes и в config.php завести KU_FILETYPES, а в posts_* завести столбец allowed_filetypes с содержимым вида ".jpg.png.gif.webp", по strpos проверяя поддерживаемость.

Конечно, может нарушится integrity, если в config.php формат пропадёт, а в столбце останется, но Соус не так давно сперепугу форматы поудалял, а треды в /dev/ вполне себе спокойно регенерируются, правда без thumbnail'ов-заглушек, где удалено. Однако Соус просил сделать настраиваемость определяемого в config.php через manage.php, а вынос регистрации форматов в config.php такой идее скорее противоречит.

Если реализовывать Соусову идею, заменить config.php на config.json? Но не парсить же JSON при каждом вызове read.php, да и разный postprocessing для $cf[] в config.php делается. Но можно генерировать config.php на основании config.json и поставить require config.after.php в конец. В тот config.after.php добавить postprocessing и свойства, которые генерировать по JSONу не целесообразно или не хочется. Also, генерировать config.php можно ведь и не по JSONу, а по БД, где под всякие KU_CATTHUMBWIDTH завести таблицу-синглтон, оставить filetypes в БД и JSONы только для клиентов тогда. Но за актуальностью автосгенерированного config.php по config.json следить проще: если какое-то из конфигурационных значений в БД поменяется не через manage.php, должен быть механизм обновления config.php, а с config.json можно ± обойтись сверкой дат изменения. В прочем, с board.json та же проблема, если какие-то update'ы в таблице boards не через manage.php делать. В общем, некий явный механизм актуализации JSONов всё же будет нужен.

Как смотрите?

>>1000497
>Проблема с channel.json в том, что не совсем ясно, как trigger'ить его регенерацию.
Если там параметры, что можно менять в рантайме, то по сохраниению этих параметров. Если там не такие параметры, то или ставить этот json как source of truth и импортировать их в config.php, или запихивать пых в жсон чтобы импортировалось из config.php.
>Хотелось бы неким образом это централизовать.
Если что-то звучит как либа и крякает как либа, то возьмите готовую либу.
>наиболее простым вариантом видится выпилить таблицу filetypes и в config.php завести KU_FILETYPES, а в posts_* завести столбец allowed_filetypes с содержимым вида ".jpg.png.gif.webp", по strpos проверяя поддерживаемость
Это выпилит возможность добавлять форматы без доступа к серверу. В идеале, это надо только на тип формата, а не на каждое расширение.
>Но не парсить же JSON при каждом вызове read.php
plz, мы делаем запрос к БД просто чтобы проверить что доска с таким-то именем действительно существует в самом начале файла. Завернуть конфиг в формат, предназначенный для конфига, или целиком в БД никаких значимых потерь в производительности не привнесёт.
А вот делать синхронизацию которая всё равно должна будет читать жсон/БД - это тащить корову на баню.

>>/b/1004863
> https://ru.wikipedia.org/wiki/Понтрягин%2C_Лев_Семёнович
> %2C
На Авто/b/усе та же штука. Вроде декодирование печатаемых (>= 0x20 и не DEL) ASCII-символов не должно влиять на парсер у 410, но у нас не должно точно, так что исправил это + небольшие исправления в коде для списков.

>>1000498
Пока склоняюсь к тому, чтобы в config.php импортировать config.json, сделать его source of truth и сделать его 403, а JSONы для клиентов генерировать. Предусмотреть в manage.php пункт меню для регенерации тех JSONов: чтобы, если удобнее, config.json и БД можно было отредактировать чем-то кроме manage.php и в manage.php лишь применить изменения.

> А вот делать синхронизацию которая всё равно должна будет читать жсон/БД - это тащить корову на баню
Я отчасти потому config.php предложил генерировать, что какие-то строки для оптимизации через APC в config.php уже есть. И что ситуация, когда read часто, write almost never, а сравнение времени модификации файлов и проверка flock всё же более простая, наверное, операция, чем чтение их содержимого.

> Если что-то звучит как либа и крякает как либа, то возьмите готовую либу.
Для проверки соответствия расширения файла его заголовку можно подтянуть file или какой у PHP к нему binding, но ведь и для JS что-то нужно будет взять... Точно не overkill для ныне circa 10 расширений, где оно надо? С другой стороны, ещё удобнее будет новые форматы добавлять и для них тоже проверка будет.

В целом с расширениями и информацией о них пока склоняюсь к тому, чтобы получать их из JSONа. Без SSH к серверу, пусть через manage.class.php тот JSON будет редактируемый.

> read.php
Возвращаясь к нему, хочу заметить, что оно из архитектуры, где страницы каталогов, досок и тредов статичные, несколько выбивается подходом. Although, свиду оно позволяет несколько постов читать, но у нас это где-то, кроме как для внутренних ссылок, используется? Судя по inc/func/calculations.php:getQuoteIds, когда-то через запятую форматом >>0,1,2 можно было указать несколько постов, но они у нас форсированно одиночные, и вряд ли какие-то изменения предвидятся.

По Traditional: read.php/board/thread/posts могу предположить, что когда-то посты были статичными файлами тоже, что было бы проще. Скажем, если запиливать внутренние ссылки на посты архивированных тредов. Но можно решить и перестав выпливать посты архивированных тредов из базы и добавив столбец is_archived.

Хм, now that I look at it, вижу getArchivePostMessage в inc/func/stringformatting.php и параметр $archive_dir у formatReflink. Но у Соуса ссылки на архивные посты не работают, и по вопросу сказал, что не нужно, помнится. А у нас, если какие-то треды в архив отправлять, я бы сделал. Но не проще ли просто закрывать старые треды тогда? Перенося, может, на специально отведённую под архив доску.

>>1000500
>какие-то строки для оптимизации через APC в config.php уже есть
Таки да, но APC заменён на APCU ещё с седьмого Пыха, и по умолчанию выключен. Я не уверен, что многие этим пользовались. И я не вижу какого-либо способа из админки форсировать перезагрузку конфига для всех.
>сравнение времени модификации файлов и проверка flock всё же более простая, наверное, операция, чем чтение их содержимого
Возможно, но это всё равно дополнительный disc read. ИМХО, если и делать генерацию, то не автоматическую, а по вызову какой команды ручками. Ну и потом встаёт вопрос, насколько сильно надо заботиться чтобы правильно-правильно все строки там экранировать, чтобы генерация точно-точно всегда работала.
>но ведь и для JS что-то нужно будет взять
Тут бы я тем более взял либу, на самом деле. Выставлять магические числа в json не стоит, они должны быть стандарт. Должно хватать только списка поддерживаемых MIME-типов. В идеале, если не костылить самому, то и дрифта между либами быть не должно, если они нормально поддерживают стандарт.
Но нам надо костылить самим как минимум лимит на размер кадра в картинке, и количество потоков в видео. Делать это ручками очень, очень не стоит. Хотя количество потоков может можно и только серверу оставить проверять.
>Для проверки соответствия расширения файла его заголовку можно подтянуть file или какой у PHP к нему binding
Я это предлагал ещё когда на Ычан добавляли вебм, через ExifTool. Меня решили не слушать и полагаться на выхлоп ffprobe через консольку, как и в FBE потом. ЧСХ, FBE вообще не смотрит на магические числа когда генерирует уменьшенную копию, а надеется на то, что вызываемые тумбнейлеры станут противиться, если формат файла не будет совпадать с передаваемым спецификатором.
Но есть вызов mime_content_type в случае если уменьшенная копия НЕ генерируется, лол. Так что зря Соус вообще архивы выпиливал из /dev/.
>могу предположить, что когда-то посты были статичными файлами тоже, что было бы проще
Скорее всего, никогда не были. read.cgi был полностью динамикой, futallaby что-то странное со всего одним файлом, футабу тыкать лень. Есть Кахера, где ссылки как раз в Traditional-формате, но там это достигалось путём того что треды, как файл - просто наборы строк-постов, разделённые через \n. А собиралось всё опять-таки динамикой.
В целом, в те времена не думаю что людям нравилось бы хранить пост, фактически, три раза. А то и больше с +50 и -100-страницами.
>Но не проще ли просто закрывать старые треды тогда? Перенося, может, на специально отведённую под архив доску.
Архив по идее и должен быть отдельной доской под каждую доску, просто автоматизировать это слегка геморрно.
ЕМНИП в стандартной кусабе (или Х) архивирование вообще изкоробки сломано.

>44 изменённых файлов: 713 добавлений и 1853 удалений
Я хотел сделать менеджер для баннеров и спойлеров но отвлёкся. https://codeberg.org/yakui-lover/fbe-410/compare/kotocafe...yakui-lover/fbe-410:dev

>>1000501
> Выставлять магические числа в json не стоит, они должны быть стандарт
Стандартные и выставлять? Стандарты-то открытые и такие важные для совместимости вещи там, думаю, вряд ли меняются. Конечно, больше мороки при добавлении file extension'ов и писать цикл с hex2bin, но это не что-то слишком страшное в обмен на отсутствие зависимостей.

Но пусть будет либа.

> лимит на размер кадра в картинке, и количество потоков в видео. Делать это ручками очень, очень не стоит
Аа. Indeed. Хотя вот размер кадра в картинке у нас проверяется разве? И надо ли? Доводилось было видеть в интеренете такую экзотику, где этот размер увеличивался по ходу видео. Если у каждого кадра может быть свой размер, то... Просто взять, и проверить все кадры? Но, например, их в 25 MiB с mp4/avc1 можно запихать не меньше миллиона точно. Предметно говоря, сконструировал видео 1x1 на 18 MiB/700 тыщ кадров; мои попытки перебрать frame=width с помощью ffprobe идут 7-11 секунд. Хотя, если прямой binding к libav подключать, скорее всего, это будет на порядок, а то и на несколько, быстрее. Если нет, ввести предел на количество кадров? Может ли быть так, что в метаданных контейнера количество кадров одно, а на деле в контейнере их куда больше? Наверное, может. То же самое с duration, который таки проверяется? Тоже, и точно можно, опять же, покадровым перебором PTS и frame duration посчитать. Непаханное поле тут на самом деле, если с точной валидацией видео заморачиваться; было бы классно, будь под этот попсовая PHPшная либа, чтобы самому с libav не возиться, но вряд ли. Хотя вот и с libav я пока только https://github.com/PHP-WebRTC/av , которое насколько поддерживаемое? Для Питона вот есть PyAV, а тут, видимо, не всё так просто. Anyhow, это если точность нужна.

> Ну и потом встаёт вопрос, насколько сильно надо заботиться чтобы правильно-правильно все строки там экранировать, чтобы генерация точно-точно всегда работала.
Думаю, стоило бы. BTW, надо ли для config.json простенький inc/func/acid.php, где atomic_read($path) и atomic_write($path, $data) с семафорами и восстановлением? Или просто лочим config.json в manage.class.php при редактировании?

Ещё такой вот вопрос. В config.php к параметрам стоят комментарии и параметры эти разбиты на секции с описанием.

Можно эту схему прямо в config.json, рядом со значениями, добавлять и удалять их в случае чего удобнее, но код для чтения значений в $cf[] будет менее эффективен.
'type': 'section',
'desc': 'Database',
'vars': [
    { 'name': 'KU_DBHOST', 'value': 'localhost', 'type': 'string', 'desc': 'Database hostname' },
    ...
]
Но можно генерировать config.values_only.json. Можно разделить это на config.json, где будут только 'KU_NAME': '014chan' и config.schema.json. Или, как вариант, всю мету над значениями определять и handle'ить прямо в manage.class.php. Что больше нравится?

>>1000502
Уборка тоже хорошее дело же.

Мы точно совсем-совсем не хотим Аобин escape_sql? Я не пользовался (или его ещё тогда не написали? не помню), но можно начать, некое удобство в том, наверное, есть... Хотя вот выпилить KU_DBPREFIX, предположу, с ним сложнее оказалось. Но поддерживать-то вряд ли сложно. Ну, или Аобу же и можно попросить, если контакты остались.

P.S. libav refers to libavcodec and other libav* that are part of FFmpeg to distinguish them from FFmpeg executables. Not to the dead libav fork of FFmpeg.

>>1000507
>Хотя вот размер кадра в картинке у нас проверяется разве?
Ага. Вроде и правда не проверяются. В Вакабе точно есть.
>И надо ли?
Желательно, особенно при увеличенных лимитах на загрузку. Иначе https://github.com/liclac/pngbomb.
Но это только(?) png. С видео проблем быть не должно таких.
Заморачиваться с точностью duration... при наших объёмах постинга наверное непринципиально. Всё запощенное всё равно просматривается, и врушничать с этим мало что кому даст.
При больших объёмах постинга скорее наверное имеет смысл какая-нибудь периодическая батчевая оффлайн-проверка?
>Или просто лочим config.json в manage.class.php при редактировании?
ИМХО flock() должно быть достаточно для этих целей, да. Оно и так должно быть достаточно быстро. В крайнем случае tmpfile->mv.
>config.schema.json
Это лучше и так можно валидировать конфиг перед попыткой его записи (или чтения, или отдельной командой). JSON Schema вполне себе давно стандарт.
>Мы точно совсем-совсем не хотим Аобин escape_sql?
Я его поддержал потому что мне было лень этим заниматься, а ему нет. С момента https://codeberg.org/FBE410/fbe-410/issues/33 прошёл год, и теперь мне не так сильно лень.
Плюс я всё-таки хочу использовать рано или поздно Постгрес, для этого нужен будет PDO в любом случае. И даже без него, prepare->execute->fetch для меня привычнее писать. А там где ты используешь prepare, escape_sql уже и не нужен. Плюс, если его оставлять, то неплохо бы добавить поддержку float, blob, NULL (ни %s, ни %d корректно не данный момент это не обрабатывают), и чтобы %B вызывало аналог Board::verify_board_name мною добавленного а не регексп на [a-z]. Или хотя бы заменить на [^`/], потому что имя борды может быть довольно большим набором символов.
Оно в отдельном коммите, реверснуть дело не хитрое. Выиграет тот кто переведёт все вызовы под свой стиль раньше.

>>1000509
>Иначе https://github.com/liclac/pngbomb.
И вся защита у людей сводится к "не открывайте слишком большие (по количеству пикселов) файлы в памяти", да. Помимо "никогда не запускайте imagemagick на одной системе с сервером и правами сервера".

>>1000509
> https://github.com/liclac/pngbomb.
Аа, вылетело из памяти. Лол.
https://www.kernel.org/doc/gorman/html/understand/understand016.html#htoc101
Теоретически, наиболее вероятно, что по out of memory Линух просто убьёт процесс, который генерируя thumbnail сожрал всю память, а не Apache, MariaDB или что-то важное. Так что интересно, насколько это в действительности страшно. С одной, наверное, не смертельно. С другой, a system running out of memory может тормозить до глюков, и проще вызвать DoS.

>>1000510
> И вся защита у людей сводится к "не открывайте слишком большие (по количеству пикселов) файлы в памяти"
У imagemagick точно нет эффективного thumbnailer-а, который декодирует исходную картинку по частям? Вроде у PNG хранить декодированные линии дальше предыдущей не обязательно. JPEG поделён на блоки 8x8. С I-frames у видео сложнее, там блоки бывают разного размера: WebP top to bottom rendering поддерживает, а вот AVIF нет. Но с AVIF не ясно, потому ли это, что какая-то важная информация хранится в конце файла, или потому, что зависимости между блоками в самых разных частях картинки или ещё что-то сложное.

Насколько целесообразно вместо или совместно с лимитом на пиксели сделать imagemagick'у и ffmpeg'у лимит на память? Через ulimit, systemd-run, timeout или иначе. Заодно и лимит на время поставить? В конце концов, гигантские картинки попросту долго обрабатывать. А в случае, скажем, с JXL — не только гигантские; пока Google поставил на нём крест, но кто знает.

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

> Но это только(?) png. С видео проблем быть не должно таких.
https://litter.catbox.moe/u06p8y4eby61w3gb.avif
20000 по высоте и ширине. 17 килобайтов. AV1 поддерживает размерность до 65536 по одной стороне и 12bpc. Конкретно AVIF также поддерживает прозрачность. К сожалению или к счастью, FFmpeg'овский IMGUTILS при попытке что-то FFmpeg'ом с картинками такого размера сделать или сгенерировать такие размеры фильтрами, говорит, что size invalid, так что продемонстрировать WebM на 20000x20000 не могу. Но можно попробовать найти-поменять захардкоженные константы и рекомпилировать или сделать через aomenc --webm.

BTW, у нас ведь есть поддержка анимированных thumbnail'ов. Lossy WebP не поддерживает yuv444p и позволяет кадры только до 16384 по стороне, но, вполне возможно, закодированными такие кадры тоже достаточно невесомые, чтобы их в одном файле можно было отправить тысячу или две.

>>1000511
Ну, я для демонстрации знакомому докер-процесс прибивал таким. Хотя там ж Докер, там наверняка и общей памяти немного, и он всё равно перезапустится через пять секунд.
>У imagemagick точно нет эффективного thumbnailer-а, который декодирует исходную картинку по частям?
По крайней мере за секунду не гуглится, но есть выставление лимитов если делать через пых, а не сискаллом: https://www.php.net/manual/en/imagick.setresourcelimit.php
>Через ulimit, systemd-run, timeout или иначе.
Можно и так, да.
Но это ж надо напрягаться и помимо админства бордочки из инсталлятора ещё и систему заадминить, ха. Хотя вон Ханабира с vargrant-файлом в комплекте шла. И kusaba.js вообще в Докере.

> https://codeberg.org/yakui-lover/fbe-410/pulls/4
> +9063 -44418
Вот это похудение..

Но пока, наверное, рано?

Пофиксив синтаксические ошибки в api_adaptive.php и inc/classes/randword.class.php, ./vendor/bin/phpstan analyse --memory-limit 8G -cignore.neon -l1 inc lib *.php даёт 34 ошибки.

> ignore.neon
parameters:
    ignoreErrors:
        - '#Function _gettext not found#'
        - '#Function _getText not found#'
        - '#Function _textdomain not found#'
        - '#Function _setlocale not found#'
        - '#Function _bind([_a-z0-9])* not found#'
        - '#Constant KU(_[A-Z0-9]*)* not found#'
        - '#Variable \$.* might#'
    excludePaths:
        - inc/classes/mark.php

Несколько опечаток в названиях переменных/функций.
Часть конструкторов/функций вызывается без нужного количества аргументов или вызывается с большим, чем объявлено.
Часть вызываемых функций пытаются сослаться на переменные (объявленные вне их тела?) (но так и было?).
Часть функций should return .* but return statement is missing (но это потому, что там return в if'е?).
Висит mark.php от Котобы, наверное, стоит удалить.
В posting.class.php в CheckFaptcha на 219-ой "$this->board_class->board_dir" не в {}. phpstan на это почему-то не ругается. Статический Анализатор, лол.
Оставлена финская локаль. (Эйля горячо одобряет.)

Это, наверное, лучше не про сейчас, но что нам даёт gettext такого, чего не даст inc/lang/$locale.json?

>>1000513
>Вот это похудение..
Большая часть всё же от вывода Smarty в подтягиваемую либу.
>Часть вызываемых функций пытаются сослаться на переменные (объявленные вне их тела?) (но так и было?)
Я попробовал прибить везде global, но может быть не везде/часть наследует объявление от импорта.
>что нам даёт gettext такого, чего не даст inc/lang/$locale.json?
Более стандартный интерфейс, наверное? Но так как мы и так используем либу вместо встроенного, то как удобнее.
Но жсон-вариант я ещё ни разу не видел.

С qutebrowser(который webkit) постоянно Old faptcha is old. Please renew, и не важно включены кукисы\жава или нет.

>>1000515
Без печенек оно работать и не будет, да, оно через PHPSESSID ведётся.
Проверьте после включения и прокликивания фапчи что оно у вас выставляется и не сбрасывается в новое значение после попытки постинга?

>>1000516
Сработало после смены content.cookies.accept never на no-3rdparty.
А нельзя ли его без кукисов заставить работать?

>>1000517
Можно. Переписав механизм работы с PHPSESSID на БД. Только у вас тогда будет отваливааться капча при смене айпишника.
Заниматься я этим ближайшее время, конечно же, не буду.

>>/b/1005072
Спойлеры в (18837, 18840, 18841, 18965, 19000, 19021, 19022, 19030, 19033, 19048, 19067, 19074, 19084, 19102, 19109, 19158, 19167, 19182, 19216, 19259, 19282, 19291, 19325, 19373, 19392, 19429, 19432, 19451, 19456, 19475, 19480, 19501, 19524, 19551, 19557, 19558, 19559, 19577, 19581, 19585, 19599, 19602, 19603, 19642, 19691, 19692, 19716, 19825, 19836, 19846, 19927, 19929, 19931, 19933, 19935, 19936, 19941, 19942, 19944, 19961, 19995, 20020, 20028, 20037, 20038, 20039, 20041, 20043, 20044, 20051, 20055, 20057, 20059, 20080, 20082, 20085, 20087, 20090, 20092, 20093, 20109, 20112, 20122, 20123, 20125, 20126, 20128, 20129, 20130, 20144, 20148, 20150, 20152, 20157, 20162, 20165, 20166, 20167, 20173, 20174, 20178, 20201, 20219, 20254, 20301, 20307, 20319, 20322, 20334, 20355, 20359, 20417, 20425, 20435, 20437, 20443, 20445, 20447, 20459, 20506, 20557, 20565, 20571, 20575, 20577, 20579, 20587, 20589, 20597, 20605, 20607, 20608, 20613, 20628, 20644, 20647, 20648, 20668, 20673, 20683, 20686, 20688, 20696, 20697, 20715, 20717, 20718, 20720, 20741, 20745, 20748, 20756, 20783, 20848, 20852, 20887, 20913, 20993, 20994, 20998, 21006, 21026, 21058, 21070, 21072, 21105, 21106, 21151, 21154, 21161, 21164, 21191, 21267, 21277, 21292, 21298, 21315, 21350, 21370, 21404, 21406, 21477, 21490, 21494, 21546, 21557, 21579, 21630, 21641, 21654, 21733, 21749, 21750, 21808, 21814, 21844, 21910, 21911, 22031, 22039, 22158, 22174, 22179, 22270, 22279, 22310, 22316, 22317, 22318, 22319, 22370, 22376, 22427, 22435, 22454, 22455, 22579, 22595, 22617, 22619, 22626, 22637, 22643, 22670, 22679, 22684, 22697, 22714, 22715, 22720, 22721, 22722, 22759, 22764, 22765, 22766, 22767, 22770, 22777, 22781, 22782, 22785, 22787, 22789, 22794, 22796, 22797, 22813, 22821, 22826, 22833, 22834, 22841, 22851, 22852, 22860, 22876, 22884, 22890, 22891, 22900, 22927, 22928, 22929, 22931, 22940, 22943, 22973, 22974, 22993, 22994, 22996, 23001, 23002, 23003, 23004, 23005, 23012, 23023, 23042, 23043, 23044, 23045, 23046, 23051, 23052, 23053, 23054, 23055, 23073, 23108, 23117, 23134, 23140, 23141, 23152, 23184, 23190, 23191, 23226, 23228, 23231, 23282, 23303, 23347, 23352, 23364, 23402, 23413, 23417, 23427, 23514, 23516, 23521, 23553, 23575, 23606, 23615, 23694, 23698, 23707, 23716, 23793, 23796, 23839, 23870, 23885, 23886, 23887, 23890, 23903, 23904, 23923, 23969, 23975, 24081, 24146, 24153, 24156, 24163, 24165, 24170, 24173, 24218, 24250, 24276, 24285, 24295, 24300, 24360, 24367, 24368, 24445, 24490, 24496, 24553, 24574, 24588, 24589, 24616, 24628, 24690, 24776, 24845, 24909, 24947, 24958, 25098, 25099, 25100, 25101, 25109, 25117, 25133, 25134, 25135, 25201, 25242, 25336, 25342, 25347, 25354, 25357, 25378, 25453, 25454, 25472, 25500, 25585, 25586, 25597, 25646, 25647, 25684, 25833, 25875, 25876, 25896, 25905, 25915, 25918, 25923, 25951, 25956).

На булочке был удалён файл в >>/b/25341.

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

Похоже, что пересоздание страниц не пересоздаёт thumbnail'ы. >>/b/25864. Наверное, стоит удалить их для файлов, запощенных на Булочке за последние несколько месяцев, и перегенерировать страницы.

>>1000526
>пересоздание страниц не пересоздаёт thumbnail'ы
С чего бы оно это делало, уменьшенная копия генерируется всего один раз, при загрузке.

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

Thumbnail'ы параметризуются по размеру и анимированности. На случай изменения этих параметров какой-то механизм для регенерации мог бы быть. Или если corruption случится.

BTW, где-то на задворках сознания у меня крутится идея провести реформу thumbnail'ов: сейчас артефакты сжатия бывают довольно заметны при увеличении интерфейса до удобочитаемости на моём ноутбуке. Увеличить s'кам качество. Перевести, может, все thumbnail'ы на WebP. Взять более медленный метод сжатия, чем сейчас. Сделать, чтобы как и в случае с PNG, для VP8L thumbnail'ы тоже были lossless. Или PNG перевести на lossy? I wonder.

>>1000517
Если без кукисов и не по IP, то разве что скриптами. Видится два варианта и как-то так:

Первый будет загружать JS'ом капчу, сохранить PHPSESSID в переменной и добавлять его в cookie при отправке. Можно user script'ом. Как понять, когда PHPSESSID всё, а клиент думает, что оно живое? Dunno, но, скорее всего, можно.

Второй — шлём вместе с капчей шифрованный на неё ответ + timestamp, по успешному решению возвращаем токен на постинг с закодированным timestamp'ом. Но тогда проще вайпать, ибо таких токенов на постинг можно намайнить тьму, и не очень понятно, как без IP вести какой-то контроль за их выдачей/аннулированием. Вводить PoW? От атакующего, арендовавшего десяток EPYC'ов, не спасёт. Хотя от такого атакующего текущая защита всяко инвалидна; тут разве что по аномалии вводить белые списки IP на постинг.

У PHPSESSID же скорее всего есть какие-то ограничения на количество на IP и количество в целом. Таким образом, если привязывать капчу только к IP, то легче установить, есть ли другая ойчанька с тем же IP, чем если оставить всё, как оно есть.

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

Из JS-функционала про капчу, который действительно стоило бы запилить, мне видится синхронизация капчи между вкладками: чтобы по открытию новой вкладки с формой постинга, капча на других вкладках обновилась ею. Иначе открываешь в процессе чтения треда А тред Б, возвращаешься к треду А, пишешь туда ответ, а тебе говорят, что капча не правильная.

Ещё, для фапчи сделать, чтобы при JS постинге ответ на неё отправлялся отдельно--без поста с файлом в 10 MiB.

ЖС это глупость. Не стоит на неё лочить функциональщину.

Некоторые патчи к текущему HEAD'у dev ветки.

Дальше попробую заставить ссылки на посты работать; проблемы и с постингом, и с read.php. Наверное, уберу таки Inter(board|thread)QuoteCheck, по проверке поста на существование, сделаю post link через formatQuote, которое пока игнорирует KU-традиционный-что-то-там и тип борды.

С read.php, стоит ли его упростить, убрав неиспользуемый функционал для чтения множества постов?

>>1000533
Ну, раз у меня развязаны руки экспериментировать и дальше, то можно и в /dev/.
>С read.php, стоит ли его упростить, убрав неиспользуемый функционал для чтения множества постов?
Хмм. У меня есть подозрение что оно ещё может использоваться на текстодосках. Как-нибудь.
Я в выходные приму патч и ещё поиграюсь с предлагаемым phpstan, да.
Если интересно, я тестирую на кусаба.якуж.мое.

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

>>1000528
Но тогда это и не импорт. Meh. А если это и не импорт, а что-то лучшее, то можно и домен обратно на 0141 или котокафе или вообще правила править.

>>1000529
Можно ещё всю форму ответа сделать на динамике, чтобы она шла с айдишником капчи в скрытом поле.
>Ещё, для фапчи сделать, чтобы при JS постинге ответ на неё отправлялся отдельно--без поста с файлом в 10 MiB.
Формально, и текстовая капча может быть адаптивной, и фапча неадаптивной. Но ЕМНИП это указывается или в печеньках или в коде страницы.

>>1000534
> У меня есть подозрение что оно ещё может использоваться на текстодосках.
Вряд ли. Когда-то может и использовалось — когда (судя по getQuoteIds) через запятую можно было указать несколько постов, но ни у Соуса, ни у нас в parse.class.php такой ввод not recognized. Только в *QuoteCheck функциях и по разным файлам частично код для поддержки остался. Проще окончательно выпилить. Понадобится, тогда уже и думать о добавлении.

> можно и домен обратно на 0141 или котокафе
Хотел было написать, что by this point я не очень против, но есть следующие возражения. Баннеры у нас по большей части про 014 — в частности, и те несколько, которых нет на Булочке. Ещё, во избежание конфуза с доменами, возможно, лучше оставить как есть. Кто-то было жаловался, что что-то с индексированием у поисковиков случилось по прошлой смене домена.

> или вообще правила править
Есть какие-то соображения по? Наготу без спойлера разрешить?

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

> Можно ещё всю форму ответа сделать на динамике, чтобы она шла с айдишником капчи в скрытом поле.
Indeed. Жаль, что HTML imports не живы. Судя по всему, было непродолжительное время, когда через <template is=""> и <link href="postform.php"> можно было бы такую динамику и без JS, и без embedded PHP сделать.

PHP внепланово обновлён до 8.4.

>>1000543
> The uploaded file exceeds the upload_max_filesize directive (2M) in php.ini.

Also, делали ли какие-либо правки после применения патчей? Или, когда я починю ссылки, можно спокойно к 0010-Fix-autoformatter-messed-up-vars-declarations присылать?

>>1000545
Ещё нет.
Присылайте, мерж-конфликт исправить не сложно.

>>1000544
И вроде пофикшено.
Зря оно не пытается конфиг скопировать, хм.

>>1000539
>Проще окончательно выпилить.
Тогда согласен.
>Кто-то было жаловался, что что-то с индексированием у поисковиков случилось по прошлой смене домена.
Можно впилить обратно поиск, ха. Только в dev он уже почти выпилен.
>Есть какие-то соображения по?
Ну или явно запретить если без спойлера. Добавить пару слов о главенстве формы над содержанием, что как бы более явно разрешит писать о большем, чем. В то же время явно вписать разжигание политики в правила.

В set_inputs скобку забыли у getCookie() вызова.

>>1000549
fixed.

>>1000550
> {el.value = getCookie('name'}
Иие. Скобка не на том месте добавлена.

>>1000551

Tfw всё так >>/b/1005149 и случилось.