>>20445

> вы можете отослать PR

Вообще-то BitBucket не даёт мне сделать это (скриншот прилагаю) по отношению к репозиторию «891raba».

Однако коммит у меня по адресу https://bitbucket.org/Mithgol/fbe-410/commits/63e06dbffef04c9c30fea721a9b3fe4c94af06f1 подготовлен.

Соответственно, либо владелец репозитория «891raba» сам зафетчит ветвь «webm» из моего репозитория и затем станет мёрджить её к себе в одноимённую ветвь, либо, наверное, владелец репозитория «Therapont» получит от меня PR в ветвь «public» с течением времени (после того, как запрос https://bitbucket.org/Therapont/fbe-410/pull-requests/15 будет принят).

Других путей я пока что не вижу, так как не особенно знаком с Битбакетом.

>>20452
А~ попробуйте ещё раз PR сделать? Я сам битбакетом второй раз в жизни пользуюсь, но вроде подкрутил нужные настройки. Не выйдет так через час сам возьму.

>>20453

А не вышло. Снова та же ошибка.

Некоторые реплики на форумах (и на Atlassian, и на StackOverflow) вроде как говорят, что и вообще это нипочём не преодолимая проблема — на BitBucket делать pull request из форкнутого репозитория не в него же и не в направлении первоисточника форка. Конструкцией, дескать, не предусмотрено.

(Может и врут, не знаю.)

>>20454
Выцепил и применил патч сам. Благодарю за содействие.

>>20455

Очень хорошо.

Слѣдующая моя мысль в том же направлении состоит в том, что сейчас у нас дѣйствуетъ такой развёртыватель миниатюр, который миниатюры аудиофайлов развёртывает до состояния звукопроигрывателей (что можно посмотреть, например, в репликах >>18692 и >>18702 и >>18703), поэтому заблаговременное формирование аудиопроигрывателей (особенно основанное на SWF Google) ни к чему, поэтому его уместно отпилить вместе с настройками.

Практическим выражением этой мысли служит коммит https://bitbucket.org/Mithgol/fbe-410/commits/d09547dfecb628c34251a81996a2e2c30ece35f2

>>20456
Принято, но таким образом тип 'audio' не несёт никакой нагрузки, кроме разве смысловой. Может стоит его удалить тогда?

>>20458

Очень хорошая мысль!

Некоторое время думал над заданным в реплике >>18814 вопросом о смысле изложенного в реплике >>18805 намерения ограничивать на 410чане не один только объём файла, но также и длительность видеозаписей.

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

Это то самое и есть, о чём я в реплике >>19601 упоминал: 19 марта по адресу https://iichan.hk/d/res/244600.html#245388 на Ычане сказано было, что если звукозаписи MP3 или Opus не давать публиковать, то вместо них явятся такие MP4 и WebM, у которых каждым кадром дана обложка альбома, а звуковая дорожка (в формате AAC для MP4 или в формате Opus для WebM) прилагается та самая, которую нужно послушать.

И сбылось буквально. (Именно такого рода файл WebM можно по адресу https://iichan.hk/a/res/1403230.html#1407488 видеть, и он там вот ужé никак не менее двух недель кряду.)

Но, разумеется, если бы на Ычане было не только ограничение размера (не более 4096 килобайтов), но также и ограничение длительности, то никак нельзя было бы 4 минуты 25 секунд опубликовать — даже вышеозначенным способом нельзя бы было. И это, по-видимому, то самое и есть, к чему намерение >>18805 сводится: устроить такое ограничение на 410чане.

А иначе к чему бы это? — только к этому, понятно же.

Продолжая изложенную автором реплики >>18170 и автором реплики >>20325 мысль о возможности брать пример с расположенного по адресу https://gitgud.io/devarped/instant-0chan репозитория, мне хочется дополнительно упомянуть и о том, что по адресу https://kurisa.ch/sg/res/15697.html и https://kurisa.ch/sg/res/32736.html и https://kurisa.ch/sg/res/48357.html велось обсуждение доработок в другом ещё движке, который назван «Курисаба» (в честь Макисэ Курису из аниме и визуального романа «Steins;Gate» и их сиквелов) и который основывается (если только можно поверить изложенному в реплике https://kurisa.ch/sg/res/32736.html#42134 мнению) «на инстант-нульче, который, в свою очередь, на кусабе х». И упоминаю.

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

Ни с какими.

В реплике >>20450 сказано же, что улучшения будут «при наличии у администрации свободного времени на это», ну дык вот за прошедшую неделю не нашлось свободного времени на это, даже в выходные дни, так надо думать.

Ждём дальше.

>>20469

+1.

Соусовый аудиоответ на вопрос >>/b/134916 прилагаю.

>>20485
Печаль, поддержка видео это очень весомый апдейт для нашего движка, и чана вообще. Например, можно было бы в /а/ и /ts/ создать тред с шебмками и инструкцией по их созданию средствами ffmpeg, и обмениваться там клипами и опенингами. Чуваки в /cu/ могли бы какие-то элементы готовки на видео записывать и выкладывать, урбанисты в /ci/ - урбанистику. В /dev/ бы можно было демонстрции игровых проектов делать правда у нас активно идет разработка только визуальных новелл, не ясно что там показывать на видео

>>20486
А на практике этим будут пользоваться полтора человека.

>>20487
Скажу больше: на деле это превратит Автобус в кладбище репостов смищных видосиков и музыки.

>>20486 >>20488
Пассажир в те же 5 Mib сможет засунуть значительно больше видео в лучшем качестве, нежели в gif. Это хорошо ведь. Пассажиру не нужно будет перекодирывать видеофайлы в gif, он сможет постить их как есть. Это замечательно же. Посетителям иных досок тоже лучше будет, наверное, обитателям /a/ уж точно.

>>20488
По этой логике Автобус бы уже давно был кладбищем смешных картинок и музыки (картинки и музыку-то прикладывать движок давно умеет)

>>20490

Движок действительно умеет прикладывать музыку, однако в b/ эта возможность отключена, так что только гадательно можно утверждать, обрела бы в этом разделе широкую популярность практика репостов музыкальных файлов, или не обрела бы, или сперва обрела бы, а затем была бы пресечена модерациею.

И когда возможность публикации WebM появится, то это ещё вопрос, будет ли она во всех разделах включена, или только в одном-двух.

>>20486

> создать тред с шебмками и инструкцией по их созданию средствами ffmpeg

Не поможет.

Версия >>20487 более всего вероятна.

Для примера можно указать, что в реплике >>19332 и в ряде последующих реплик была дана инструкция по созданию GIFов, но создаёт ли GIFы кто-нибудь, кроме меня? — многие считают, что нѣтъ; напримѣръ, въ репликѣ >>/b/134609 появление GIFа у реплики было буквально названо той чертой, по которой меня можно отличать от других в тех разделах, где анонимность принудительна.

> можно было бы в /а/ и /ts/ (…) обмениваться там клипами и опенингами

> элементы готовки на видео записывать и выкладывать

> урбанистику

> демонстрации игровых проектов делать

Мрачно подозреваю, что для этого мало и недостаточно будет встроить публикацию WebM в движок и даже мало будет разрешить такую публикацию въ нѣкоторомъ раздѣлѣ.

Публикаторы будут упираться в ограничение по объёму файла, будут упираться (если подозрение >>20467 справедливо) и в ограничение по времени.

Не может, например, в /ts/ быть никакого оупенинга в нормальном качестве (и не будет) до тех пор, пока там ограничение объёма файла остаётся двухмегабайтовым. Потому что частное от деления тех двух мегабайтов на 90 секунд (так как типичная длина оупенинга бывает именно девяностосекундною) равняется почти точно 182kbps. Для упомянутого в реплике >>20467 «звукового видеоформата» (обложка + звуковая дорожка) может и хватить, а для «нормального» видео — отнюдь нѣтъ.

То есть небольшое улучшение произойдёт (где было несколько секунд небольшого GIF, там будет десяток-другой секунд FullHD WebM в не особенно даже вырвиглазном качестве), однако «не стоит излишне пропихивать всякие там революционные идеи».™

>>20494
>въ репликѣ >>/b/134609 появление GIFа у реплики было буквально названо той чертой, по которой меня можно отличать

Не-не-не-не-не. Так не пойдёт. Было упомянуто появление не некоторого GIF, а большого и тяжёлого GIF с артефактом-мозаикой (как он, артефакт этот, правильно называется, кстати?). Есть разница. Например, эта мозаика отсутствует или менее заметна в следующих постах с GIF: >>/b/133840, >>/b/134764, >>/a/14742, >>/b/93844. Именно по этому артефакту и проще всего отличать.

>создаёт ли GIFы кто-нибудь, кроме меня?
Я.

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

>>20496
>на отрывки самостоятельно
fixed

>>20494
>только гадательно можно утверждать, обрела бы в этом разделе широкую популярность практика репостов музыкальных файлов, или не обрела бы, или сперва обрела бы, а затем была бы пресечена модерациею.
Ну, в /б/ уже существует тред обмена музыкой, и там обмениваются ссылками на музыку. Была бы возможность прикладывать - её бы просто прикладывали. И думаю за рамки этого оно бы не вышло. И учитывая что это 410й, обычно делятся чем-то интересным.

>Не может, например, в /ts/ быть никакого оупенинга в нормальном качестве (и не будет) до тех пор, пока там ограничение объёма файла остаётся двухмегабайтовым.
Есть какие-то объективные причины, по которым с учетом скорости постинга в /ts/, максимальный размер файла не может быть поднят до 5-8-10 мегабайт? Вроде ж в современных условиях диск ничего не стоит. Трафик может стоить больше, но опять же, не так много людей сюда заходят.

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

>>20496
Я думаю что имеется в виду, что не-техническим людям сложно ковыряться в энкодинге и реэнкодинге видео. Можно конечно для них сделать батничек / шелл-файл, который бы в интерактивном режиме помогал просто создавать видео, с учетом ограничения размеров постинга на досках. Т.е. перетаскиваешь на такой батничек файл, и он тебя интерактивно проводит по этапам, выберите доску, укажите время начала, укажите время конца (длительность), оставить / убрать звук, и дальше потом оптимизирует источник по разрешению и битрейту самостоятельно, с учетом ограничения доски. Это бы сильно упростило создание видеоконтента и постоянные посетители могли бы пользоваться, но сколько стало бы пользоваться фактически - вопрос. Впрочем, если идея интересна можно попробовать просто сделать, и посмотреть что будет.

>>20488
Вообще, тут переживают за контент так, как будто у нас посещаемость макача, и если аудитория что-то может сделать, то она обязательно сделает. А на самом деле у нас практически несуществующая аудитория, большинство которой состоит из постоянных многолетних постеров, не забаненных за все это время модерацией сайта, и не ушедших полностью на более посещаемые ресурсы. Т.е. во-первых можно изначально надеяться на то что описанный сценарий находится вне интересов нашей аудитории потому что если вы хотели смешных картинок и вебемок, зачем вы сидите на 410м, где их почти нет? Во-вторых, как и с любым другим контентом который не нравится модерации, если модерации он не понравится, она за него просто забанит, а контент удалит. Так что даже если сюда каким-то чудом попадет коварный репостер вебемочек данкест мемес, то он скорее всего быстро получит бан, после чего пойдет постить куда-то еще.

Ещё раз вгляделся (на сей раз в том коммите, который по адресу https://bitbucket.org/Therapont/fbe-410/commits/3355e9e1bb4bc267b6c21d3a6962cbfd993790ef расположен) в те правки, которые должны принести нам возможность употребления WebM.

В файле inc/classes/manage.class.php на строке 282 увидел код «<option value="image">Audio</option>».

Много думал.

Не следует ли в духе реплики >>20458 отпилить этот код оттуда?

Если же это почему-либо не удобно, то нельзя ли хотя бы атрибуту «value» придать значение «misc» вместо «image»?

>>20498

> Есть какие-то объективные причины, по которым с учётом скорости постинга в /ts/, максимальный размер файла не может быть поднят до 5-8-10 мегабайт? Вроде ж в современных условиях диск ничего не стоит. Трафик может стоить больше, но опять же, не так много людей сюда заходят.

Этак можно спросить по аналогии: есть ли какие-то такие объективные причины, по которым с учётом скорости постинга (главным образом — моего постинга) максимальный размер файла не может быть поднят до восьми или десяти мегабайтов в dev/? Нетрудно догадываться, что такие причины имѣются, коль скоро всѣ мы видимъ вꙭчію: максимальный размер файла не только не был поднят, но даже наоборот — он опущен был с 10 мегабайтов до 5 мегабайтов, то есть сразу вдвое. На этом примере приходится увидеть, что рассуждения о возможности пренебречь стоимостью объёмов диска и траффика оказались далековаты от истины, а были какие-то ограничения, и чтобы в те ограничения упереться, даже полутора человек >>20487 не потребовалось, а хватило и одного меня.

(В качестве наглядного сравнения я напоминаю, что чуть менее двух месяцев тому назад в примерно аналогичном обсуждении на Ычане по адресу https://iichan.hk/d/res/244600.html#246336 прозвучал упрёк «за сервера не вам платить», в ответ которому прозвучало несколько вариантов приглашения устроить механизм целевых денежных пожертвований, прямо привязанных к увеличению ограничения размера видеофайлов, но к ним ровным счётом никто не прислушался: так и остаётся для тамошнего /a/ не более четырёх мегабайтов, а для b/ и вовсе не более трёх.)

Есть ли какие-то такие объективные причины, которые администрацию 410чана удерживают от того, чтобы максимальный размер файла уменьшить до ычановских трёх-четырёх мегабайтов (или даже сразу вдвое — до 2500 килобайтов, а в ts/ до 1000 килобайтов, а в cu/ до 500 килобайтов) одновременно с внедрением WebM?

>>20502
Мне кажется нет смысла внедрять WebM, если вместе с этим вводить такое устаревшее ограничение на размер файла. Хотя может кому-то бы и так было в радость.

Кстати, движок 410го случайно не в базу все файлы загружает? Может в этом и основная проблема? Тогда можно было бы относительно просто отучить движок так делать и хранить в базе только ссылку на файл.

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

Ну, если применительно к нашему чану, то самое простое - открыть Патреон, где будет написано "Администрация 410го чана развивает площадку для анонимного творчества и общения", а увеличение максимального размера файла оформить там как goal, который достигается по определенному количеству пожертвований. Соответственно, прочие улучшения качества жизни туда можно внести тоже. Самое удобное в патреоне для чанеров, что делать пожертвования можно анонимно. Самое удобное в патреоне для администрации, что кушать он не просит, его просто как открыть, так и закрыть. Зато раз и на всегда можно исключить спекуляции на тему "хочет кто-то пожертвовать на автобус на самом деле или нет", если уже даже с таким простым способом не будут, то точно не хотят. И как бы никто ничего не теряет, наоборот все получают возможность улучшить своё качество жизни на автобусе.

Это нить про разработку движка, а не для порожнего флуда о лимитах и прочей работе сайта.
Упырьте мел.

>>20503

> Кстати, движок 410го случайно не в базу все файлы загружает?

1) Нѣтъ. Код открыт, там это видно.

2) Особенной проблемы бы и не было. В зависимости от используемой базы данных, как оказывается, хранение файла в базе может быть даже эффективнее, чем в файловой системе. Например, для базы SQLite подсчёт https://sqlite.org/fasterthanfs.html показывает тридцатипятипроцентный рост эффективности. (Правда, Кусаба/FBE использует MySQL, а не SQLite, а для MySQL я аналогичных подсчётов не видывал.)

>>20496

> GIF с артефактом-мозаикой (как он, артефакт этот, правильно называется, кстати?)

Есть два рода мозаики в тех GIF, которые я публикую на 410чане: мозаика на самóм GIFе и мозаика на его миниатюре.

Мозаика на самóм GIFе представляет собою классическую байеровскую матрицу 8×8 пикселов, которая была предложена Байером сорок пять лет тому назад (в 1973 году) в качестве средства, позволяющего использовать строго определённую мешанину точек двух различных цветов для отображения других цветов, промежуточных между этими двумя.

Первоисточник можно найти по адресу https://web.archive.org/web/20130512190753/http://white.stanford.edu:80/~brian/psy221/reader/Bayer.1973.pdf в Архиве Интернета. (Посканирован он очень хреново, поэтому качество иллюстраций в действительности не отражает настоящее качество достижения Байера.)

По адресу https://en.wikipedia.org/wiki/Ordered_dithering в Википедии находится статья, кратко пересказывающая суть. В настоящее время предпоследний абзац этой статьи гласит: «Additionally, because the location of the dithering patterns stays always the same relative to the display frame, it is less prone to jitter than error-diffusion methods, making it suitable for animations. Because the patterns are more repetitive than error-diffusion method, an image with ordered dithering compresses better» — что означает: «Кроме того, так как расположение узоров диѳеринга всегда остаётся тем же относительно границ кадра, то по сравнению с методами диффузии ошибок они менее склонны вызывать джиттер, что делает их более пригодными для анимаций. Так как узоры являются более повторяющимися, чем результаты метода диффузии ошибок, то изображения с такими узорами лучше сжимаются». (В этом тексте словом «джиттер» называется тот неприятный и раздражающий эффект, проявляющийся при некоторых методах использования точек двух различных цветов для отображения других цветов, промежуточных между этими двумя, который выглядит как склонность пиксела, в первоисточке имевшего промежуточный цвет, во время анимации от кадра к кадру быстро переключаться между этими двумя цветами, что выглядит как «поблёскивание», будто «рябь на воде» и проч. Этот эффект раздражает главным образом тем, что ввиду своей заметности отвлекает на себя изрядную часть внимания зрителя, которую совершенно не заслуживает, так как в первоисточнике отсутствует.)

Того же мнения насчёт «лучше сжимаются» держится и тот рецепт 2015 года, по адресу http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html расположенный, на котором основаны изложенные в реплике >>19332 (и в некоторых дальнейших репликах) мои рецепты изготовления анимированных GIFов посредством FFmpeg. Про методы, основанные на диффузии ошибок (а не на байеровских узорах), там сказано: «While this often provides a much better quality, it completely kills the compression of GIF» — что означает: «Хотя она нередко обеспечивает гораздо лучшее качество, она совершенно убивает сжатие GIF».

Использование байеровского подхода позволяет мне при создании довольно крупных GIFов (нередко имеющих размеры в районе HD или даже FullHD) удерживать их объём внутри 410чановского ограничения, равного 5000 килобайтов (ранее — внутри 10000 килобайтов), чему в архиве обсуждения http://410chan.org/dev/arch/res/17371.html нашлось бы (ближе к концу его) не менее четверти сотни примеров, кабы всѣ они не были уничтожены администрациею (движимою, по-видимому, желанием высвободить около четверти гигабайта жизненного дискового пространства на сёрвере).

Размер байеровского узора, FFmpeg используемого, согласно https://ffmpeg.org/ffmpeg-all.html#paletteuse равен 8×8 пикселов.

Что же касается гораздо более уродливой мозаики на тех миниатюрах, которые Кусабою/FBE создаются из таких GIFов, то это явление не имеет даже названия, а его первопричина заключается в чрезмерном принесении качества в жертву скорости — эта жертва более подробно рассмотрена в реплике http://410chan.org/dev/arch/res/17371.html#19336 и восьми последующих. Устранению этого эффекта я посвятил расположенный по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/12 запрос, суть которого состоит в том, чтобы движок Кусабы/FBE на 410чане не сам тщился создавать миниатюры, а перепоручал бы это занятие опять же в FFmpeg (раз уж FFmpeg на сёрвере 410чана всё равно будет поставлен ввиду необходимости внедрения WebM). Этот мой запроc 5 августа был принят администрацией 410чана, но с той поры не был ещё внедрён непосредственно на сёрвер 410чана, а остаётся на проверке у администрации.

Упомянутое в реплике >>20517 благотворное влияние узоров Байера на сжимаемость GIFов постепенно сходит на нѣтъ по мѣрѣ уменьшения размеров GIFа, а замѣтность узоров, наоборот, возрастает (квадрат 8×8 занимает меньше одной тридцатидвухтысячной доли площади кадра FullHD 1920×1080, однако по отношению к кадру 320×180 займёт ужé одну девятисотую).

Соответственно, в тех случаях, когда принятое на 410чане ограничение объёма файла (до 5000 килобайтов, а в ts/ до 2000 килобайтов, а в cu/ до 1000 килобайтов) принуждает укладывать некоторые GIFы на прокрустово ложе менее 200 пикселов высотою (во имя сохранения многосекундной продолжительности таких GIFов необрезанною), можно и отказаться от узоров Байера в пользу диффузии ошибок по методу https://en.wikipedia.org/wiki/Floyd–Steinberg_dithering (который был предложен Флойдом и Штейнбергом в 1976 году). Этот их метод использует заметно «мелкозернистую» (3×2) мешанину пикселов и оттого создаёт ощущение более высокого качества тонких деталей изображения по сравнению с «крупноузорчатым» (8×8) байеровским, но вместе с тем для двухсотпиксельных (и меньших того) GIFов всё же создаёт файл либо не особенно большего размера (так что ростом размера можно и пренебречь во имя качества), либо даже несколько меньшего размера (что само по себе повадно). Примером этого подхода могут послужить анимации, приложенные к репликам >>20502 и >>/b/135340.

И так как миниатюры, создаваемые Кусабою/FBE, также по умолчанию имеют двухсотпиксельные размеры, то и в исходном коде запроса https://bitbucket.org/Therapont/fbe-410/pull-requests/12 для создания миниатюр FFmpeg использует именно алгоритм Флойда и Штейнберга, а не Байера.

Длящееся со дня вторника по вопросу >>20499 молчание я считаю знáком согласия, так что по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/19 сочинил pull request.

>>20504
Удваиваю этого джентльмена: >>20514

>>20514>>20528
http://410chan.org/d/

Наступил понедельник 27 августа 2018 года. Позади — последние выходные дни нынешнего лета. Настала пора огласить, с какими изменениями к лучшему 410чан вступает в новую неделю, и оглашу.

Устранена обнаруженная http://410chan.org/dev/arch/res/17371.html#20418 избыточность (теперь kusaba.js полагается на то, что Кусаба не создаёт графических файлов с расширением «jpeg»).

Переработана гиперссылка «Развернуть все изображения», нажатие на которую теперь не действует на звукопроигрыватели (чтобы предотвращать торможение и какофонию от одновременного пуска их) и на те изображения, которые и без того были вручную развёрнуты ранее нажатия на неё. Пожелание http://410chan.org/dev/arch/res/17371.html#20417 исполнено созданием дополнительной гиперссылки, убирающей развёрнутые изображения обратно в миниатюры.

В соответствии с замечанием http://410chan.org/dev/arch/res/17371.html#20422 реакция на гиперссылку «Полный текст» переработана таким образом, чтобы выполнять свои задачи и в начальной реплике из некоторой нити обсуждения, а не только в последующих репликах.

Кэшируется (а не скачивается всякий раз заново) скрипт, обновляющий фапчу.

Сёрвер теперь отдаёт файлы JS и CSS с явным указанием кодировки UTF-8, и это может помочь с отображением русских букв (и других неASCIIшных символов), например, при непосредственном просмотре адреса http://410chan.org/lib/javascript/kusaba.js во браузере.

Ферапонт Соусов устроил так, что SVG-значки в теме «Umnochan» теперь меняют цвѣтъ при наведении (на синий).

Кроме >>20544 надо отдельно (чтобы не наткнуться на ограничение размера реплики) упомянуть и о том, что администрацией были приняты предложенные мною изменения движка и конфигурационного файла, позволяющие употреблять FFmpeg (а точнее — запуск программы «ffprobe» и затем ещё «ffmpeg» из комплекта FFmpeg) для создания миниатюр графических файлов.

Идея такого употребления была первоначально высказана в реплике https://nullnyan.net/b/thread/20928#P22458 и по замыслу автора реплики https://nullnyan.net/b/thread/20928#P22472 обеспечивает ускорение создания миниатюр по сравнению с принятым в Кусабе по умолчанию способом (GD). Такой подход, кроме роста скорости, обеспечивает также возрастание наблюдаемого качества изображения за счёт возможности употребить фильтр Ланцоша. Так как установка FFmpeg в любом случае планируется (в качестве генератора миниатюр для видеозаписей), то рост скорости и качества достигается к тому же с экономией тех усилий, которых потребовала бы установка ещё и ImageMagick (единственной до сих пор альтернативы для GD) с той же целью.

По сравнению с первоначальной реализацией https://gitgud.io/devarped/instant-0chan/commit/351c5f0230ec52e2738a589c1ee0fefca08639b8 предложенная содержит ряд улучшений.

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

Во-вторых, параметр «quality», вовсе никак не действующий на FFmpeg, заменён указанием «-q 1» для JPEG (согласно приведённым по адресу http://www.ffmpeg-archive.org/Create-high-quality-JPEGs-td4669205.html рекомендациям он обеспечивает качество JPEG около 89%); что же касается PNG, то по умолчанию FFmpeg и так ужé применяет для PNG максимальное сжатие.

В-третьих, используемый по умолчанию генератор GIF (создающий «крупнозернистые» результаты благодаря использованию неадаптивной палитры и довольно грубого алгоритма распределения ошибок) заменён на предложенный по адресу http://blog.pkh.me/p/21-high-quality-gif-with-ffmpeg.html двухпроходной алгоритм, на первом шаге подбирающий индивидуальную палитру, более всего подходящую для тех цветов, которые используются пикселами данного конкретного файла, а на втором шаге использующий алгоритм «тонкозернистого» распределения ошибок, предложенный Флойдом и Штейнбергом в 1976 году.

В-четвёртых, наложен фильтр Ланцоша.

В-пятых, исправлена оплошность, суть которой — указание «scale=» перед кавычками, а не внутри них.

На всякий случай ещё раз напоминаю: во избежание ошибки, в реплике >>19790 упоминаемой, рекомендую избегать употребления версии FFmpeg более новой, чем 3.4.2.

Впрочем, сравнение миниатюр файлов, приложенных к репликам >>20544 и >>20545 (в первом из которых диѳэрингъ основан на идеях Байера 1973 г., а во втором — на идеях Флойда и Штейнберга 1976 г.), позволяет почти с полною уверенностью утверждать, что эти миниатюры созданы всё ещё тем способом, который используется Кусабою по умолчанию — и, следовательно, упомянутые в реплике >>20545 изменения не были ещё включены на 410чане: либо настройке «$cf['KU_THUMBMETHOD']» ещё не придали значение «'ffmpeg'» в конфигурационном файле, либо даже сам FFmpeg на сёрвере 410чана ещё не ставили (без чего эту настройку в это положение переключать ещё рано и было бы вредно).

На тесте «ffmpeg» генерировал уменьшенные копии ГИФов целиком анимированными вместо использования начального кадра (хотя в конфиге для них стоит «false»), то есть в таком виде не пригоден для использования.

>>20548

Пожалуйста, приведите текст результата выполнения на сёрвере команды «ffmpeg» без параметров. Хочу посмотреть на её версию.

>>20550
Очевидно, что версия из стабильного «Дебиана».
>3.2.12-1~deb9u1
Также очевидно, что она не вырастет в ближайшие пару лет.

>>20551

Версия 3.2.12-1~deb9u1 вовсе не очень старая, вообще-то она должна работать невозбранно.

Для начала попробуем воспроизвести желаемое поведение не из PHP, а из командной строки.

Вот я скачиваю к себе на Windows архив https://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-3.2.4-win64-static.zip (по логикѣ версій онъ старше, чѣмъ 3.2.12-1~deb9u1). Распаковываю, захожу в подкаталог «ffmpeg-3.2.4-win64-static/bin», запускаю команду «fmpeg», убеждаюсь в том, что работает версия 3.2.4 (а не взятая из PATH более новая).

Вот я скачиваю анимированный GIF http://410chan.org/dev/src/153533527866.gif в тот же подкаталог.

Вот я запускаю двѣ команды, имитирующие результат конкатенации, достигнутый строками со 114 по 131 в файле «inc/func/posts.php» (эти номера строк привожу по его нынешней версии в ветви «public»):

Команда №1:

ffmpeg -i 153533527866.gif -vframes 1 -vf "scale=200:-1:flags=lanczos,palettegen" palette.png

Затем — команда №2:

ffmpeg -i 153533527866.gif -i palette.png -vframes 1 -lavfi "scale=200:-1:flags=lanczos [x]; [x][1:v] paletteuse=dither=floyd_steinberg" output.gif

Во время работы каждой команды я могу убедиться (по заголовку текстового вывода), что работает версия 3.2.4 (а не взятая из PATH более новая).

После завершения второй команды я могу убедиться, что файл «output.gif» является неанимированным (однокадровым) GIFом. (Для наглядности этот файл я прилагаю тут.) Созданный промежуточный файл «palette.png» после этого не нужен, я его стираю.

А как выглядит результат попытки повторить эти действия в стабильном «Дебиане»?

В идеале он должен выглядеть байт-в-байт как тот файл, который я прилагаю к своей реплике.

Если версия 3.2.12-1~deb9u1 незначительно отличается от 3.2.4, то тогда не байт-в-байт, но всё же такой же GIF — неанимированный (однокадровый) — получиться должен.

А если не получается такой файл, то тогда что-то с FFmpeg не так в Debian.

А если получается в точности такой файл, то что-то не так с формированием командной строки из PHP-кода.

Не может же условное выражение, на строке 117 расположенное, не сработать? — оно там довольно простое для этого.

(Я надеюсь, в кусабовской конфигурации для переменной «KU_ANIMATEDTHUMBS» значение «false» записано без кавычек?)

Кажется, я нашёл, в чём ошибка.

Причём она была в самом начале существования репозитория https://bitbucket.org/Therapont/fbe-410 (и вообще она появилась никак не позже расположенного по адресу https://github.com/tslocum/kusaba/commit/193ae0c325966f8514eb35cc905dc2452dce145a коммита, датируемого 2 сентября 2007 года — скоро ему ровно 11 лѣтъ).

Кусок кода, создающего миниатюры посредством ImageMagick — тот кусок, который я копировал и переправил для FFmpeg — был сочинён человеком, убеждённом в своём праве сочинять условные выражения наподобие «substr($filename, 0, -3) != 'gif'» для проверки того, не оканчивается ли имя «$filename» расширением «'gif'».

Я воспринял это убеждение некритически (предполагая, может быть наивно, что вряд ли можно наткнуться на грубую ошибку в коде, проработавшем более десятилетия на нескольких известных сайтах). Между тем один лишь взгляд, по адресу https://secure.php.net/manual/en/function.substr.php брошенный, способен открыть печальную истину: функция «substr» в языке PHP работает совсем не так, и вмѣсто «substr($filename, 0, -3)» должно было стоять просто-напросто «substr($filename, -3)».

О, етить.

Патч: https://bitbucket.org/Therapont/fbe-410/pull-requests/20

Пристальное вглядывание в код https://gitgud.io/devarped/instant-0chan/blob/5ff12039145d7292cddfcaec67633ea854bc30e5/inc/func/posts.php#L76 убеждает меня в том, что и там эта ошибка до сих пор наличествует, по меньшей мере, в двух местах.

Рекомендую автору реплики http://410chan.org/dev/arch/res/17371.html#18170 и автору реплики http://410chan.org/dev/arch/res/17371.html#20325 (излагавшим мысль о возможности брать пример с расположенного по адресу https://gitgud.io/devarped/instant-0chan репозитория) донести соображения >>20554 до публики, занимающейся исправлением той репы.

>>20556
Передал, спасибо.
Там, кстати, немного иначе сделали.

>>20558

Есть определённая логика в том, чтобы код «substr($filename, 0, -3) != 'gif'» поправить не простою заменою на «substr($filename, -3) != 'gif'», а заменою на «substr(strrchr($filename,'.'),1) != 'gif'», как по адресу https://gitgud.io/devarped/instant-0chan/commit/56d38d35fb3cbfb0c78d4d7e54935ecae62382ac сдѣлано.

Однако при бѣгломъ взглядѣ эта логика неочевидна. Даже сам автор через пару-тройку-другую месяцев может начать недоумевать над этаким-то сочетанием «substr» и «strrchr».

Практичнее (потому что нагляднее) выразить совершенно ту же логику исходным кодом «substr($filename, -4) != '.gif'».

И теперь я такъ и сдѣлалъ.

Чем вам mime_content_type() из Fileinfo не угодил, обязательно надо велосипеды городить?

>>20560

Разве ImageMagick и FFmpeg ориентируются не на расширение файла, а на «магию» анализа контента его? — кажется, всё же на расширение; а раз уж на расширение, то его-то и следует сравнивать с тем или иным.

К >>20561 следует прибавить ещё два соображения, и прибавлю.

Во-первых, https://secure.php.net/manual/en/function.mime-content-type.php полагается на содержимое «magic.mime», а я не знаю, сколько ему лѣтъ. Может нечто вроде >>20551 быть, несколько лѣтъ без обновлений, и порождать подобные https://nowere.net/d/res/3573.html#4691 и https://nowere.net/d/res/3573.html#4695 ошибки распознавания WebM, напримѣръ, потому что этот формат новѣе.

Во-вторых, внутри функции «createThumbnail» поздновато заниматься анализом контента на соответствие расширению. Такой проверке мѣсто в методе «HandleUpload» у класса «Upload» в файле inc/classes/upload.class.php, и она там есть, хотя и несколько рудиментарная (ограничивающаяся вызовом функции «getimagesize»). Тѣмъ, кому сія рудиментарность не по нраву, придётся сочинить собственный патчъ для ея исправленія. К тому времени, когда «createThumbnail» вызывается, можно считать содержимое файла провѣреннымъ, и соответствие его расширению установленным достовѣрно, и на расширение ориентироваться. (По точно таким же соображениям коммит https://bitbucket.org/Therapont/fbe-410/commits/3355e9e1bb4bc267b6c21d3a6962cbfd993790ef пополняет метод «HandleUpload» проверкой видео через запуск «ffprobe» и последующим анализом результатов, производимым, так сказать, «с пристрастием» — после чего внутри функции «createThumbnail» запускает уж «ffprobe» без всякой проверки, съ полнымъ довѣриемъ к результатам.)

>>20561
Ох, горюшко ты горе... Этот ЯП, похоже, проклят. Ладно, могу ещё понять, что со времён 5.3.0 до 2016 года семь лет был тупой баг в документации, когда при переносе модуля из пекла эту функцию пометили как deprecated (хотя мартыхи документацию обычно не читают, а всё, что реально deprecated, бросает E_DEPRECATED, если раньше не сегфолтится), и подобный вопрос, вброшенный в стадо, неизбежно порождал там срач.

Во-первых, ни один вменяемый разработчик полагаться на честность юзера и ловить сегфолты с RCE не будет. Ты никогда не задумывался, зачем в первых нескольких байтах пишут %PNG, яШяа, MZ, e.t.c.?
Во-вторых, со времён KDE 3.x файлы не обязаны иметь расширений чтобы корректно определяться KDE-шным проводником, поскольку mime.magic — часть NIX-подобных ОС, т.е. юзер в принципе не обязан именовать свои картинки по чужим правилам на прыщавом десктопе. In contrast, Винды, по крайней мере XP и ниже, полагаются на имена файлов, делегируя ответственность ассоциированному с расширением ПО.
В-третьих, есть такая штука, как валидация данных, особенно присланных непойми кем из интернета, особенно если предполагается последующая обработка этих данных на сервере. Хотя бы ради того, чтобы сервер в случае чего не упал.
In the fourth, the browser usually doesn't care about mime-types of transmitting files.

>>20565

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

А у нас такие особые юзеры, нечестность которых ограничивается постановкой некорректных расширений и не простирается на постановку некорректных байтов в начале файла, так что «mime_content_type() из Fileinfo» внезапно всех спасёт?

И ещё у нас есть пример того, как достигнуть сегфолт+RCE, скормив некорректный файл в GD в PHP, причём либо сразу в «getimagesize» такой сегфолт, либо «getimagesize» даже выдаст не FALSE и позволит сегфолт чуть позже устроить? Причём этот пример можно предотвратить именно благодаря некорректности байтов в начале файла?

> Ты никогда не задумывался, зачем в первых нескольких байтах пишут %PNG, яШяа, MZ, e.t.c.?

Да куда уж мне задумываться над такими высокими материями. Я и адрес https://secure.php.net/manual/en/function.mime-content-type.php в реплике >>20564 привёл без единой мысли: этот адрес просто выделился из организма на чистых инстинктах, всё равно что слюна у собаки Павлова или использование каменных орудий калифорнийскими каланами.

> В-третьих, есть такая штука, как валидация данных, особенно присланных непойми кем из интернета, особенно если предполагается последующая обработка этих данных на сервере. Хотя бы ради того, чтобы сервер в случае чего не упал.

Есть такая штука, как повторение ранее изложенной мысли второй раз заново, только другими словами: вместо «ни один вменяемый разработчик полагаться на честность юзера не будет» пишешь «валидация данных, особенно присланных непойми кем из интернета», а вместо «ловить сегфолты с RCE» пишешь «сервер упал». И вот уж новый пункт готов, который «в-третьих», но который от «во-первых» ничем по сути не отличается, только слова другие. Это делает честь тезаурусу.

> In the fourth, the browser usually doesn't care about mime-types of transmitting files.

But when it does, that's https://en.wikipedia.org/wiki/Content_sniffing

По адресу https://gitgud.io/devarped/instant-0chan/commit/71aca5a666ef7bd069e8b4a59aba825f0c760988 с интересом наблюдал, как в instant-0chan прибавили (ещё 25 апреля) возможность вызова OptiPNG¹ для уменьшения объёма файлов PNG — однако же почему-то только для файлов, содержащих миниатюры, причём созданные не из GD.

Между тем хорошо извѣстно (или должно быть извѣстно), что нѣкоторые видеопроигрыватели (в частности, Media Player Classic Home Cinema) сохраняют кадры аниме в файлах PNG не очень эффективно, так что применение OptiPNG к такому файлу (а не к одной только миниатюре его) в момент загрузки файла на 410чан могло бы способствовать экономии мѣста на сёрверѣ.

Есть ли OptiPNG на сёрверѣ у 410чана? Если есть, то какой версии? Если нѣтъ, то нельзя ли поставить?

Какого мнѣнія держится администрация 410чана насчёт возможности употреблять OptiPNG, будет ли в список желаемых изменений (по адресу https://bitbucket.org/Therapont/fbe-410/issues?status=new&status=open расположенный) прибавлять эту возможность?

А как насчёт возможности загрузки нѣскольких файлов?

А как насчёт возможности указать вмѣсто файла нѣкій URL, ведущий на крупнофайловый хостинг (YouTube, Vimeo, Coub, IPFS, Dropbox, Mega, Google Drive, Яндекс.Диск, etc.)?

А как насчёт тэгов meta для Twitter Cards?²

А как насчёт предупреждающего надписывания видеозаписей, содержащих звук, но зато одновременного включения этого звука вместе с видеозаписью в момент первого же жмяка мышóю по миниатюре видеофайла?

____________

¹ http://optipng.sourceforge.net/

² Например, https://developer.twitter.com/en/docs/tweets/optimize-with-cards/overview/summary-card-with-large-image

>>20567
По всем позициям: не нужно.

А конкретно «Ютуб» в виде видосов тут всегда был и есть, просто мы его не используем.

Посмотрел на создание превьюшек через ffmpeg — теряется прозрачность в gif.

По-видимому, наблюденіе >>20573 совершенно справѣдливо, и багъ https://trac.ffmpeg.org/ticket/6813 (или другой подобный) является первопричиною его.

У меня нѣтъ словъ, господа, для того, чтобы передать вамъ глубину моего разочарованія. До этого дня я имѣлъ основанія надѣяться на то, что ужасное качество миниатюръ гифовъ намъ удастся преодолѣть хотя бы уходомъ на «ФФмпэгъ», но это стремленіе оказалось цѣликомъ безплоднымъ.

Видъ ошибки, въ репликѣ >>19790 упомянутой, какъ бы говорилъ мнѣ, что нельзя и «ФФмпэгъ» считать совершенно свободнымъ отъ оплошностей, но могъ ли я предвидѣть такую-то глубочайшую хѣрню, доходящую по глубинѣ до вещей элементарнѣйшихъ, такихъ какъ обработка прозрачности? — никоимъ образомъ не могъ!

О, етить.

Остаётся ли какой-нибудь разумный третий путь создания нормальных человеческих миниатюр GIFов?

Прежде всего: установлено ли на сёрвере у 410чана программное обеспéчение ImageMagick или GraphicsMagick? — и если да, то какой версии? — а если нѣтъ, то нельзя ли установить его?

>>20575 Оба есть, 6.9.7.4, 3.25 (из стабильного дебиана)

>>20576

Могу ли я считать, что порядок версий «6.9.7.4, 3.25» соответствует порядку упоминания ImageMagick и GraphicsMagick в моей предыдущей реплике?

Но тогда что такое «3.25», если по адресу http://www.graphicsmagick.org/ последней названа версия 1.3.30?

Может быть, GraphicsMagick 1.3.25?

>>20577 Да, ошибка при копи-пасте. Версия GM 1.3.25.

>>20578

Я проверил GraphicsMagick версии 1.3.25 у себя на Windows и убедился, что эта программа не умеет нормально генерировать анимированные миниатюры анимированных GIFов: они то подлагивают, то подёргиваются. Сочинять её поддержку я не стану.

Что же касается ImageMagick, то по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/22 поддержку этой программы я напилил.

Напоследок я должен сознаться, господа, что меня разочаровал расхваливаемый по адресу https://www.imagemagick.org/Usage/quantize/#dither_how алгоритм перераспределения ошибок вдоль кривой Гильберта, потому что на примере GIF-анимации, к реплике >>20577 приложенной, я убедился в склонности этого алгоритма к неспровоцированным однопиксельным выплескам цвета (по сравнению с результатами старого доброго алгоритма, предложенного Флойдом и Штейнбергом в 1976 году).

И сознаюсь.

К этому разочарованию я пришёл, когда подал вот какие двѣ команды:

convert "не время сдаваться (FullHD Bayer).gif"[0] -resize 200x200^> example.gif

convert "не время сдаваться (FullHD Bayer).gif"[0] -resize 200x200^> -dither FloydSteinberg exampleFS.gif

(Если будете повторять их не под Windows, то не позабудьте переменить «^>» на «\>».)

С результатами вы можете ознакомиться в прилагаемом архиве 7-Zip. В файле example.gif (по сравнению с контрольным exampleFS.gif по Флойду и Штейнбергу) на небе видны две дополнительные тёмно-синие точки, а несколько ниже — какие-то турбулентные завихрения на границе между небом и зарёю.

В итоге по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/22 я вызываю именно алгоритм Флойда и Штейнберга.

Наступил понедельник 3 сентября 2018 года, первый понедельник нынешней осени. Настала пора огласить, с какими изменениями к лучшему 410чан встречает новую неделю, и оглашу.

Во-первых, создание миниатюр изображений возлагается теперь на программу ImageMagick, а не на библиотеку GD языка PHP. Это изменение должно принести нам рост качества результатов миниатюризации, особенно заметный в случае анимированных GIF, содержащих узоры Байера, для которых предшествующий алгоритм создавал довольно досадные низкокачественные миниатюры с резкими изменениями цвета, происходившими в шахматном порядке. Пример прилагаю.

Во-вторых, выявлена и обойдена та проблема, ввиду которой во браузере Mozilla Firefox ещё сохранялся упомянутый в финале реплики http://410chan.org/dev/arch/res/17371.html#20260 недостаток, свойственный первому поколению развёртывателей миниатюр, то есть сохранялась задержка между жмяком мышóю по миниатюре и началом полноразмерного отображения — задержка, равная промежутку времени между отправкою запроса на сёрвер и началом поступления первых пикселов с сайта. (Для устранения этой задержки теперь миниатюра делается не фоном полноразмерной иллюстрации, а второю иллюстрациею, растянутою до того же размера да подложенною под неё, как на Архиваче.

Исключением по-прежнему являются файлы GIF, для которых такого подкладывания не происходит по причинам, изложенным в реплике http://410chan.org/dev/arch/res/17371.html#20261 под конец её.)

Можетъ ли кто-нибудь понятно объяснить мнѣ, какимъ образомъ получилось такъ, что даже измѣненія https://bitbucket.org/Therapont/fbe-410/commits/0f1aa5969812263c8645707004c7cfa31086bac7 въ кодѣ на сёрверѣ не привели къ устраненію ошибки, по адресу http://410chan.org/dev/arch/res/17371.html#18031 обнаруженной?

Если администрации нужна какая-нибудь помощь по допиливанию исходного кода видеообработчика, то давайте, по крайней мѣрѣ, поговорим об этом поподробнее.

>>20585
Пока не тестировали этот код, так что и говорить нечего.

>>20586 Код пока на локалхосте тестируется.

>>20503

> Самое удобное в патреоне для чанеров, что делать пожертвования можно анонимно.

Разве анонимно? Если на странице https://www.patreon.com/saucenao я нажимаю кнопку «BECOME A PATRON», то оказываюсь переброшенным на страницу https://www.patreon.com/bePatron?c=130578 с приглашением ввести желаемый размер пожертвования, но затем (после нажатия на кнопку «CONTINUE») — на страницу https://www.patreon.com/join/saucenao/signup с приглашением либо регистрироваться, либо через Facebook заходить. Сие не анонимно.

>>20591
Регистрироваться действительно необходимо, тем не менее само пожертвование можно сделать анонимно.

https://patreon.zendesk.com/hc/en-us/articles/203913579-Can-I-be-anonymous-

>We want you to be whoever you want to be, as long as you provide your real payment info.

Стоит заметить, что патреон также позволяет использовать для пожертвования пейволл, типа того же paypal.

Чтобы пожертвования не было видно:

https://patreon.zendesk.com/hc/en-us/articles/204694855-What-does-it-mean-if-my-account-is-private-

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

По работе видосов замечаний пока нет, но на данный момент требуется синхронизировать ветку public-webm с изменениями, принятыми в public.

>>20618
> замечаний пока нет
А, нет, есть. При попытке запостить ogv выдает "Filetype tampering detected"

И да, не помню точно, сделано ли, нужно отсекать видео с двумя и более видеотреками. А то напостят.

>>20618

Запрос на синхронизацию по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/24 отправлен.

>>20619

Прошу выложить пример OGV, которым это достигнуто, так как собственными примерами OGV не располагаю.

P. S.   А у нас точно есть намерение поддерживать заливку видео OGV, а не одних только WebM и MP4?

>>20622
>OGV и WEBM как минимум, а также MP4
https://bitbucket.org/Therapont/fbe-410/issues/15/

そですか。

>>20619

По адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/24 прибавил два коммита, которые должны устранить ошибочное появление сообщения «Filetype tampering detected» и исключить возможность загрузки таких видеофайлов, в которых число видеодорожек отличается от единицы.

Проверяйте.

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

Нужно ли проверять, какая https://ru.wikipedia.org/wiki/Цветовая_субдискретизация используется в видеозаписи, и запрещать видеоролики, в которых она не соответствует схеме 4:2:0? Если не запрещать их, то напостят пренепременнейше.

Нужно ли запрещать видео, у которого количество звуковых каналов в звуковой дорожке равно не 1 (моно) и не 2 (стерео), а больше (квадрозвук, или surround sound, или что-то другое в этом же роде)? Если не запрещать, то можно быть совершенно уверенными, что напостят, да ещё в дополнительных звуковых дорожках будут ругаться по матери и по Путину, а модератор не услышит, модератор пропустит.

Нужно ли ограничивать размер кадра снизу (чтобы не напостили слишком небольших) или сверху (чтобы не напостили слишком больших)? А не то беспременно напостят ведь!

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

А как насчёт частоты дискретизации звука: 48000 раз в секунду — это ещё ok, или надо не более 44100? Любители тёплого звука напостят, это они умеют.

Нужно ли проверять в случае MP4, какой из аудиопрофилей https://en.wikipedia.org/wiki/MPEG-4_Part_3#Audio_Profiles используется, и запрещать те видеоролики, в которых он сложнее AAC LC? А не то их напостят, а у кого-то тупой мобильник декодировать не потянет!

Нужно ли проверять https://en.wikipedia.org/wiki/Pixel_aspect_ratio и запрещать видеозаписи с неквадратными пикселами? А не то найдутся и таковские, которые их напостят, чтобы у добрых людей видео перекосило!

Нужно ли принимать видеоролики только с восьмибитными пикселами, а с десятибитными запрещать? Если не запретить, то закономерно напостят десятибитных — хотя бы оттого, что станут десятибитное аниме конвертировать без умаления глубины цветности.

Нужно ли проверять, используется ли https://ru.wikipedia.org/wiki/Прогрессивная_развёртка в видеоролике, и запрещать те, в которых развёртка чересстрочная? А не то ретроанимешники напостят, да и как им тогда было бы не напостить.

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

>>20628
Не знаю, видел ли ты это, но Якуй не осилил: https://files.catbox.moe/7o4xyh.mp4 https://files.catbox.moe/a96733.mp4 https://files.catbox.moe/j8n6qg.mp4

>>20629

Разумеется, всѣ эти файлы я видел: реплики http://410chan.org/dev/res/17371.html#18841 и http://410chan.org/dev/res/17371.html#18855 и http://410chan.org/dev/res/17371.html#18857 об этих файлах, оставленные зимою нынешнего года, принадлежат мнѣ.

Не увѣренъ, что значит «Якуй не осилил», но нынешний код FBE (из ветки public-webm) запрещает публикацию файла https://files.catbox.moe/7o4xyh.mp4 (так как файл настолько битый, что FFmpeg отказывается сделать из него миниатюру), а два других принимает.

Так как по адресу http://410chan.org/dev/res/17371.html#18857 я упоминал способность браузера Mozilla Firefox невозбранно (и безглючно) открывать эти два другие файла, то я пока не вижу никакой особенной проблемы в их публикации. По адресу http://410chan.org/dev/res/17371.html#18855 я сообщал уж, что считаю делом браузера готовность открыть видеофайл (или готовность с ошибкою отказаться открывать его), как это и с неподвижными картинками случается.

Около десяти минут тому назад исходный код из ветви public-webm был слит в ветвь public.

Это явный знак, позволяющий с изрядною уверенностью утверждать, что администрация 410чана начинает окончательное (предстартовое) тестирование видеохостингового исходного кода.

Возрадуйтеся!

Опечатка: посты с webm (и т.п.) без превью в rss. Посты с картинками показывает нормально.

Прошу применить поправку https://bitbucket.org/Therapont/fbe-410/pull-requests/25/ для коррекции стилей медиапроигрывателей.

>>20638

Там не опечатка, а логическая ошибка автора движка, допущенная в файле inc/classes/rss.class.php на строке 50.

Нельзя просто приписать букву «s» в конце имени файла (перед точкой и расширением) и переменить название его папки «src» на «thumb» и надеяться, что получится адрес миниатюры. Это и раньше работало только с картинками, а с некартиночными файлами не работало и работать не могло, так я это понимаю.

>>20639 ok.

>>20638>>20640
Но это не значит, что это не может быть починено. Сделал PR.
И прошу прощения за продолжительное отсутствие.

>>20638
У меня с какого-то обновления вообще всё без превью. Учитывая что читалка ревностно относится к стандартам, проблема таки на автобусе.

Cloudflare по адресу https://blog.cloudflare.com/distributed-web-gateway/ объявляет о начале поддержки IPFS и о запуске расположенного по адресу https://cloudflare-ipfs.com/ собственного гейта.

По адресу https://www.cloudflare.com/distributed-web-gateway/ сообщается, что кэширование контента IPFS происходит более чем на полутора сотнях дэйтацентров Cloudflare. (Скриншот прилагаю.)

С учётом вновь открывшихся обстоятельств не пожелает ли администрация 410чана пересмотреть ранее данный отрицательный ответ >>20568 на вопрос >>20567 о возможности указать вмѣсто файла такой URL, который вёл бы в IPFS?

>>20645
Вы и так можете указывать любой URL, который не внесён в спамфильтр.
Умерьте пыл. Тут имиджборд, а не файлообменник.

>>20646
Так понял, Мицгол предлагает использовать как файлообменник как раз не Автобус, а Флару, на Автобусе же контент только подгружать с неё.

>>20647

Закономерные события рано или поздно происходят. Со временем так или иначе Соусов поймёт, что двух небольших команд, поданных в консоли, вполне достаточно, чтобы архив его стрима сохранялся не только пару недель на «Твиче», но и неограниченно долго в IPFS (и открывался в уютном видеопроигрывателе рядом с репликою на имиджборде, если в имиджборде заложена поддержка IPFS, а результат этих команд запостили); если интересно, то вот пример таких двух команд для архива №310805212:

youtube-dl https://www.twitch.tv/videos/310805212

ipfs add -w "Унылый фанарт-v310805212.mp4"

>>20649
Вот, что думаю: а нельзя ли полностью всю статику в ИПФС перенести, поставив демона на сервере? Это же огромная экономия места получится.

>>20650

Если поставить демона на сервере и перетащить на сервере всѣ статические файлы из обычной файловой системы в P2P-распределённую систему IPFS, то экономии места не получится (файлы придётся и дальше в IPFS держать, чтобы был хоть один надёжный источник их для P2P). Зато получится экономия траффика и притом ещё достижение ≈100% аптайма, но для того и для другого непременно потребуется, чтобы для WWW хостом файлов указан был не 410чан, а IPFS-гейт Cloudflare.

Если в довершение к этому всё-таки нужна и экономия места на сервере, то её можно достигнуть, например, если статические файлы сохранять (для раздачи их в IPFS) не на сервере у 410чана, а под кроватью у админа на отдельном сервере, который дешевле в обслуживании и от которого не потребуется 100% аптайма. Или, например, если хранить статические файлы всё-таки на сервере в IPFS, но зато после отправки обсуждения в архив стирать всѣ статические файлы, обсуждением употребляемые, тем самым полагаясь на то, что за время жизни обсуждения эти файлы осели в нескольких копиях у читателей (на их собственных, читательских, демонах IPFS; конечно, для того наперёд надо пропагандировать и среди читателей готовность установить IPFS в их системы и притом ещё пропагандировать готовность дополнительно установить также и расширение https://github.com/ipfs-shipyard/ipfs-companion во браузеры, способствующее локальному кэшированию P2P-распределённого контента для последующей раздачи в IPFS) — тогда размер необходимого места на сервере стабилизируется в объёме активных обсуждений, а не будет неуклонно возрастать со временем по мере архивации прежних обсуждений. Это также экономия.

(Можно и комбинировать эти приёмы — например, архив отправлять на выделенный IPFS-сервер к админу под кровать, не полагаясь на одних читателей.)

>>20654
Идея скорее в недобросовестном использовании предоставляемых Клаудфларой возможностей. А именно того, что они на своих серверах будут кешировать контент, слитый на их гейт. Опять же если я не Мугичкой поперёк прочитал.
То есть можно заливать статику на сервер, скидывать через ИПФС в гейт Флары, держать до какого-то момента, пока контент не закешируется на их серверах, после чего удалять со своего. Вопрос остаётся в доверии Фляре и её надёжности.
В конце концов, поднятие зеркала борды посредством проксирования её через Фляру тоже не очень честно по отношению к последней. Хотя такая практика имела место быть, пока кое-где не появилось хттпс с сертификатом LE.

>>20655
Ты слишком lawful человек, если задумываешься о честности по отношению к этому крышевателю, подминающему под себя Всемирную паутину.

>>20656
Если бы был lawful, то вообще не возникло бы идеи. Так я только за эксплуатацию корпораций.

>>20655

> Идея скорее в недобросовестном использовании предоставляемых Клаудфларой возможностей. А именно того, что они на своих серверах будут кешировать контент, слитый на их гейт. Опять же если я не Мугичкой поперёк прочитал.

> То есть можно заливать статику на сервер, скидывать через ИПФС в гейт Флары, держать до какого-то момента, пока контент не закешируется на их серверах, после чего удалять со своего. Вопрос остаётся в доверии Фляре и её надёжности.

Я не уверен, что это вообще можно называть недобросовестным использованием. Их гейт объявлен как предназначенный для показа контента из IPFS и притом кэширующий тот контент, так что делать то и другое никто не запрещает.

Другое дело, что и Cloudflare не обещает держать контент на их 150+ серверах неограниченно долго. Да они, небось, и не смогли бы, так как вряд ли их кэш способен целиком вместить всё содержимое файловой системы IPFS (летом прошлого года в файле https://cloudflare-ipfs.com/ipfs/QmWimYyZHzChb35EYojGduWHBdhf9SD5NHqf8MjZ4n3Qrr/Filecoin-Primer.7-25.pdf на тринадцатой странице было сказано, что число файлов в IPFS ещё тогда превысило пять миллиардов). Это не вопрос доверия к Cloudflare, а вопрос арифметики: каков средний размер файла в IPFS? — какой объём получится, если сперва помножить на пять миллиардов, а затем на вероятность попытки скачать файл именно через гейт Cloudflare (вероятность, возрастающую вместе с популярностью гейта по мере распространения свѣдѣній о нёмъ)?

Вот почему в предшествующих репликах я не рассматривал вопрос о стирании файла сразу после гейтования его на Cloudflare, а рассматривал только две альтернативы: «у админа под кроватью» (дешёвое централизованное хранение с необязательным аптаймом) и «у читателей» (ещё менее надёжное, зато децентрализованное, хранение, но полагающееся на распространённость употребления читателями на их компáх и самогó софта IPFS, и расширения IPFS Companion).

Если обе эти альтернативы представляются малопривлекательными, то можно ещё у Cloudflare по адресу https://developers.cloudflare.com/distributed-web/ipfs-gateway/connecting-website/ прочесть о третьем варианте: есть серверы, предлагающие хранение файлов в IPFS в качестве платной услуги. Среди них там упомянуты два: http://ipfsstore.it (который, по-видимому, от упоминания на Cloudflare сразу и лёг) и https://www.eternum.io (который не лёг и предлагает хранение в IPFS по цене 30 центов за гигабайт в месяц, что по нынешним временам означает рублей двадцать с копейками).

Я допускаю, впрочем, что этот последний вариант покажется ещё менее привлекательным (и даже грабительским), так как с калькулятором в руках кто угодно может сосчитать (а некоторые и без калькулятора, то есть устным счётом или вообще въ умѣ), что 30 центов за гигабайт означает 12 баксов за 40 гигабайтов, тогда как по адресу https://www.leaseweb.com/cloud/virtual-server можно арендовать сорокагигабайтовый VPS за пять евро (а это явно дешевле), после чего останется только самостоятельно поставить на него демон IPFS и запустить. Я привожу Leaseweb просто в качестве наиболее наглядного примера, так как для IP-адреса 410chan.org (95.211.122.44) https://ru.wikipedia.org/wiki/Обратный_просмотр_DNS выдаёт имя «hosted-by.leaseweb.com».

Если изложенное в реплике >>20663 покажется слишком сложным или порождающим невыносимые мýки выбора, то вдобавок я сейчас ещё раз напомню, что суть моего-то собственного предложения состояла не в том, чтобы сервер и администрация 410чана задумались над собственным идеалом сохранения статических файлов в IPFS, а в том только, чтобы наряду с публикацией файла на имиджборде существовала и возможность приложить к реплике IPFS-адрес от файла, заранее кем-то ужé опубликованного в IPFS.

Откуда такой адрес возьмётся? — нетрудно предположить (и предполагаю), что большинство таких публикаторов в качестве необходимого для P2P источника файла употребят, вероятно, либо установку IPFS на один из собственных многотерабайтных дисков (так как у типичного любителя аниме всегда есть ведь пара-тройка-другая многотерабайтников, не всѣ из которых забиты до конца, причём совокупная ёмкость таких отщипленных за ненадобностью остатков всегда будет больше того объёма, который администрация сайта сумеет централизованно арендовать), либо воспользуются подобными http://ipfs.stadja.net/upload/ интерфейсами для выкладывания файлов в IPFS, совершенно бесплатными, но зато нисколько не гарантирующими срок (и даже факт) хранения — а затем станут полагаться на то, что среди читателей 410чана отыщется достаточно пользователей IPFS Companion для того, чтобы файл сохранялся и у читателей столь же долго, сколь долго он остаётся реально нужным 410чановской публике.

Конечно, для таких файлов сайт 410чана, в общем случае, не станет создавать миниатюру, а оттого принуждён будет указать какую-нибудь общую на всех заглушку с надписью «IPFS». Сейчас такое кажется непривычным, но такое впечатление не будет существовать вечно; напротив, можно догадываться, что после устранения проблемы, по адресу https://bitbucket.org/Therapont/fbe-410/issues/8 обозначенной, на 410чане появятся заглушки спойлеров (пример прилагаю), после чего общественное сознание скоро привыкнет, что миниатюра может и не соответствовать содержанию файла.

Не могу совершенно исключать даже и того, что в дальнейшем можно будет напилить и некий цикл «скачать ➡️ миниатюризировать ➡️ стереть скачанное, начать использовать миниатюру» для тех из хранимых в IPFS файлов, которые не превосходят некоторого доступного на сервере объёма, необходимого для краткого сохранения их после скачивания из IPFS через гейт.

>>20663
Жаль, что нет точных сроков или алгоритма выбора удаляемых из кеша ИПФС Флары, но если предположить самый вероятный из, то, скорее всего, большие файлы будут храниться совсем недолго, а вот небольшие — достаточно. Насколько помню, те же сайты, которые задудосили со стороны хоста, если Флара закешировала, то с месяц-два могла одна версия висеть. Не знаю, как сейчас, но можно выявить экспериментным путём сей алгоритм хранения и удаления, после чего можно написать скрипт, что будет дёргать файлы из кеша в момент протухания на Фляре, ждать, пока снова не закеширует и обратно удалять.

>>20665

А вот это ужé опасно к https://en.wikipedia.org/wiki/Tragedy_of_the_commons приближается.

>>20666
Вот потому и говорил, что вовсе не lawful. В конце концов, китайцы убивают много более достойные ресурсы альтруистов, желавших сделать великое добро для человечества, терабайтами трафика, а тут считай корпорация с некислой монетизацией. Это как паразитировать на Гугле — если и заметят маленький зуд с их масштабами, то очень нескоро, как было с хостившими на Драйве порнуху годами.

Одновременно со вчерашними и сегодняшними переделками на сервере, Автобус двинул на PHP7.

>>20671

А в какой конфигурации?

Например, позволит ли она на основе https://secure.php.net/manual/en/session.upload-progress.php растущую полоску процента закачки напиливать, или там между браузером и PHPшным движком поставлено сёрверное кэширование закачиваемого файла, только затем в PHP начинающего поступать?

>>20675 В минимальной, практически дефолтной, что на какое-то время сломало загрузку больших файлов.

Сегодня я возвратился к идее об употреблении IPFS и записал по адресу https://www.pscp.tv/w/1mnxeolgakoGX стрим с рассуждениями и аргументами об этом вопросе длиною 83 минуты. Заинтересованных прошу посмотреть.

Сознавая возможное недостаточное визуальное качество приёма потокового вещания с сайта Periscope, прилагаю альтернативную версию в высоком качестве (командою «youtube-dl https://www.pscp.tv/w/1mnxeolgakoGX» скачанную из Periscope же) на IPFS-гейте Cloudflare в подкаталоге https://cloudflare-ipfs.com/ipfs/QmfYpqAmErJhEtBojjqvUoaemgLrVBZPQNtc53PG6bFp9d (192 660 килобайтов).

Даю ссылку на подкаталог, так как прямую ссылку на сам видеофайл дать не могу: движок 410чана воспринимает адрес https://cloudflare-ipfs.com/ipfs/QmfYpqAmErJhEtBojjqvUoaemgLrVBZPQNtc53PG6bFp9d/Mithgol - Стрим про %D
0%BF%D0%B5%D1%80%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D1%8B%20%D0%B2%D0%BD%D0%B5%D0%B4%D1%80%D0%B5%D0%BD%D0%B8%D1%8F%20IPFS%20%D0%BD%D0%B0%20410%
D1%87%D0%B0%D0%BD%D1%A3.mp4 как чрезмерно длинный и расчленяет его до неупотребимости, как вы и сами можете видеть.

（仕方がない。）

>>20671

Одно из двух: или движок FBE пошёл под PHP7 без переделки, или содержимое репозитория больше не отображает настоящее состояние исходного кода.

Первый из этих вариантов необъяснимо противоречит реплике https://410chan.org/dev/arch/res/17371.html#19039

Второй из этих вариантов не радует, так как не ясно, есть ли смысл сочинять pull requests со значительным шансом на безрадостные merge conflicts.

>>20692
Теоретически, вполне может быть, что необходимые изменения уже были встроены в FBE до этого момента. На практике, я не проверял.

>>20692
Чем оно противоречит, если он там ставит старую Кусабу 1.0.4?

>>20710

>>20716

Ага, теперь вроде чуть понятнее, как это могло получиться.

Добавьте указание кодировки в html/head, пожалуйста. Как на ычане. HTTP-заголовка недостаточно, потому что сохранение страниц чем-нибудь (сам браузер, куклоскрипт, расширения) приводит к кракозябрам при открытии.

>>20746

Так как, к нашему счастью, 410чан перешёл к употреблению HTML5, то мы можем использовать и более краткую форму «<meta charset="utf-8">».

Если автор(ы) реплик >>20558 и https://410chan.org/dev/arch/res/17371.html#18170 и https://410chan.org/dev/arch/res/17371.html#20325 до сих пор с нами, то рекомендую донести до создателей репозитория https://gitgud.io/devarped/instant-0chan мысль о возможности использования распределённой файловой системы IPFS в качестве внешнего источника крупных файлов (главным образом, видеозаписей или звукозаписей — хотя, возможно, и анимированных GIFов также) — мысль, изложенную прежде всего в репликах >>20567 и >>20645 и >>20664 и >>20687.

Это подстегнёт его поступательное развитие, а не то там почти месяц (после 7 сентября) не видать новых коммитов ни шиша.

Опять же, если хорошая мысль въ 410чанѣ не была принята, то тогда не пропадать же ей? — никоим образом не пропадать.

>>20755
А как ипфс работает с тором, например?
Вообще, они там сейчас как раз над работай с файлами думают, чтоб были тумбинашки для каждого расширения, да и не только: http://metatorjq65tshfy.onion/meta/res/405.html#4180

>>20768

> А как ипфс работает с тором, например?

На доске http://metatorjq65tshfy.onion/meta/ я вижу поддержку вложения видеофайлов с сайтов Youtube и Vimeo и Coub. По сравнению с ними открытие файла из IPFS через гейт Cloudflare будет работать ничуть не хуже (появится возможность открыть, например, каталог https://cloudflare-ipfs.com/ipfs/QmXv9tuzCaigcGjVDAJTf48mfFB9VeUH3fihoaes8pLnZZ и звуковой файл в этом каталоге через TOR), но и ничуть не лучше (обращение к одному центральному серверу).

Можно ли улучшить это положение дѣлъ далѣе (в сторону децентрализации)? — нѣтъ: установка IPFS в свою систему, производящаяся не просто так, а непременно ещё и с последующей настройкою IPFS на работу через TOR, по-видимому, в настоящее время ещё не слишком-то возможна или преизрядно сложна (по крайней мере, авторы https://news.ycombinator.com/item?id=12719771 и https://github.com/ipfs/notes/issues/37 склоняются к такому мнению).

Впрочем, как я говорил уж выше (в репликах >>20664 и >>20687), почему бы и не удовольствоваться тем одним, что промежуточная цель (перекладывание хостинга крупного файла с сервера на публикатора) будет достигнута? — ведь одно это будет ужé очень, очень хорошо.

>>20771
Вопрос скорее в том, нельзя ли будет как-то слить айпи постера.
Хорошо, передам.

>>20772

IP постера, безусловно, можно выяснить тем же способом, который работает в любом неанонимизирующем P2P: сделать запрос в DHT «у кого есть файл?» и, получив список IP-адресов, вычесть из него заранее заготовленный список IP-адресов IPFS-узлов Cloudflare — оставшийся IP-адрес будет IP-адресом постера, если только тот не озаботился заранее распространить тот же файл достаточно широко или не стал публиковать файл в IPFS посредством внешних по отношению к своему компу возможностей, часть из которых в репликах >>20663 и >>20664 перечислена: https://constellation-fs.org/ и https://www.eternum.io/ и https://github.com/BrendanBenshoof/cachewarmer и https://nuts.rtradetechnologies.com:6768/uploads и http://ipfs.stadja.net/upload/ и проч.

>>20776
>http://ipfs.stadja.net/upload/
Хорошо там, где нас нет.

>>20776
>сделать запрос в DHT «у кого есть файл?»
Кстати, не подскажет кто-то, какой именно командой это делается?

ipfs dht findprovs <hash>

выдает id пира (или нескольких), а вот дальше по

ipfs dht findpeer <id>

пустота. Это значит можно спрятаться, или я доки читаю не тем местом?

>>20784
Кое-что выяснил. Информация по собственному id не ищется, зато по соседним пирам, взятым через

ipfs dht query <my_peer_id>

очень даже. Это значит, что я просто сам себя не могу прощупать, или дело в том, что демон заперт в докере без открытия портов в окружающий мир? Но при этом ведь тот же cloudflare как-то подтягивает то, что я добавляю через

ipfs add

В общем, потребен гуру. Я больше по общей архитектуре, чем по отдельным деталям.

Вчера просматривал старые треду, у звуковых файлов исчезла превьюшка. Собственно, тест, есть ли это и сейчас, или нет.

>>20801
...а теперь,напомните мне, пожалуйста, я за последний месяц-полтора забыл: это в <a> неправильный аттрибут или с сервера картинка не пришла?

У меня после переезда сервера FBE ещё заново не поставлен, так что сам до ответа я дойду разве завтра.

>>20802
Открой для себя инструменты разработчика в браузере. Там как раз с <a> все в порядке, а вот в <img> превьюшки ссылка

/dev/thumb/153944823978s.mp3

что очевидно полная хрень, потому что это не картинка. И на сервере такого файла нет. Подстановка .jpg, .jpeg и .png не помогает, так что вероятно превью вообще не существует.

>>20804
Инструменты открыл, <a> не раскрыл.

В любом случае, выгрузил master, проверил на сервере, всё работает. Может не работать в том случае, если у mp3 в filetype указано image в БД/на странице типов в админке. Что явно было сделано уже при внедрении webm на Автобусе.
Собственно, сейчас и в RSS у >>20801 нет превьюшки.

И да, >>20692, FBE с варнингами, но работает даже на 7.2.

Картинка появилась, значит, ошибка устранена. Вот и славно.

>>20809
Кроме RSS. Значит, или в master сейчас не то, что на сервере, или одно из двух.
Алсо, там ошибка в моём патче. rss.class.php, строка 55 должна быть

$items .= '<img src="'.KU_BOARDSPATH.'/inc/filetypes/'.$board_class->allowed_file_types[$row['filetype']][1].'" /></a><br />';

С нужным отступом, да. Мне PR сделать или и так смогу поправить?

>>20810 Оно тестируется, вероятно сегодня мастер будет на бою.

Лень было переделывать pr в другой бранч

>>20810
> Мне PR сделать или и так смогу поправить?
Поправил в public

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

>>20813
Я последовал Мицголу, но да. Больше не повторится.

>>20814

В своё оправдание могу сообщить только то одно, что запросы на слияние с ветвью «master» стремился по возможности создавать только тогда, когда та опережала ветвь «public» и притом опережала в тех файлах, которые затронуты были запросом. Дѣлалъ это для того, чтобы merge conflicts избѣгнуть. И о том по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/27 объявил въ послѣднемъ абзацѣ.

Расскажите мнѣ о причинѣ того, почему коммитъ https://bitbucket.org/Therapont/fbe-410/commits/3ba13935e6046cd2920c99ac237c90bcc1cb7474 был коммитомъ https://bitbucket.org/Therapont/fbe-410/commits/9dcfd44294ad35115d8ce4ca1279f41f4d5e7b29 отмѣнёнъ.

Я правильно понимаю, что такая отмѣна позволит в RSS видеть миниатюры видеофайлов, а предложенная в реплике >>20810 правка заменяла их значками видеотипов?

>>20818
Потому что я не умею считать, и должен был таки сделать это через PR. Правиться должна была не ветка video, а финальный else, где сейчас

$items .= '<img src="'.KU_BOARDSPATH.'/'.$board_class->allowed_file_types[$line['filetype']][1].'" /></a><br />';

Очевидно, если править вместо этого ветку video, то это не миниатюры аудио чинятся, а ломаются миниатюры видео.

>>20819
Ох, я надеюсь в новой версии заполняется строка-шаблон, вместо вот этой невероятной конкатенации.

>>20820
>в новой версии
В новой версии чего?

У меня одного превьюшки раскрываются на свой полный размер, а не на размер фрейма?

>>20820
Это и есть шаблон.

>>20822

> У меня одного превьюшки раскрываются на свой полный размер, а не на размер фрейма?

Это как? Что-то без примера не понятно.

На всякий случай сообщаю, что превьюшки показываются в собственном своём размере с самого начала. Что же касается видеопроигрывателя, то он может быть меньше размера кадра (фрейма), если кадр в полном размере не поместился бы в видимой области окна браузера. Такое уменьшение видеопроигрывателя порождено было осознанием того, что видеопроигрыватель (в отличие, скажем, от полноразмерного изображения) типичный зритель не пожелает прокручивать вверх и вниз, отдельно рассматривая верхнюю и нижнюю часть его — следовательно, не одна только максимальная ширина, но и максимальная высота видеопроигрывателя должна быть ограничена. Естественным ограничением для неё является высота видимой части страницы за вычетом высоты верхнего меню и ещё некоторого дополнительного пространства (чтобы не принуждать зрителя снайперски прицеливаться при прокрутке, со сверхчеловеческой точностью предугадывая будущее положение верхней кромки видеопроигрывателя, ожидающееся после развёртывания миниатюры первого кадра), размер которого для простоты сейчас также предполагается равным высоте верхнего меню (равной 32 пикселам в настоящее время).

Вы что-то сломали, кажется. И вот такое вылезло.

>>20844
После отправки картинки еще и такое.

>>20845>>20844
Кот-то включил выдачу дебаг-информации. Первое было в FBE ещё до правок, array_push начал давать варнинг на undef начиная с PHP7.0.

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

>>20857
А неподдерживаемые производителями браузеры никто тут поддерживать и не собирался.

Привёл rss в гости к валидатору, а там пикрелейтед.

>>20910
Ты, кажется, подсунул RSS валидатору Atom, а не валидатору RSS.

>>20911
Один хрен аналогичный вывод Ычана всё проходит, а на несоответствие стандарта тут жалуются. Если есть более лучший - вперёд и с песней. А я пока этими займусь.

См. >>/b/138958.

>>20914
А нельзя webp использовать? Должно быть лучше png.

>>20915
Нельзя, потому что половина браузеров его не поддерживает.
И даже когда станет поддерживать, надо выждать время, чтобы все старые версии умерли.

Фонд Мозиллы сподобился начать поддержку WebP в шестьдесят пятой версии браузера Mozilla Firefox.

Теперь дело за Apple.

Впрочем, так как год назад Фонд Мозиллы начал выпускать новую версию браузера Mozilla Firefox (под названием Firefox Quantum) вместо прежней, то с тех пор многие пользователи до сих пор продолжают пользоваться прошлогоднею версиею, досадуя о нарушенной (и за год не восстановленной!) работоспособности многих прежних расширений этого браузера.

Один из таковых пользователей в чате стрима https://www.twitch.tv/videos/338354243 рассказал о том (скриншот прилагаю).

Общее число таких жестокосердно выпизднутых¹ пользователей оценивается по адресу https://bugzilla.mozilla.org/show_bug.cgi?id=1427928 как превосходящее 968 000 человек только для четырёх наиболее популярных расширений (Tab Mix Plus, Session Manager, Tab Session Manager, MySessions); вообще же не удивлюсь, если число это приблизилося к миллиону человек или даже превзошло его.

Для всех этих многих сотен тысяч людей совершенно всё равно, добавили ли в этом году поддержку нового-клёвого формата WebP для изображений, нового-клёвого формата AV1 для видеозаписей, а почему всё равно? — а потому, что они её не увидят.

И так как всѣ люди склонны к тому же рационализировать свои решения (в том числе для самозащиты от фрустрации через обесценивание недостигнутой цели), то станут восклицать «Зéлен виноград!», как лисица в басне у Эзопа² — и они даже не будут совершенно неправы, так как более пяти лет тому назад по адресу https://research.mozilla.org/2013/10/17/studying-lossy-image-compression-efficiency/ и затем в последующем году по адресу https://research.mozilla.org/2014/07/15/mozilla-advances-jpeg-encoding-with-mozjpeg-2-0/ упоминался результат исследования, согласно которому WebP не настолько лучше JPEG, насколько это казалось авторам WebP (и внедрявшим WebP людям Google), а просто надо лучше было сжимать JPEG.

Справедливости ради следует сказать, что сейчас удаётся найти одно только упоминание этого исследования; само ж оно располагалося на сервере people.mozilla.org, который, по-видимому, с тех пор был закрыт.

____________

¹ Прошу извинить необходимость прибегнуть к нецензурной ругани, но иным способом никак нельзя передать всю глубину эмоционального накала реакции на это решение Фонда.

² https://ru.wikipedia.org/wiki/Лиса_и_виноград

В честь поддержки webm пощу ностальгическое видео о доработке движка 410го чана, из 2009го года.

>>20933
Ох уж этот злополучный 2009-й, с его $регистрацией и аватарками.

Туда же в тему: https://www.youtube.com/watch?v=f3fLXMNnej8

По адресу https://www.twitch.tv/videos/341851040 был дан ряд советов.

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

>>20954
>придётся перебивать все посты
Вообще, нет. Ссылку на пост может дать только последующий пост (в случае нескольких досок, пост с более поздней датой). Учитывая... семантику подобных переносов, равно как и скорость Автобуса, это максимум 100 постов. Я уж не говорю о том что БД лочиться будет на крайне короткие промежутки времени, так как большая часть работы - это чтение и обработка, ничего "падать" вообще не должно. Это, чёрт подери, Апач, он форкается.
Хотя править тексты постов всё равно придётся из Кусабы, а не пряямо в мускуле. Но ничто не мешает вывод обратно запихнуть в один стейтмент.

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

>>20954
>сайт на полминуты будет падать
Поквантовать обновление — обновляем n постов, потом следующие n постов и так, пока посты не кончатся. Можно обновлять в нескольких потоках одновременно. Для удобства сделать виртуальную машину с единственной командой «(Replace This That)» и очередью задач. Статику не переделывать, она переделается сама при появлении нового поста.

Фрагмент стрима https://www.twitch.tv/videos/342627998 (по времени — в районе конца первого часа и начала второго часа вещания).

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

💢 Необходимость уместить видеозапись в объём 5000 килобайтов вызвана техническими ограничениями 410чана. Сознавая недостаточное аудиовизуальное качество такой видеозаписи, приношу извинения.

>>20965
А каким боком тут административный интерфейс?

Как бы там ни было, надо добавить каждому изображению в базе булево свойство Spoiler (или Hidden) (если, конечно, у вас файлы — это отдельная сущность). В форму отправки сообщения соответственно надо добавить представление этого свойства, в контроллере связать это представление со свойством, а в генераторе страниц реализовать обработку свойства.

На административном уровне булево свойство... ну положим “Spoilers_Allowed” будет принадлежать сущности «доска», соответственно в интерфейс админки добавляется его представление, в контроллере админки оно связывается со свойством, и тогда обработка в генераторе страниц будет зависеть от двух свойств, т.е. (псевдокод) if Board.Property.Spoilers_Allowed and then Post.File.Spoiler then Generator.decorateFileRepresentation (Post.File); end if;

Ну а чего ещё вы сделаете без привлечения волшебных гномиков?

>>20966
>А каким боком тут административный интерфейс?
Делать для каждой доски разные настройки спойлера?

>>20967
Что ви таки собхалися там настхаивать?

>>20968
http://410chan.org/dev/arch/res/17371.html#20366

>>20969
>«Опционально: возможность задать для разных досок разные заглушки»
Ну и?.. Сущности «доска» добавляется ещё одно свойство “Spoiler_Image” (с фолбеком на дефолтную кахтинку в папке ${Board.Name}/src или где у вас там хесухсы доски хъанятся). Впиливаете в бэк эту функциональность, там видно будет, стоит дальше ковыхяться с фхонтом админки или не нужно оно вообще.

>>20970
>Впиливаете в бэк эту функциональность, там видно будет, стоит дальше ковыхяться с фхонтом админки или не нужно оно вообще.
Очевидно, что функциональность без удобного воплощения бесполезна, иначе бы и баны проводились через iptables.
Дальнейшую лирику вижу бессмысленной.

Никто не хочет запилить https://bitbucket.org/Therapont/fbe-410/issues/17/410 уже наконец?

>>21748
Ок.
> создание специального конфига
В config.php или в админке?

>>21749
Лучше в админке галочку ставить, конечно.

>>21750
...в общем, я взглянул на ту монструозность, что получается в SQL-запросах на модификацию опций доски и последние две ночи я прикручиваю вменяемый DBO вместо mysqli. Так как это скорее всего я и не сегодня закончу, и до тестирования этого руки у всех дойдут нескоро, то я лучше сегодня-завтра сделаю версию через конфиг. А через БД как-нибудь через месяц или когда одобрят/отклонят DBO, смотря что медленнее.

>>21779
Ок, делайте через конфиг.

>>21748
Хочу заметить, что меню с досками Ычана нет в /r, тогда как на Ычане ссылка на радио есть.

Помню, кто-то всё бухтел, что строка «[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]» ни во что не обёрнута, но после публикации исходников воз и ныне там.

>>21816
Кто-то забил на украшательства и юзерстили, и теперь ему в общем-то все равно.

Въ ычаноменю нѣтъ /tu.

>>21826
Потому что это доска Новеря.

>>21826
Действительно.
Со следующим обновлением будет.

>>21828
Тогда ещё abe, vo и es.

Ничего не понимаю, зачем сделали список досок ычана сверху?

>>21860
>Для улучшения интеграции

>>21860
Руководство Ычана, очевидно, полагает, что не все бородатые сорокалетние админы, отыгрывающие здесь маленьких девочек, знают о существовании Ычана.

>>21866
Если пользоваться шапкой для навигации вместо фрейма, то при переходе в тот же дев с ычана обратно в вг так просто не вернуться. С новой шапкой можно.

>>21868
Ладно, уговорил. Пусть будет.

Наконец, тикет для «Быстрого ответа» готов.
https://bitbucket.org/Therapont/fbe-410/issues/21/

Близится середина мая 2019 года, и в настоящее время по адресу https://caniuse.com/#feat=webp сообщают уж, что поддержка WebP появилася у ≈79% пользователей браузеров во всём мірѣ — и, в частности, у ≈70% в России. (Скриншот прилагаю.)

Это большинство более значительное, чем две трети.

Ввиду этого предлагаю мнение >>20916 пересмотреть: не «выждать время, чтобы все старые версии умерли» (чего много лѣтъ ещё, может быть, пришлось бы дожидаться), а просто-напросто подпереть старые версии посредством https://webpjs.appspot.com/ или другого аналогичного по своему дѣйствію костыля — и тѣмъ невозбранно достигнуть желаемого.

По поводу issue https://bitbucket.org/Therapont/fbe-410/issues/13/html
".html" в конце ссылок имеет семантику, если присутствует расширение, то точно понятно, что это ссылка на статичный файл, если расширения нет, то страница, должно быть, генерируется динамически либо ссылается на index.html. Если убрать расширение, то это существенно ухудшит читабельность исходников.
Если убрать расширение со всех ссылок на страницах, то так же потребуется изменение конфигурации Apache, чтобы он резолвил ссылки без ".html" на конце на файлы с ".html", то есть требуемые изменения выходят за пределы кода, выложенного в репозитории.
Для экономии трафика давно придумали mod_deflate, который включается в конфигурации довольно просто: https://knackforge.com/blog/karalmax/how-enable-gzip-compression-apache и трудозатраты по его внедрению намного меньше, чем выпиливание расширения из всех шаблонов в движке, да и apache все равно придется настраивать. Что же по эффекту, то сравним страницу /b/:
Исходная: 103 228 байт
Если убрать ".html": 102 143 байт
Экономия: 1%
Нетрудно посмотреть в админке общее количество html файлов, и посчитать, сколько же места на hdd сэкономит этот 1%. В десятки раз больший эффект даст удаление всех незначащих пробелов и табуляций из файлов, которые являются артефактами при генерации шаблонов, но сделать это в таком движке непросто, так как тут повсюду используется тупо конкатенация строк.
Если же применить сжатие: https://www.whatsmyip.org/http-compression-test/?url=aHR0cHM6Ly80MTBjaGFuLm9yZy9i
Сервис говорит, что экономия составит 82.8%, причем сжатие не будет ограничиваться html-файлами, но так же распространяется на js, css и svg.
Конечно, экономия будет только в трафике, место на hdd будет заниматься прежнее, но нужна ли эта экономия?
На скорость генерации файлов "лишние" 5 символов влияют чуть менее, чем никак (может за все время существования Вселенной и наберется пара секунд). Накладные расходы на сжатие файлов так же пренебрежительно малы по сравнению с экономией трафика, страницы так будут грузиться в разы быстрее.
tl;dr: включайте сжатие gzip и не страдайте фигней.

>>21997
> Для экономии трафика давно придумали mod_deflate
> tl;dr: включайте сжатие gzip и не страдайте фигней.
Для HTTPS включать сжатие по широко известным причинам нельзя без дополнительных предосторожностей, если на страницах есть элементы с других сайтов. Модуль mod_deflate уже научился отключать сжатие при использовании TLS для ответов на те запросы, у которых сторонний Referer?

>>22001
Так как в теле статичной страницы не содержится ровно никакой чувствительной инфы, никаких приватных ключей, и ничего секретного, то я не вижу, как тут применим CRIME/BREACH и какие такие печньки им можно своровать.

>>21997
Это далеко на самая приоритетная задача, которую никто особо не продвигает. Нам в первую очередь нужно отмеченное высоким приоритетом на трекере.
>сравним страницу /b/
Эта там, где картинкопостинг и минимум дискуссий со внутренними ссылками, лол?

>>22002
> какие такие печньки
Модераторские или администраторские, пароли на удаление постов и тредов, пароль от трипкода Мицгола.

>>22020
Там слово "печеньки" употреблено условно. Дело в том, что все атаки, эксплуатирующие gzip + TLS, способны только лишь расшифровать тело ответа сервера, но не заголовок ответа (который и так не сжимается), то есть если в HTML не будет написано: "пароль от трипкода Мицгола: fidonet", то и узнать его нельзя. Можно лишь расшифровать тот же текст файла .html, который и так находится в свободном доступе. А так как нет инфы, то нет и уязвимости. Включать сжатие для таких страниц можно смело.
Для страниц админки можно сжатие не включать.
>>22004
В этом тикете обозначена вполне валидная проблема, но неэффективный метод ее решения. Выбор страницы абсолютно не важен, на любой странице будет в десятки раз больше экономия места от удаления пробелов, чем от удаления расширения .html, да и почему только ".html"? Почему не удалять ".jpg", ".png", и прочие расширения из ссылок? Почему бы не сократить названия css-классов "r" вместо "reply", "t" вместо "thrdcntnr", это все уменьшит количество драгоценный байтиков еще больше. Вот только делать это бессмысленно: экономия в 1-10% погоды не сделает, в результате только еще больше изуродуется страница, а эффект от этого заметен не будет. А вот экономия трафика в районе 80% - это другой разговор.

Не движок, но обсуждение, что делать с забивкой канала у 410чана.
N.B.: я вообще ничего об этом не знаю, и просто кидаю ссылки.

1. https://blog-en.openalfa.com/how-to-limit-the-crawl-rate-of-bots-in-a-website советует директиву Crawl delay в robots.txt . И лезть в настройки самих поисковиков.
2. mod_qos/mod_evasive/mod_bw . Но это надо настраивать
3. Банить или лимитировать юзерагенты поисковиков. Минус: 410чан будет не видно.

Я ещё тут это продублирую. В субботу мы проверили пулл-реквест № 34 и увидели, что там переключалка стилей утратила вертикальное центрирование относительно навигационного меню и съехала вверх.
Пока это не будет исправлено, мы не будем принимать эти изменения.
(Я не смог сам это починить.)

>>22183
В общем, отступ у селекта помог.
Впрочем, если есть более изящные решения, можете предлагать.

>>22207
Это не "помог", это 3.14десу.

>>22209
В мобилковерсии ещё хуже.

>>22183
Убери отступ, поменяй на
.adminbar select{
vertical-align:sub
}

>>22209
>>22210
>что такое кэш

>>22212
>что такое абсолютно неюзабельный интерфейс, if-modified-since и другие полезные вещи

Соус, ты шатаешь? Почему Автобус падает?

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

>>22214
Поисковый бот «Яндекса» забивает соединения. Если так и продолжится, забаним в итоге.

>>22216
> Если так и продолжится, забаним в итоге
Зачем вообще роботы дозволены? Неужто в 2018 есть надежда на легитимный трафик из поисковиков?

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

>>22226
В кодобазе есть какая-то имплементация поиска уже.

>>22226
Так как в конечном счёте решать Совусу, то заинтересованные могли бы поднять свою дампалку с любым поиском. Или попросить кого-то ещё её сделать (например, Якуя, у которого уже есть дампалка Иичана).

>>22068
Ычан, кстати, за последний год добавил этот самый Crawl-delay.

>>22068
И настройте VirtualHost чтобы всякая лабуда навроде 1337.410chan.org не отдавала ничего.

>>22242 Чем оно мешает?

>>22243
Сценарий 1: поисковик сканирует 410чан.орг и обновляет по протухаемости.
2. Поисковик сканирует 410чан.орг и любую другую комбинацию и проверяет по протухаемости каждую.

Понаходил всякой нежелательной лабуды в поведении скриптов.
https://bitbucket.org/Therapont/fbe-410/issues/30/
https://bitbucket.org/Therapont/fbe-410/issues/29/

>>21997
Заморозил эту задачу, потому что она пока не нужна всё равно.

Предлагаю отключить функцию "[Первые 100 сообщений] [Последние 50 сообщений]", отключается она через config.php:
$cf['KU_FIRSTLAST'] = false;
Аргументы, почему это стоит сделать:

• эта функция не востребована, в яндекс.метрике наверно можно посмотреть статистику по посещениям файлов "x-100.html" и "x+50.html", скорее всего она нулевая.
• на каждый тред генерируется два лишних файла, что в 3 раза увеличивает занимаемое место на диске и на столько же замедляет ответ сервера при постинге.
• Лишние файлы генерируются для любых тредов, где ответов больше 100. Тред со 101 ответом так же получит дополнительные файлы. При этом ни одному пользователю не придет в голову экономить трафик на 1 посте. Даже на 200 ответах загружать только 100 или 50 из них не рационально, учитывая что сообщения могут состоять из одной строки.
• Огрызки тредов индексируются поисковиками, в результате генерируется лишний трафик, в выдаче образуются дублирующиеся результаты, при переходе по которым будет видна только часть обсуждения с постами, выдранными из контекста.
• Огрызки тредов попадают в архив, хотя казалось бы, зачем они там.

Возможно — баг, возможно — фича, возможно — я что-то недопонимаю. С PHP вообще в первый раз сталкиваюсь.

Описание:
При

• Установке движка в какую-либо подпапку в корне сервера (в примере — в /srv/http/fbe-410/), а не в корневую папку сервера (в примере — /srv/http/);
• И (согласно комментариям в config.php, получаемом копированием из __sample-config.php) правильно выполненной соответствующей настройке, а именно:

$cf['KU_ROOTDIR']  = '/srv/http/fbe-410/';

$cf['KU_WEBFOLDER'] = '/fbe-410/';

$cf['KU_WEBPATH']   = '/fbe-410';

Конструируются неверные пути к CSS и JS, вследствие чего они не загружаются браузером. А именно — в генерируемых HTML указываются ссылки на скрипты/ресурсы не по их абсолютному пути, а по пути относительному.

Так, для приведённого выше примера инсталляции, при обращении к http://localhost/fbe-410/ (к kusaba.php) в HTML будут ссылки вида:

<link rel="stylesheet" href="fbe-410/css/sitemenu_umnochan.css" title="Umnochan">

<script src="fbe-410/lib/javascript/kusaba.js"></script>

<link rel="shortcut icon" href="fbe-410/favicon.ico">

— то есть ссылки не по абсолютному пути, указанному в cf['KU_WEBFOLDER'] и cf['KU_WEBPATH'], а по пути относительному, что приводит к тому, что браузер пытается обратиться, скажем, не к http://localhost/fbe-410/lib/javascript/kusaba.js, но к http://localhost/fbe-410/fbe-410/lib/javascript/kusaba.js, который, очевидно, не существует.

Предполагаемые причины:
В __config-sample.php и в получаемом как его копия config.php содержится следующий код:

$cf['KU_WEBPATH']    = trim($cf['KU_WEBPATH'], '/');

$cf['KU_BOARDSPATH'] = trim($cf['KU_BOARDSPATH'], '/');

$cf['KU_CGIPATH']    = trim($cf['KU_CGIPATH'], '/');

$cf['KU_BOARDSPATH'] и $cf['KU_CGIPATH'] до этого приравнивается значение $cf['KU_WEBPATH']

Уничтожающий символы '/' слева и справа для этих путей (trim по '/'). Уничтожая символы '/' слева, он превращает абсолютные пути в $cf['KU_WEBPATH'] и прочих в пути относительные, что, судя по всему, и приводит к неработоспособности скриптов и CSS.

Предлагаемое решение:
Удаление этих строчек полностью решает эту проблему. Вследствие чего предлагается удалить/закомментировать оные в __config-sample.php. Проблемы для инсталяций в корень сервера это создать точно не должно, поскольку в таком случае $cf['KU_WEBPATH'] вроде как должен быть равен пустой строке, а на неё наличие/отсутствие trim'а не влияет в принципе.
Или же дополнить комментарий к $cf['KU_WEBPATH'] кратким описанием оговариваемой проблемы и методом её решения в случае, если более эффективное решение удаленим/комментированием trim’ов не приемлемо.

>>22306
То есть, единственный аргумент заключается в архивации. И это не проблема данной функции, которая никому не мешает и может быть востребована на мобилках (кто-то упоминал, что пользуется ей именно в таком контексте), а проблема архивации, которую надо переосмысливать в целом. Дополнительный файл место занимает? Ну да. А всякие формы постинга и прочие бесполезные штуки в коде самих страниц место не занимают? И ещё вёрстка едет с каждым обновлением ЦСС.
Надо какой-то мегатикет под это дело сочинять, которым всё равно никто не будет заниматься.
Тут ещё всплыла проблема, что уменьшенные картинки в ответах не архивируются. Но до выходных нет возможности проверить, от движка это или от сервера.

>>22323
Образец конфига основан на 410чановском по самоочевидным причинам.

>>22324
> То есть, единственный аргумент
Аргументов приведено 5 разных, и архивация на последнем месте по значимости. А пользуется ли этой функцией хоть кто-то на мобилках, должно быть ясно из метрики. Если не пользуется, то нет причин ее держать включенной.
> А всякие формы постинга и прочие бесполезные штуки
Это не бесполезные штуки, а обязательный контент страниц, без которых сайт не будет работать.

>>22325
>обязательный контент страниц, без которых сайт не будет работать
И что же перестанет работать, если из архивных страниц формы постинга и прочие бесполезные для архива вещи вырезать, наркоман?

>>22326
Ну при чем тут архив? Эти +50-100 занимают место в массе своей не в архиве, а в обычных тредах. Проблема FirstLast-файлов к архиву имеет мало отношения, просто интересно, чем руководствовался тот, кто писал этот код, когда решил, что из тоже нужно туда сохранять.

>>22324
Кстати, вы может пароль БД и затёрли, но пароль от спец. трипов, похоже, нет.

>>22324
>Образец конфига основан на 410чановском по самоочевидным причинам.
А он, в свою очередь, основан на поставлявшемся вместе с Кусабой конфиге, да. Это обстоятельство очевидно из содержимого конфига-образца.

Таким образом, является ли это очевидное обстоятельство серьёзным препятствием для внесения исправления обсуждаемого бага или создания заметки о нём в комментариях? Будет ли протестировано/принято предложение по его исправлению? Например, если я сделаю соответствующий pull request с изменением образца? Если же необходимо довольно точное (всё, кроме конфиденциальных сведений) соответствие образца, с использованием которого ведётся разработка, 410чановскому конфигу, то как минимум краткий комментарий с заметкой о возможной проблеме определённо можно включить и в 410чановский конфиг, и в sample.

Что же до нужности… Это поможет, в частности, и потенциальным новым разработчикам, в случае если они решат поставить у себя FBE, таким же, как и у меня, образом. Да и неужели задача доработки FBE до состояния, при котором его можно легко и безпроблемно развернуть в отрыве от 410чана и не в точности таким же, как на 410чане, образом, сама по себе не интересна?

>>22330
>Да и неужели задача доработки FBE до состояния, при котором его можно легко и безпроблемно развернуть в отрыве от 410чана и не в точности таким же, как на 410чане, образом, сама по себе не интересна?
Кому интересна, лол? Это движок «410чана», допиливаемый в интересах «410чана». Что вы там собрались делать в отрыве — исключительно ваша личная трагедия.
Нам не хватает свободного времени, чтобы тестировать код, который исправляет действительно проявляющиеся на сайте баги и недоработки, а вы ещё предлагаете заниматься техподдержкой хѣръ знает кого ради хѣръ знает чего.

>>22332
>ваша личная трагедия
Ох ты ж, какие эпитеты.
Достаточно было прямо ответить да/нет.

>вы там собрались
Поставить FBE, посмотреть, как он работает, понять, что из ticket’ов я могу и буду делать и буду ли. Пока ещё только смотрю-с.

Никто не хочет заняться https://bitbucket.org/Therapont/fbe-410/issues/25/ ? По идее, там ничего сложного не должно быть.
Сами CSS-файлы можно не ковырять, с этим я сам справлюсь.
И ещё новая задача, тоже связанная с главной: https://bitbucket.org/Therapont/fbe-410/issues/32/

>>22452
Первый тикет — плохая идея. Наоборот лучше оставить глобальный стиль для служебных страниц отдельным, а объединить оформление текстовых досок и картинкодосок одним условным board.css, возможно, правкой кусабашаблона первых. Все темы вынести только на уровень перекрашивания элементов и сделать единой системой для всех страниц.
Почему: на досках нет элементов со служебных страниц, в свою очередь на служебных страницах нет всех элементов досок, а объединение глобального стиля в свою очередь означает загрузку лишних свойств и утяжеление страничек служебных на много и досок на не очень. Так же с унификацией системы тем отпадает нужда в ориентации на старые костыли с ней связанные.

>>22453
Плохая идея — это сейчас, когда зоопарк файлов с двумя разными переключалками стилей (одна из которых сломана).
Вы говорите, что там общих элементов нет? Так это следующий этап, лол. Туда точно надо встраивать навигационное меню, чтобы служебные страницы можно было использовать без фрейма (и вообще перестать этот фрейм людям по умолчанию совать).
Какое утяжеление страничек, лол? CSS, которые у всех и так закэшированы, на вырастут пару килобайт (причём в кэши зато не будут лежать упразднённые файлы из тех же пары килобайт)? Да и плевать, лол.

Это очень важная задача, которую я давно жду, чтобы начать дальнейшие изменения.

>>22454
Имелось в виду… впрочем, ладно. Само собой вынести в global.css всё повторяющееся, а в board.css и pages.css оставить полшишечки уникальных идентификаторов.
Скажи, ты стили-темы унифицировать пока не собираешься?

>>22460
>Скажи, ты стили-темы унифицировать пока не собираешься?
Не собираюсь. Ибо что там унифицировать, если весь каркас и так лежит в img_global.css, а во всяких umnochan.css в основном остались только цвета всякие?
Не хотите работать над существующими задачами? Тогда хватит флудить в треде.

>>22462
Ну не стукай, не знал, что ты уже по большей части.
Кстати, переключалка стилей во фрейме вообще сломата. Ща потыкаю.

Для задачи https://bitbucket.org/Therapont/fbe-410/issues/25/ в файле /inc/func/html.php найден код, который прописывает на страницы дополнительные наборы стилей с префиксами site_ и sitemenu_.

Открыта новая задача https://bitbucket.org/Therapont/fbe-410/issues/33/ — Фоновая проверка заполнения форм. Она явно будет полезна и сама по себе, и для «Быстрого ответа» (https://bitbucket.org/Therapont/fbe-410/issues/21/)

А также куча старых задач, на которые всем плевать. Не знаю, зачем я это всё пишу вообще.

>>22560
Попробуйте стимулировать людей чем-то кроме пораженческих настроений и "нам это не нужно".

Надпись "Ныне 3156 unique user posts" зело razdrazhaet.
В config.php заменить бы сочетание "unique user posts" на "уникальных столбов". А вообще это число считает количество ip-адресов, с которых отправлялись столбы.

>>22904
Уникального пользователя столбов.

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

>>22930
Сделать это возможно это только лишь так, как сделано в кукле: аяксом отправлять форму и при ошибке показывать попап.
Все остальное может только добавить проблем и багов. Тикет действительно написан так, что остается только чесать голову.
Только нафига оно нужно, если кукла эту проблему решает давно и хорошо.

>>22930
Зачем, если есть required, maxlength и прочие accept?

>>22932
В кукле и у меня тупо AJAX-постинг. Его сделать довольно просто, только это не «Фоновая проверка заполнения форм», а «Фоновая отправка форм» с последующей обработкой ответа сервера.

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

>>22956
Где есть? На бэке нету; в бэк придётся впиливать некий DSL и на его базе генерировать формы в шаблонизаторе.

>>22959
Пхп сам шаблонизатор.

>>22959
>только это не «Фоновая проверка заполнения форм», а «Фоновая отправка форм» с последующей обработкой ответа сервера.
Вы сами это придумали, там нигде не сказано, что надо проверять до отправки.

>>22990
Мы придумали только то, что написано здесь и в ведре. Т.е. ви таки хотите фоновую проверку, которая выглядит как AJAX-постинг, данные отсылает прямо как AJAX-постинг, результаты обрабатывает как AJAX-постинг, но не AJAX-постинг? А механизм, который по мере заполнения пользователем формы проверяет корректность введённых данных и высвечивает ошибки если не, ви таки не хотите?

Есть мысль по поводу «мегатикета», призванного решить все проблемы с архивом.
А что если не заморачиваться с починкой движка, а просто написать внешнюю никак от него не зависящую скриптоту на любом языке, которая тупо парист html-файлы в архиве, а взамен выдает свои html, где нет ничего лишнего, стили свои встроенные, так что ничего потом не поломается и вообще. Есстественно, проблема в том, что парсер должен быть достаточно всеядный, чтобы корректно работать со всеми изменениями за последние 10 лет.
Скрипототу можно вручную временами запускать, или же создать в cron'е задачу чтоб периодически сканировала директории с архивом на наличие новых файлов.
И потом никакая доработка движка, которой никто не будет заниматься, не исправит архив за эти 10 лет, файлы так и останутся кривыми.

Пока preview’шка находится в фокусе, её картинка не меняется обратно на preview для spoiler’а. Так и должно быть?

>>23210
УМВР.

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

>>23128
Звучит, как ничем не обоснованный костыль. Почему нельзя это делать на стороне движка (кроме старых файлов)? Потому что лично вы не хотите дорабатывать движок? Ну, проходите мимо. А вот лично я не хочу возиться с левыми костылями, которые потом придётся поддерживать отдельно от движка. Не для этого исходники открывались.

>>23210
Под мобилками нет концепции курсора и его наведения, так что, видимо, так и должно быть.

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

Короч, шоб всё было в жсонах, аяксах и конечно же на базе Кусабы.

>>23259
>Тыжпрограммисты ведь как известно обладают бесконечным запасом свободного времени
Зато теоретизировать, не глядя в код, у этих мегапогромистов время есть. И обидки кидать, если их идею отклонили, будто бы им кто-то что-то должен, тоже время есть. На всё время есть, кроме написания кода, ага. А, ну и на аргументы, конечно, ведь вместо них сразу идут обидки.
Ещё раз:
>доработка движка, которой никто не будет заниматься
Потому что вы ск0зали?
Никто вчера прикрутил спойлеры? Никто прикрутил видосы? Никто исправил кучу багов?
Нет, это не никто, это всё вполне конкретные люди. Да, у нас с ними бывают разногласия, но мы им благодарны за их вклад. Вы не хотите ковырять этот движок? Это ваша проблема и ваши обидки на злого меня никак этого не изменят.

>>23253
Вам уже два человека говорят, что не понимают, чего вы хотите.

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

Костыли на JS имитируют браузер без JS — отправляют форму, как это делает браузер без JS, и принимают ответ, как это делает браузер без JS; из ответа вытаскивают строки ошибки и показывают их во всплывающем окошечке. Это называется AJAX-постинг.

Вы вот именно это хотите, или что-то другое?

>>23269
>Зато теоретизировать, не глядя в код, у этих мегапогромистов время есть...
Если вы такие все из себя чёткие, конкретные и самодостаточные, и лучше других знаете, что, как и когда делать, то смысла выходить из привата в паблик нет. Потому что будут крокодилить, будут спрашивать об одном и том же, будут не понимать и требовать разжевывания тех вещей, которые вам ясны аки день Бажий, будут фантазировать, как бы они это сделали на своём стэке, и как это вообще можно сделать, будут шутить про отсталость и прочее «говно мамонта», предлагать переписать на Node.js или другой стэк, интересный крокодилам, будут обижаться на отказы. Вот зачем, чтобы впоследствии публично же возмущаться, что вот мол ходють тут всякие, тереотизируют всякое, спорють о чем-то своем, а к станку хозяйскому вставать не хотять; кармодрочерство на основе количества коммитов устраивать?

>>23271
Ну, я в третий раз могу вас спросить: а нельзя ли оптимизировать ответ сервера после отправки и проверки этих данных, чтобы эти заглушки-уведомления генерировались и выдавались пользователю как-то более изящно, чем просто ныне существующие HTML-страницы со всем лишним мусором, обёрнутые в костыль, чтобы этот мусор спрятать?
Как мне ещё спрашивать, чтобы вы, наконец, попытались это прочитать и внятно ответить?

>>23269
Конечно, кроме платинового ответа я ничего другого не ожидал.
> Потому что вы ск0зали?
Потому что вы ск0зали. Не далее чем в >>22324 посту. И я склонен с этим согласиться, та задача, в представленном виде, не выглядит выполнимой.
> Зато теоретизировать, не глядя в код
Откуда такие выводы? Тот, кто не видел код Кусабы наоборот считал бы, что все это легко допиливается. Тот же, кто его хоть раз видел, при первом упоминании о нем хватается за голову.
> На всё время есть, кроме написания кода
На написание кода время есть. Но на проделывание в десятки раз большей работы, чтобы добиться того же результата, времени и желания не будет ни у кого.
Вот AJAX-постинг. Здравый казалось бы реквест, полезная фича. Но вам нужен не просто AJAX-постинг, вам нужно чтоб ответом был не простой HTML, который можно распарсить, а JSON с кодом ошибки или еще что, чтоб не было "как в костылях", и таким образом одним росчерком пера задача на пару часов, затрагивающая только фронтенд превращается в задачу на пару недель, в которой надо перелопатить половину бекэнда. По сути, нужно поверх существующего постинга пилить API, да еще сохраняя совместимость с легаси.
Спорить о целесообразности такого решения учитывая дополнительные трудозатраты (значительные) и эффект ими достигаемый (никакой) бесполезно: "Ваши аргументы - не аргументы", "Кроме ваших аргументов у вас нет аргументов".

>>23275
>Конечно, кроме платинового ответа я ничего другого не ожидал.
А вы большего не заслуживаете, увы. Вы не хотите разбираться в существующем коде, вы не хотите задачи на две недели, а хотите на два часа, вам не нравятся используемые технологии, вам не нравлюсь лично я и т.д. и т.п. Так хорошо же. Это ваш выбор, ваши интересы, ваше свободное время. Но нахѣръ тогда тут писать простыни о том, как вам не подходит этот проект, лол?
Нытьё о том, что эта сложна, аргументом не является.

А вообще, для всех мегакодеров, которые не хотят писать код, у меня тоже найдётся задание на чистом ӁС+ХТМЛ. Правда, для другого супермаркетовского сайта.

Вообще, мне кажется, до отправки можно было бы проверять сам факт заполнения, чтобы нельзя было послать пустое сообщение или ОП-пост без картинки.

Новые тикеты:

• https://bitbucket.org/Therapont/fbe-410/issues/34/ Пагинация новостей на главной: низкоприоритетная задача для ныне не используемой нами функции. Чтоб новости на главной разбивались на страницы по мере накопления записей.
• https://bitbucket.org/Therapont/fbe-410/issues/35/ Переделать текстовую кнопку «Развернуть все изображения» в значок: самоочевидное. Задача минимум вообще тривиальна, но там надо глянуть на поведение скриптов, потому сейчас они подпись подменяют, если картинки развёрнуты.
• https://bitbucket.org/Therapont/fbe-410/issues/36/ Упростить строку с именем и размером файла. Сделать как на «Ычане» недавно сделать. Да, надо ковырять шаблон.

Для https://bitbucket.org/Therapont/fbe-410/issues/21/ (Быстрый ответ) уточнил параметры задачи в комментариях. Возможно, совать кнопки к сообщениям прямо в шаблон, а не скриптом, как на «Ычане» — не лучшая идея, ибо в перспективе можно будет приделать настройки (отключить быстрый [убрать значок], совместить традиционный и быстрый ответы [со значком], оставить только БО [без значка/со значком]).

>>23507
>Сделать, как на «Ычане» недавно сделали
Опечатка.

Ой, а я что-то забыла...

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

Если ничего, то проще привести в порядок поломанные сейчас сообщения и обернуть ошибки MySQL в ошибки бизнес-логики, сделать им статус отличный от HTTP 200 и смириться с тем, что для пары строк несётся очень много мусора.

Иначе есть два подхода:

1. Для “server side rendering” с сервера отдают отрендеренные куски HTML-а (partial rendering), например, <f:ajax render="element_id" /> в JSF отдаст заново отрендеренный кусок начиная с element_id. Надо чтобы шаблонизатор поддерживал такой вид рендеринга, иначе впиливание его самостоятельно выльется в разработку мега-фреймворка, аналогичного JSF.

2. Для “client side rendering” рендеринг выносят на клиент, а на сервере колхозят JSON-RPC, которое переносит только команды, их параметры и результаты их выполнения, соответственно надо или делать отдельный эндпоинт (и контроллер), который понимает только JSON и только это RPC, или заморачиваться с механизмом content negotiation для существующего контроллера, который будет по заголовкам пытаться угадать, в каком виде пришли, кто их должен обрабатывать и в каком надо отдавать данные. Пока что это наилучший вариант по соотношению мусор/полезные_данные. Однако всё может упереться в архитектуру приложения, поскольку это — вторая пара View-Controller для одной бизнес-логики, и если никто о таком кейсе на этапе проектирования не думал, придётся переделывать очень многое.

>>23374

реквестуем

>>23602
В общем, реалистично было бы брать в разработку именно вариант со скриптами, которые дёргают ХТМЛ как есть, видимо.

>>23633
Насколько я помню PHP, выходит что так.

З.Ы.: Ты обсуждения здесь вообще читаешь? Например, отсюда >>23614 и выше.

Всё хотел сообщить. На страницах с частичным отображением содержимого нити нумерация не соответствует порядку постов в нити: она не учитывает неотображаемые посты. То есть, нумерация не соответствует порядку постов в нити, а вместо этого соответствует лишь их расположению на странице.

>>23753
При текущей реализации это не починить.

>>23602
>штатный запильщик
Отличная шутка.

>>23753
>>23782
Технически это возможно, если первому элементу
>.reply span.reflink
Добавить класс reflnik-first, и затем задать для него такое правило:

span.reflink-first::after {

    counter-increment: num+197 !important;

}

Вместо 197, конечно же, надо подставить количество пропущенных постов + 1 (оп-пост). Результат можно увидеть на пикрелейтед. Вопрос только в том, где и как этот кусок стиля создать и поцепить на элемент. И второй вопрос, почему это всё вообще важно?

С изначальным автором кто-нибудь смог выйти на связь за эти два с половиной года? Или он реально... умер?

>>23813
>С изначальным автором
Автором чего?

>>23818
Промах тредом.

После отправки поста меня редиректит из треда на уровень вверх - на доску. Судя по тому, что никто об этом не пишет нигде, то я подозреваю, что так задумано.
Но неудобно же.

>>23873
Используй noko

Ну щта, никто так и не выучил «Ӂаваскрипт», чтобы запилить «быстрый ответ»?

>>23927
>>23927
Если отказаться от пункта
> Существующая версия «Быстрого ответа» упраздняется
А так же
> пользователь может потянуть за заголовок, чтобы открепить её и двигать по экрану
И просто сохраняя текущую реализацию вместо скролла наверх перекидывать форму под пост, то задача будет казаться более выполнимой.
Если такой вариант не устраивает, то возможно придется ждать еще три года.

>>23928
Ок, подождём. Нам нужен нормальный «быстрый ответ» как у всех, а не фигня какая-то.

>В Firefox 75 будет добавлена возможность отложенной загрузки изображений
(https://www.linux.org.ru/news/mozilla/15529229)
В хромоте уже есть, как я понимаю.
Как вы думаете, оно нам надо?

>>24001
При медленном и нестабильном интернете просматривать нити будет не очень удобно. Нельзя будет подождать пару минут, пока страница сайта загрузится полностью и тогда уже её читать. Да и при несколько более быстром интернете всё равно, подозреваю, будет виден процесс подзагрузки изображений thumbnail’ов, что по-моему не очень красиво. Я предпочитаю читать цельный статичный документ без прыгающих туда-сюда текстов, стилей и ленивых дозагрузок. Как посетитель, я против.

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

>>23929
Это выглядит вот так?

>>24018
Как это должно выглядеть, можно посмотреть на «Ычане».

>>24019
Но на Ычане версия из >>23928

>>24020
На «Ычане» не было предыдущей версии «быстрого ответа», которую надо отломать. У нас есть. Её надо заменить на новую.
На «Ычане» верхняя форма никуда не перекидывается, её можно использовать. Но под сообщением появляется форма «быстрого ответа».
Да, на «Ычане» нельзя откреплять и двигать форму по экрану. Но у нас, в отличие от, эта функция уже есть в скриптах для формы «избранных нитей». Какая проблема её присобачить к форме «быстрого ответа»?
На >>24018 какой-то кривой вырвиглаз просто. Так оно выглядеть не должно в любом случае. На «Ычане» оно выглядит именно так, как должно выглядеть здесь.

>>23928
>И просто сохраняя текущую реализацию вместо скролла наверх перекидывать форму под пост, то задача будет казаться более выполнимой.
Можно выложить эту версию?

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

Для начала никак нельзя обойти упоминанием то обстоятельство, что формат WebP представляет собою гугловскую попытку соединить под одним названием и под одним расширением файла, в сущности, три различных формата. Первый из них (lossy WebP) предназначается для сжатия изображений, совершаемого с потерями — идейным основанием для этого формата послужил формат ключевых кадров видеопотока VP8. Второй из них (lossless WebP) предназначается для сжатия изображений, совершаемого без потерь — этот формат не имѣетъ ни малѣйшаго отношения к VP8, а вмѣсто того сочинён на основе различных передовых методов сжатия информации (их по адресу https://developers.googleblog.com/2012/08/lossless-and-transparency-modes-in-webp.html перечислил тот инженер Jyrki Alakuijala, который-то и был проектировщиком). И есть ещё третий формат (animated WebP), который используется для хранения анимированных изображений, каждый кадр в которых хранится в одном из двух ранее упомянутых форматов — с потерями или без потерь.

Из этих трёх форматов только один (lossless WebP для сжатия изображений без потерь) я считаю действительно заслуживающим поддержки. Что же до двух других, то анимированный WebP не очень нужен на имиджборде, так как на страницах не используются никакие анимированные элементы или украшения, если не считать время от времени публикуемых пользователями цитат из кинофильмов, из аниме и всего такого — а всѣ эти послѣднія гораздо лучше смотрятся в современных видеоформатах (VP9 и тѣмъ болѣе AV1) и в таких контейнерах (WebM или MP4), в которые заодно можно всунуть и звуковую дорожку. Не очень-то нужен и lossy WebP для сжатия без потерь: репликою >>20925 я сообщал ужé о существовании исследования, проведённого Фондом Мозиллы и свидетельствующего о том, что достаточно сжатый файл JPEG не слишком превосходит собою по размѣру lossy WebP подобного ему качества. Притом по адресу https://nowere.net/b/res/167102.html#171866 я упоминал и про нѣкоторые досадные недостатки lossy WebP: обязательная цвѣтовая субдискретизация 4:2:0 (то есть всегда только один пиксел цвѣтности на 2×2 пиксела яркости), размѣръ не больше 16383×16383 пиксела, нѣтъ режима постепенной (чересстрочной) развёртки файла (то есть файл показывается по мѣрѣ загрузки всегда только сверху вниз), etc. Короче говоря, если хочется использовать такой формат сжатия с потерями, который был бы очень хорош въ своёмъ дѣлѣ, то уж лучше дождаться того, когда Joint Photographic Experts Group опубликует новую версию своего формата — JPEG XL; сознаюсь, что мнѣ хочется вѣрить, что это случится в нынешнем (2020) году, несмотря на всѣ короновирусныя трудности.

⬇️ ⬇️ ⬇️ ⬇️

А вот lossless WebP — это другое дѣло, как я чуть выше только что начинал уж говорить. К счастью, про такой формат, который предназначен для сжатия изображений, совершаемого без каких-либо потерь, нам не нужны никакие исследования, сравнивающие внѣшній видъ результатов съ тѣмъ видомъ, который обеспечивается конкурирующими форматами, и также не нужна сама постановка подобных https://nowere.net/b/res/167102.html#171819 вопросов о том, насколько та или иная метрика вида изображения соѿвѣтствуетъ или не соѿвѣтствуетъ человѣческому впечатленію. Наоборот, мы можем раз навсегда успокоиться насчёт качества сохранения изображений в этом формате: оно всегда стопроцентное — и обращать наше внимание единственно на выигрыш въ размѣрѣ файла. И что же? — оказывается, инженер Jyrki Alakuijala превосходно сдѣлалъ свою работу, так что в качестве конкурента для PNG (то есть для единственного формата сжатия полноцвѣтныхъ изображений без потерь, сейчас на имиджборде поддерживаемого, не считая архиваторных форматов в /dev) формат lossless WebP годится очень хорошо, упомянутую по адресу https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study#results способность сжимать содержимое большинства PNG-файлов (даже после переужатия их лучшими средствами переужатия PNG, совершаемого без потерь) ещё на 20% или даже на 40% (а в среднем — где-то на четверть) можно только попривѣтствовать, особенно когда в крупных файлах экономятся цѣлые мегабайты (то есть, для мобильных зрителей — полновѣсныя секунды их времени). Болѣе того: даже тот режим сжатия, совершаемого без потерь, которым будет оснащён грядущий формат JPEG XL, в представленном по адресу https://twitter.com/FidonetRunes/status/1236833595144040448 частном случае сжимает изображение не так сильно, как PNG (потому что проектировщики решили пожертвовать экономиею объёма в пользу большего распараллеливания декодирования и в пользу большей простоты извлечения ѿдѣльныхъ фрагментов изображения) — а вот lossless WebP даже в этом же частном случае сжимает болѣе чѣмъ на четверть сильнѣе, чѣмъ PNG.

Поэтому призываю администрацию запустить поддержку WebP на имиджборде.

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

На двадцать шестой минуте чифира >>/b/152677 прозвучал отказ от реализации поддержки WebP (цитату прилагаю), и отказ этот заключается в повторении смысла реплики >>20916 с таким видом, как будто ни отклика >>21953 не поступало, ни костыля https://webpjs.appspot.com/ не существует на свѣтѣ.

Ну 仕方がない тогда.

Что вы сделали с фотоном? Почему теперь шрифты не меняются?

>>24298
Размер и расположение элементов, шрифты и прочие вещи в темах оформления приводятся к единому виду.
Шрифты себе сами ставьте, какие хотите.

>>24309
Во-первых, зачем это делается? А во-вторых, ну этот фотон уже неторт получается. Шрифты ставить сложно. Не то чтобы фанат этой темы, но приятно серое нейтральное оформление.

>>24003

>>24004

Существование читателей с нестабильным доступом к Интернету — ещё не повод отказываться от «ленивой» загрузки иллюстраций, так как такие читатели вольны отключить «ленивую» загрузку изображений в настройках у браузера (скриншот прилагаю).

Главный вопрос заключается в другом: сидит ли 410чан на безлимитном траффике? — или же хостинговый тариф его предусматривает оплату траффика, побуждая включить «ленивую» загрузку изображений съ цѣлью экономии траффика?

На двадцать шестой минуте чифира >>/b/152677 было сказано:

> Потому что с WebP вам ужé ответили тут: когда Apple добавит поддержку, тогда приходите.

Ну пришёл.

По адресу https://developer.apple.com/documentation/safari-release-notes/safari-14-beta-release-notes#Media компания Apple сообщает, что поддержка формата WebP добавлена.

💢 Прилагаемая иллюстрация могла бы быть на 23,23% меньше по объёму без потерь, если бы 410чан поддерживал lossless WebP.

>>24557
По адресу сообщают, что вышла какая-то бета-версия для ещё не готовых систем.

Как я говорил, кого нетерплячка бьёт, могут пойти и разгрести высокоприоритетные задачи, чтобы мы могли позволить потратить время на их хотелки.

>>24569
То есть, пока не запилят новый Быстрый Ответ, можно не ждать? Ой-вей.

Это конечно та самая ситуация когда 20% усилий дало 80% результата, и потом надо будет долго ковыряться в мелочах, но хотел бы узнать ваше мнение.

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

Преимущества:

• Форма отправки на странице всегда одна, не надо кода ни для каких синхронизаций, дублирований и прочей головной боли;
• Благодаря этому все старые скрипты завязанные на форму вроде как работают;
• Благодаря этому при ошибке постинга не надо переживать, что контент формы пропал, делаем модору-модору и контент всё так же в форме вверху;
• Форма в быстром ответе висит над контентом и поэтому можно скроллить и цитировать нить, пока пишешь ответ, очень удобно в длинных нитях (например, Начинающих Программистов)
• Форму можно перетягивать и растягивать как душе вздумается ну, правда надо добавить ручку перетаскивания чтобы не конфликтовать с цветочком;

Сделать в таком же формате реализацию "а-ля ичан", где форма встраивается прямо под целевой пост также возможно, и это даже меньше кода, но сильно неудобнее для пользователя, как мне кажется.

Вобщем, скажите, что вы по всему этому поводу думаете.

>>24613
Во-первых, в тикете нарисовано, как должна выглядеть форма. Да, это важно.
Во-вторых, тут много критиковали плавающую форму, поэтому это должен быть альтернативный режим. Скажем, через кнопочку «открепить».
За техническую часть не скажу, но у вас есть все исходники, чтобы с ними работать.

>>24619
Внешний вид конечно же можно поправить, это прототип. Хотя тут конечно надо проследить чтобы красиво было во всех темах. Меня больше интересует ответ на вопрос, ок ли когда форма на странице всегда одна и просто откусывается из заголовка и доставляется куда надо для ответа силами jQuery?

Поведение встраиванием сделать проще, чем плавающее, но над реализацией переключения режимов надо подумать. Я так понимаю, что если форму открепили то она уже должна оставаться открепленной, пока не закрепят обратно?

>>24626
>ок ли когда форма на странице всегда одна и просто откусывается из заголовка и доставляется куда надо для ответа силами jQuery
Нет, скрытие формы — отдельная функция, которая с быстрым ответом никак не связана.

>>24634
А сейчас это как раз никакое не скрытие, потому и спрашиваю. В представленном видео форма физически откусывается из HTML в одном месте и подставляется в HTML в другом месте, указанном пользователем при клике на быстрый ответ. Так было проще всего сделать.

>>24613
>>24619
>>24634

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

На видрелейтед можно увидеть следующую реализацию:

• По-умолчанию быстрый ответ встраивается под пост, а-ля ичан
• В любой момент можно потянуть форму за заголовок, и тогда она открепится, форму в таком режиме можно перемещать свободно, она будет висеть над контнетом
• В открепленном режиме теперь работает цветочек, по очевидной причине
• Если открепленную форму не закрывать, она так и продолжит работать в этом режиме, как и требуется
• Если форму закрыть и открыть снова, она переключится обратно в режим "а-ля ичан"
• Пока что всё работает вокруг принципа старого принципа "одна форма с доставкой по требованию"

Пишу этот ответ прямо из нового прототипа формы, удобно, что сказать

Нельзя ли сделать редирект в архив для ссылок на старые посты?

>>24677
Для этого скорее всего понадобится какая-то индексация архива, т.к. сам архив это по сути статичный HTML файлик, открепленный от движка, и функция которая достает вам пост по ссылке из базы оттуда ничего не достанет.

По возможности, хотелось бы всё же узнать мнение администрации по поводу прототипа быстрого ответа №2, показанного в >>24676 мне хотелось бы знать, надо ли вносить еще какие-то изменения, или пора приступать к оформлению кода в пулл реквест.

>>24686
Я вижу, что >>24634 автором успешно проигнорировано. Цветочек тоже добавлять не нужно, что нетрудно заметить на картинке в репозитории.
Закрепление/открепление сделано неинтуитивно (и неудобно), поэтому выше и предлагался вариант через отдельную кнопку, что автором также проигнорировано.
Почему автор изобретает велосипеды вместо общепринятых реализаций, мне неясно.

>>24688
Хорошо, пойду готовить следующую итерацию.
С цветочком забавно вышло, я думал его просто не учли на макете.

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

>>24676
>>24688

Как и обещал, сделал следующую итерацию быстрого ответа. Смотрите видрелейтед.

Основные изменения:

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

Требуется мнение администрации, надо ли еще вносить какие-то изменения?

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

>>24697
Никаких препятствий для того чтобы иметь такой двойной функционал нет. Если администрация не возражает, то так и сделаю.

>>24695
Активированный значок закрепления лучше с подложкой делать, как у нитей.
На соседнем сайте оно при возвращении назад в браузере умеет текст сохранять. У вас как?

>>24698
Можно, наверное.

>>24701
>Активированный значок закрепления лучше с подложкой делать, как у нитей.
Вот так как на пикрелейтед, или как-то поменять цвета?

>На соседнем сайте оно при возвращении назад в браузере умеет текст сохранять. У вас как?
Модору-модору работает. Скажем, если ввести неправильно фапчу, увидеть ошибку и вернуться, то старый текст будет в основной форме ответа. При повторном нажатии "быстрый ответ", текст из основной формы скопируется в форму быстрого ответа автоматически.

>>24702
>Вот так как на пикрелейтед
Да. Но вообще, вам достаточно сделать, чтобы оно нормально настраивалось через ЦСС, там уже я сам разберусь, если что.

>>24703
>Но вообще, вам достаточно сделать, чтобы оно нормально настраивалось через ЦСС, там уже я сам разберусь, если что.
Хорошо.

Еще пара чисто технических вопросов.

1. Быстрый ответ должен быть доступен изнутри самой нити? На соседнем сайте доступен.
2. Форму быстрого ответа нужно вносить в шаблон, или она тоже должна добавляться скриптом, как и кнопки?

Если других замечаний нет, начну оформлять код для пулреквеста.

>>24704
>Быстрый ответ должен быть доступен изнутри самой нити? На соседнем сайте доступен.
Самоочевидно, что да.
>Форму быстрого ответа нужно вносить в шаблон, или она тоже должна добавляться скриптом, как и кнопки?
Да вроде смысла нет это в шаблон совать, если оно работает полностью на скриптах.

>>24706
>Да вроде смысла нет это в шаблон совать, если оно работает полностью на скриптах.
Хорошо, пока оставлю так, а если что переделаем под шаблон. Буду тогда оформлять код, это скорее всего будет не быстро, но я везде напишу, как пулреквест будет готов.

А есть ли где-то исчерпывающий анализ фич имиджборд?

>>24710
Есть относительно исчерпывающая спискота разве.

>>24695
>>24706

Вашему вниманию представляется цветная, гипертекстовая, каскадно-стилевая, яваскриптовая форма быстрого ответа для Flower Bus Engine всё ради любимого 410го
Надеюсь всё понравится и критических недочетов в реализации нет.

Форма:

• универсальная будет работать для всех имиджборд на FBE, поддерживает все темы оформления и виды капчи
• настраиваемая через переменные и CSS для стилей / скрытия полей
• работает на околоактуальных мобилках и планшетах тут, как обычно нужны более широкие тесты
• отключается в случае ошибок, возвращая всё как было в том числе если не заводится на мобилке или планшете
• открепляется / перетаскивается кнопкой, или дёрганием за заголовок
• синхронизируется с основной формой ответа

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

Перед проверками не забудьте тщательно почистить кэш.
Если ваши доски используют капчу вместо фапчи, регенерируйте их.

Пулреквест уже создан.
Форма в разных оформлениях представлена на пикрелейтед.

>>24794
А почему на английском?

>>24795
А, просто язык зависит от выбранной локали.

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

>>24797
>при вставке номеров должны быть переносы строки
Не должны, чтобы делать мультиссылки.

>>24797
Всё это мелкие дефекты на самом деле. Собственно, чтобы их выявлять и устранять мы тут и рассматриваем всё.

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

>Во-вторых, текст из быстрого ответа должен дублироваться в форме ответа внутри нити, но нет никакого смысла совать его в форму создания треда при ответах с доски.
Это прямо недопустимо? На данном этапе в этом есть технический смысл. Могу пуститься в подробности, но в целом это самый дешевый способ сохранять и восстанавливать состояние формы при ошибках постинга до решения тикета 33.

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

А что должно происходить в этом случае при нажатии на No. ?

>и при вставке туда номера происходит рассинхрон двух форм, кстати
По идее, формы синхронизируются обратно как только вы начнете что-то печатать, но посмотрю.

>>24800
>Собственно, чтобы их выявлять и устранять мы тут и рассматриваем всё.
Могли бы уже сегодня всё развернуть, а теперь как минимум до следующих выходных, ага.
>Это прямо недопустимо? На данном этапе в этом есть технический смысл. Могу пуститься в подробности, но в целом это самый дешевый способ сохранять и восстанавливать состояние формы при ошибках постинга до решения тикета 33.
Вот соседний сайт почему-то умеет содержание быстрой формы сохранять при возвращении, как я упоминал в >>24701.
>А что должно происходить в этом случае при нажатии на No. ?
Это просто постоянная ссылка на сообщение, она работает как работает.

>>24801
>Могли бы уже сегодня всё развернуть, а теперь как минимум до следующих выходных, ага.
Жалко что так вышло, ничего не скажешь, но текущие дефекты поведения я бы сам не выявил. Локально проверять исправления у вас до выходных возможность есть?

>Вот соседний сайт почему-то умеет содержание быстрой формы сохранять при возвращении
Скорее всего потому что их форма не клонируется из основной. У вас где-то есть под рукой их реализация в читаемом виде?

Пока исправляю остальное.

>>24801
>>24804

Собственно, дефект переноса и дефект номерных ссылок устранены. Пулреквест пока не создавал, т.к. проясняем ситуацию с синхронизацией / сохранением формы.

>>24804
>У вас где-то есть под рукой их реализация в читаемом виде?
Ссылки в соседнем треде, где эти фичи и запиливались: https://github.com/WagonOfDoubt/iichan-extensions/blob/master/dist/iichan-quick-reply.js

>>24808
Спасибо

>>24808
>>24809

Любопытная реализация. Автор сохраняет сериализованное состояние формы (помимо прочего) в localStorage. Затем, когда пользователь попадает на страницу снова, автор проверяет: а каким образом пользователь попал на страницу? Если через модору и сохранение было недавно, то форму нужно восстановить из localStorage. Если как-то иначе, или сохранение старое, то форму восстанавливать не нужно и localStorage надо почистить. Ох не уверен конечно что нам стоит вот это всё себе прикручивать...

Также не мог не заметить такую строчку кода в инициализации:

if (isDollchan()) return;

Нам тоже cделать автоотключение по обнаружению DollChan Extensions?

>>24810
>Нам тоже cделать автоотключение по обнаружению DollChan Extensions?
Нет.

>>24804
>Локально проверять исправления у вас до выходных возможность есть?
Нет.

Ещё в русской версии должно быть «Ответ в нить № 180000», а не решётка.
Значки в «Умночане» и «Вакабе» сделайте белыми.

>>24823
Ок, сделаю.

>>24823
1. На всякий случай, заголовок формы должен выглядеть как-то как пикрелейтед?

2. Еще раз уточню про DollChan Tools. Я посмотрел, и сейчас и у соседнего сайта, и у нас указана полная с ними совместимость. Если мы вдруг станем не совместимыми, то у пользователя будет всё хорошо на соседнем сайте, но как только он перейдет на совместную доску к нам, всё сломается. Мне кажется это плохо с точки зрения удобства и впечатлений пользователя. Сделать авто-отключение, если верить существующей реализации для соседнего сайта - одна строчка. Точно-точно ничего не надо с этим делать?

>>24830
Знак номера в русском языке отбивается (неразрывным) пробелом.

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

>>24831
>Номер отбивается (неразрывным) пробелом.
Ок.

>Почему мы должны делать костыли для поддержки чьего-то костыля?
Только из чувства солидарности с соседями которые так уже у себя сделали.

Ближе к вечеру сегодня ожидайте новый пулреквест.

>>24794
>>24831
>>24833

Цветная, гипертекстовая, каскадно-стилевая, яваскриптовая форма ответа для Flower Bus Engine, версия вторая, исправленная и дополненная.

Основные изменения:

• Цитаты теперь с переносами в конце, и не вызывают "рассинхрон"
• Поправлена ошибка цитирования в браузерах основанных на Chrome
• Если форма открыта, нажатие на номер делает цитату в форму
• Если форма закрыта, нажатие номера переносят в нить, как раньше
• No. работает как раньше, но устранены ранее не обнаруженные конфликты с работой формы
• Синхронизируются теперь все доступные в FBE типы полей форм: текстовые, чекбоксы, селектбоксы, файловые
• Внутри нити синхронизация форм двухсторонняя, как в первой версии
• На доске синхронизация форм односторонняя, из основной в быструю только при закрытой быстрой
• Формы теперь сохраняются в sessionStorage и восстанавливаются при возврате / обновлении страницы после чего данные из sessionStorage сразу убираются
• Если открыта форма быстрого ответа, при возврате / обновлении она переоткроется в старом месте
• Поправлены заголовок и стили значков в соответствии с пожеланиями
• Добавлены :hover стили значков во всех темах

Большинство улучшений были реализованы благодаря открытой реализации >>24808, за что огромное спасибо её автору.

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

Пулреквест уже создан.
Тщательно проверяйте, и как всегда хорошо чистите кэш.

Эх, погорячился я с релиз-кандидатами, надо было бетой называть

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

>>24835
Добавил. Если что, эти изменения легко выщелкнуть из реквеста.

>>24835
Лучше не выдумывать всякое непредсказуемое поведение, которое отличается при использовании разных форм.

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

>>24838
Не знаю, что я там должен написать, но написал.

>>24839
Я имел в виду скорее "напишите если попробуете и не понравится", но если хотите убрать сразу, давайте уберем сразу, а предлагаемое дополнительное поведение вы проверите уже отдельно потом, в рамках отдельного реквеста.

>>24837
>>24839
>>24840
Функционал выщелкнул, реквест обновил.

Создаю я, стало быть новую нить, захожу в неё, а кнопки быстрого ответа у ОП-поста нет. Да и в старых нитях её у ОП-постов нет.

И ещё при попытке написать второе сообщение подряд из любой формы вылазит __DONTTRICK (проходит только после удаления печенек), но я пока не знаю, связано ли это с обновлением скриптов. Проверьте там у себя на всякий случай.

>>24848
>Создаю я, стало быть новую нить, захожу в неё, а кнопки быстрого ответа у ОП-поста нет. Да и в старых нитях её у ОП-постов нет.
Я не добавлял кнопку ответа к ОП-посту внутри нити, так как она выглядит там ну абсолютно бесполезной. Форма ответа-то прямо перед глазами, над оп-постом. Да и зачем заходить в нить, если хочешь ответить на ОП-пост, если это можно сделать прямо с доски. Надо добавлять?

>при попытке написать второе сообщение подряд из любой формы вылазит __DONTTRICK (проходит только после удаления печенек)
Скорее всего у вас стоит неправильный путь к файлам сессий в файле adaptive_config.php, по умолчанию он заглушечный:

define('KU_SESSION', '/path/to/sites/410chan/.htsession');

Также убедитесь что у вашего апача есть права ходить и читать из папки .htsession
Проверьте, и сообщите, в этом ли дело.

>>24851
^^ и писать в эту папку апач должен уметь тоже, а то куда ж он вашу сессию сохранит.

>>24851
>Надо добавлять?
Надо.
Конфиги сервера пока не могу проверить, если будете делать реквест, можете это пока не учитывать.

Методом пытливого выспрашивания удалось выяснить, что по адресу https://bitbucket.org/Therapont/fbe-410/issues/38 предлагается напилить поддержку WebP:

> Поддержка изображений WebP для конечного пользователя не должна отличаться от остальных форматов изображений (в том числе следует обратить внимание на показ картинок в модерке во всех нужных местах, RSS и т. д.).

> Никаких костылей для поддержки устаревших браузерных движков не нужно.

(Конец цитаты.)

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

Есть вѣроятность того, что будут ставить на версию Apache, ещё не знающую, что файлы .webp имѣютъ MIME-тип image/webp. Разъяснилъ.

В скрипте kusaba.js сдѣлалъ расширение .webp извѣстнымъ для разворачивателя картинок, но не для разворачивателя третьего поколения, потому что файлы WebP (как и GIF) могут быть анимированными.

Я замѣтилъ, что анимированные файлы WebP не поддерживаются FFprobe (даже в позавчерашней сборке https://www.gyan.dev/ffmpeg/builds/ffmpeg-git-full.7z от 4 ноября). Я также не могу совершенно быть увѣреннымъ и в их поддержке в GD в PHP. Поэтому запрос на слияние исходного кода, мною по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/40 созданный, содержит только код, рассчитанный на употребление ImageMagick, причём как для считывания ширины и высоты присланного файла в пикселах, так и для создания миниатюр.

По причинам, в нити микроблогозаписей https://twitter.com/FidonetRunes/status/1276169211719663616 изложенным, в моём коде для наращивания чёткости миниатюр примѣняется недокументированный пятый препроцессор. Что же касается числового показателя качества миниатюр, то его значение было выбрано мною экспериментально: качество 85 для статических миниатюр (потому что файлы получаются ужé меньше, чѣмъ JPEG при качестве 80, а видимое качество — всё ещё больше) и качество 93 для анимированных миниатюр (при меньшем качестве раздражающе нарастает «поблёскивание» случайной междукадровой разницы, обнажая границы макроблоков). Впрочем, этот послѣдній нюанс не коснётся 410чана, так как анимирование миниатюр анимаций не включено на 410чане.

Вроде бы ничего больше не нужно; если я что-то пропустил или не догадался о желательном, то тогда прошу указать.

Создание файла в базе данных, как я понимаю, совершается администратором, то есть можно будет, накатив предлагаемые мною правки, зайти в настройки, указать новое расширение «webp», переключатель «Image / Video / Other» оставить в положении «Image».

>>24853
Добавил кнопки к ОП-постам и создал новый пулреквест.

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

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

>>24897
Оно и на соседнем сайте не работает. Это ограничения технологии.

>>24897
>Думается, стоит добавить такой же функционал и для формы быстрого ответа.
К сожалению, вот так просто не выйдет. Как верно указывает >>24898 это ограничение технологии. Суть в том, что запрещено из скриптов выставлять путь к файлу в поле загрузки файла, из соображений безопасности описанных тут: https://stackoverflow.com/a/1696884
Соседний сайт живет с таким же ограничением и тоже не сохраняет файл в быстрой форме.
При синхронизации же форм и мы, и соседний сайт просто берем и копируем готовое поле, в которое до этого пользователь руками что-то добавил, так делать можно. Но сохранять его в таком готовом виде при перезагрузках страницы просто негде, поэтому как его восстанавливать пока тоже не придумали
Пока на ум приходит только костыль - сделать чтобы файловое поле быстрой формы синхронизировалось с основной формой всегда. В этом случае файл в форме быстрого ответа будет тоже "сохраняться" всегда, ведь быстрая форма клонируется из основной.

Сделать такой костыль?

>>24899
Теоретически, еще один вариант для сохранения файлов в поле быстрой формы - перестать генерировать форму скриптом вообще и перенести её в шаблон. Но там такая каша в текущем коде, что страшно становится.

>>24899
Файл можно сохранять в sessionStorage или localStorage, а лучше в IndexedDB. Но при отправке придется добавлять файл из хранилища к FormData и отправлять через js.

>>24902
1. Вы предлагаете прямо байты из файла хранить?
2. Как после возврата показать пользователю поле загрузки с выбранным ранее файлом?

>>24899
Наверное, проще оставить как есть.

>>24904
Хорошо, попробуем найти что-то понадежнее тогда.

А "подкрутку" к нити после успешного постинга вам засылать на пробу, или пока не надо?