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

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

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

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

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

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

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

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

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

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

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

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

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

18
24
34
41

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

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

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

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

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

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

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

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

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

>>26185
Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Справитесь?

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

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

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

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

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

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

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

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

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

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

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

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

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

>>26667

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>26682

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

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

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

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

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

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

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

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

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

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

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

>>26680

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

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

>>26680

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>26728
*борду

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>26870

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

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

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

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

410chan

.

posts_b

.

thumb_w

at row 1

>>26879

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

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

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

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

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

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

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

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

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