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
Пейнт считал что жпег, и даже сохранял в нем изменения >_>

>>26888
Paint, как и многие другие программы, при открытии файла смотрит на первые его байты и по ним определяет формат картинки. То есть, скорее всего, Paint открыл ваш PNG файл с расширением .jpg, посмотрел на первые его байты, и справедливо посчитал, что он PNG, и сохранил изменения в вашем файле с расширением .jpg как PNG. FBE (Кусаба) написан так, что соответствие расширения файла его фактическому формату необходимо. А Paint нет.
Бывают такие случаи. >>/d/2636

Постовайте файл на https://catbox.moe, посмотрим.

>>26889
Вы оказались совершенно правы, по сигнатуре файл PNG, а расширение - JPG. Стоило сразу посмотреть, спасибо за разъяснение.

Посмотрел исходник и сблевал от смеси логики с HTML в виде строк с тегами и ` = ".mysqli_real_escape_string

Мало того, что это вредит стилю и читаемости кода, так это ещё вредит безопасности и производительности.

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

>>26907
Блевать все умеют, а переписывать код — никто.

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

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

Добавил забытый баг из предыдущей нити: https://bitbucket.org/Therapont/fbe-410/issues/54/suspend

Лично моего опыта для рѣшенія проблем >>26911 не хватает, поэтому я просто воздерживаюсь и от установки FBE, и от сочинения такого кода FBE, провѣрка которого требовала бы именно установки FBE, а не подобных >>/dev/20224 средств и не «тут и так понятно, провѣрять нечего».

Реквестирую https://bitbucket.org/Therapont/fbe-410/pull-requests/77 для учёта возможности неsRGBшной цвѣтности (контуры которой сообщениями >>/b/196588 и >>/b/199138 и их обсуждением намѣчены) примѣнительно к миниатюрам (thumbnails).

Попутно улучшил развёртыватель миниатюр.

>>27043
А наличие в репозитории докер-файла для поднятия FBE помогло бы?

>>27066

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

Они ж не ставятся на Windows 7.

А ни у кого не сохранились скрипты на пикрелейтед?
В старом треде за 2017 год только пастбины протухшие.

Я рад видѣть запрос >>27058 удовлетворённым недѣлю назад (и исходный код вмёрдженным) — однако, наперёд терпеливо подождав недѣлю, теперь с любопытством поинтересýюсь: а когда эти правки кода собираетеся накатить непосредственно на 410чан? Есть какие-нибудь планы?

Вижу, что исходный код пошёл въ дѣло.

Спасибо.

Разработка движка в целом померла, но я завёл новую задачу: https://bitbucket.org/Therapont/fbe-410/issues/55/

Сообщение >>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чане? — вопрос не риторический, я это всерьёз спрашиваю.

>>27133
Я предполагаю, что в последующие недели или месяцы на сервере будет обновлён «Дебиан», тогда и будем смотреть, что там поддерживается. Сроков обновления пока нет. Спрашивать их не надо.

Чувствую, что для пользы дальнѣйшаго тестирования не помѣшалъ бы примѣръ такого AVIF, который был бы:

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

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

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

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

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

В эту старую ветку (в отличие от ImageMagick 7) ужé никто и никогда не станет впиливать поддержку новых форматов, и это не одного только AVIF впрямую касается, но и JPEG XL также. Никогда, никогда!

Кажется, fbe на php8.2 который теперь в debian stable по умолчанию, работать не будет.

https://bitbucket.org/Therapont/fbe-410/issues/56/php-8
Завёл задачу по обновлению движка под ПХП 8.2. Движок оказался совсем неработоспособен, чтобы его своими силами быстро починить, так что помощь не просто приветствуется, но всячески необходима.

https://www.php.net/manual/en/migration80.incompatible.php

По адресу https://t.me/exploitex/8944 встрѣтилося упоминание того, что вскорѣ «Битбакету» настанет кирдык.

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

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

>>27169
Лично мне такая лабуда не приходила пока.

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

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

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

Суманъ.

На данный момент все существующие внутренние наработки по переходу на новую версию ПХП доступны в репозитории. Оно по большей части работоспособно, но нужно тестирование; из известных проблем — сломаны предупреждения. В ближайшее время обновлений не будет, видимо.
Если кто-то соберётся новые пулреквесты по этой теме делать, учитывайте это.

>>27179
А когда новая версия PHP выйдет и опять что-то сломают, по новой переписывать всё? Вот уж действительно неблагодарная работа. Лучше уж один раз переписать на языке, где заботятся об обратной совместимости.

>>27202
>на языке, где заботятся об обратной совместимости
C, Common Lisp? Какие ещё варианты?

>>27206
Приходят на ум JavaScript/TypeScript, Java, Go.

С Python ситуация интересная, в пределах мажорной версии не ломают совместимость, при переходе с 2 на 3, конечно, поломали. Но при этом Гвидо заявляет, что Python 4 может не выйти никогда (https://builtin.com/software-engineering-perspectives/python-4). Поэтому включу в список Python 3.

>>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 в этом плане ситуация получше, но не знаю, так ли это на самом деле, и насколько лучше.

>>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

Свалите флудить в другую нить.

>>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 не будет.

Поскольку произошло описанное в >>27169, репозиторий переехал на https://codeberg.org/FBE410/fbe-410