Ычан: [d | b / bro / hr / l / m / mu / o / s / tran / tu / tv / vg / x | a / aa / c / fi / jp / rm / tan / to / vn]
[Назад]
410.png - (34.48KB, 500×500)
20450
No. 20450  
После публикации исходников мы можем обсуждать доработку не только ранее общедоступных частей интерфейса, но и движка в целом.

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

Предыдущая нить: >>17371
No. 20452  
Pull request - Access denied.png - (90.59KB, 1227×537)
20452
>>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 будет принят).

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

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

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

(Может и врут, не знаю.)
No. 20455  
>>20454
Выцепил и применил патч сам. Благодарю за содействие.
No. 20456  
ReLIFE - MD.gif - (4.70MB, 1026×577)
20456
>>20455

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

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

Практическим выражением этой мысли служит коммит https://bitbucket.org/Mithgol/fbe-410/commits/d09547dfecb628c34251a81996a2e2c30ece35f2
No. 20458  
>>20456
Принято, но таким образом тип 'audio' не несёт никакой нагрузки, кроме разве смысловой. Может стоит его удалить тогда?
No. 20459  
ReLIFE ED05.png - (2.64MB, 1920×1080)
20459
>>20458

Очень хорошая мысль!
No. 20467  
ReLIFE ED05.png - (2.10MB, 1920×1080)
20467
Некоторое время думал над заданным в реплике >>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чане.

А иначе к чему бы это? — только к этому, понятно же.
No. 20468  
ReLIFE ED05.gif - (4.80MB, 272×153)
20468
Продолжая изложенную автором реплики >>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 мнению) «на инстант-нульче, который, в свою очередь, на кусабе х». И упоминаю.
No. 20469  
Так как вновь наступил понедельник, то надо сказать несколько слов о том, с какими новыми возможностями 410чан вступает в эту неделю, и скажу.

Ни с какими.

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

Ждём дальше.
No. 20485  
>>20469

+1.

Соусовый аудиоответ на вопрос >>/b/134916 прилагаю.
No. 20486  
>>20485
Печаль, поддержка видео это очень весомый апдейт для нашего движка, и чана вообще. Например, можно было бы в /а/ и /ts/ создать тред с шебмками и инструкцией по их созданию средствами ffmpeg, и обмениваться там клипами и опенингами. Чуваки в /cu/ могли бы какие-то элементы готовки на видео записывать и выкладывать, урбанисты в /ci/ - урбанистику. В /dev/ бы можно было демонстрции игровых проектов делать правда у нас активно идет разработка только визуальных новелл, не ясно что там показывать на видео
No. 20487  
>>20486
А на практике этим будут пользоваться полтора человека.
No. 20488  
>>20487
Скажу больше: на деле это превратит Автобус в кладбище репостов смищных видосиков и музыки.
No. 20489  
>>20486 >>20488
Пассажир в те же 5 Mib сможет засунуть значительно больше видео в лучшем качестве, нежели в gif. Это хорошо ведь. Пассажиру не нужно будет перекодирывать видеофайлы в gif, он сможет постить их как есть. Это замечательно же. Посетителям иных досок тоже лучше будет, наверное, обитателям /a/ уж точно.
No. 20490  
>>20488
По этой логике Автобус бы уже давно был кладбищем смешных картинок и музыки (картинки и музыку-то прикладывать движок давно умеет)
No. 20494  
>>20490

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

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

>>20486

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

Не поможет.

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

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

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

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

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

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

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

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

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

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

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

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

Наверное, не многие создают GIFы и, опять же, не многие в них перекодирирывают видеоконтент. Большинство, вероятно, имеют эти GIFы скачанными с чанов или откуда-нибудь ещё. Тоже самое частично верно и для видео: немногие нарезают, скажем, аниме на отрывки самостаятельно, многие постят скачаанное ими откуда-то. Поскольку, скорее всего, мало кто будет перекодирывать скачанные видео в GIF, Чиочан же видео (пока) не поддерживает, это ограничивает возможность постинга контента, который, быть может, хотелось бы запостить некоторой чиочаньке. Поддержка видео эту проблему решит.
No. 20497  
>>20496
>на отрывки самостоятельно
fixed
No. 20498  
>>20494
>только гадательно можно утверждать, обрела бы в этом разделе широкую популярность практика репостов музыкальных файлов, или не обрела бы, или сперва обрела бы, а затем была бы пресечена модерациею.
Ну, в /б/ уже существует тред обмена музыкой, и там обмениваются ссылками на музыку. Была бы возможность прикладывать - её бы просто прикладывали. И думаю за рамки этого оно бы не вышло. И учитывая что это 410й, обычно делятся чем-то интересным.

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

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

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

>>20488
Вообще, тут переживают за контент так, как будто у нас посещаемость макача, и если аудитория что-то может сделать, то она обязательно сделает. А на самом деле у нас практически несуществующая аудитория, большинство которой состоит из постоянных многолетних постеров, не забаненных за все это время модерацией сайта, и не ушедших полностью на более посещаемые ресурсы. Т.е. во-первых можно изначально надеяться на то что описанный сценарий находится вне интересов нашей аудитории потому что если вы хотели смешных картинок и вебемок, зачем вы сидите на 410м, где их почти нет? Во-вторых, как и с любым другим контентом который не нравится модерации, если модерации он не понравится, она за него просто забанит, а контент удалит. Так что даже если сюда каким-то чудом попадет коварный репостер вебемочек данкест мемес, то он скорее всего быстро получит бан, после чего пойдет постить куда-то еще.
No. 20499  
Ещё раз вгляделся (на сей раз в том коммите, который по адресу https://bitbucket.org/Therapont/fbe-410/commits/3355e9e1bb4bc267b6c21d3a6962cbfd993790ef расположен) в те правки, которые должны принести нам возможность употребления WebM.

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

Много думал.

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

Если же это почему-либо не удобно, то нельзя ли хотя бы атрибуту «value» придать значение «misc» вместо «image»?
No. 20502  
>>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?
No. 20503  
>>20502
Мне кажется нет смысла внедрять WebM, если вместе с этим вводить такое устаревшее ограничение на размер файла. Хотя может кому-то бы и так было в радость.

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

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

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

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

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

2) Особенной проблемы бы и не было. В зависимости от используемой базы данных, как оказывается, хранение файла в базе может быть даже эффективнее, чем в файловой системе. Например, для базы SQLite подсчёт https://sqlite.org/fasterthanfs.html показывает тридцатипятипроцентный рост эффективности. (Правда, Кусаба/FBE использует MySQL, а не SQLite, а для MySQL я аналогичных подсчётов не видывал.)
No. 20517  
>>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чана, а остаётся на проверке у администрации.
No. 20520  
Упомянутое в реплике >>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 использует именно алгоритм Флойда и Штейнберга, а не Байера.
No. 20521  
Длящееся со дня вторника по вопросу >>20499 молчание я считаю знáком согласия, так что по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/19 сочинил pull request.
No. 20528  
>>20504
Удваиваю этого джентльмена: >>20514
No. 20529  
1429846893905.jpg - (122.74KB, 535×627)
20529
>>20514>>20528
http://410chan.org/d/
No. 20544  
Наступил понедельник 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» теперь меняют цвѣтъ при наведении (на синий).
No. 20545  
Кроме >>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.
No. 20546  
Впрочем, сравнение миниатюр файлов, приложенных к репликам >>20544 и >>20545 (в первом из которых диѳэрингъ основан на идеях Байера 1973 г., а во втором — на идеях Флойда и Штейнберга 1976 г.), позволяет почти с полною уверенностью утверждать, что эти миниатюры созданы всё ещё тем способом, который используется Кусабою по умолчанию — и, следовательно, упомянутые в реплике >>20545 изменения не были ещё включены на 410чане: либо настройке «$cf['KU_THUMBMETHOD']» ещё не придали значение «'ffmpeg'» в конфигурационном файле, либо даже сам FFmpeg на сёрвере 410чана ещё не ставили (без чего эту настройку в это положение переключать ещё рано и было бы вредно).
No. 20548  
1264526783515.jpg - (681.59KB, 900×1500)
20548
На тесте «ffmpeg» генерировал уменьшенные копии ГИФов целиком анимированными вместо использования начального кадра (хотя в конфиге для них стоит «false»), то есть в таком виде не пригоден для использования.
No. 20550  
>>20548

Пожалуйста, приведите текст результата выполнения на сёрвере команды «ffmpeg» без параметров. Хочу посмотреть на её версию.
No. 20551  
tex_chara_l_567.png - (116.28KB, 1024×1024)
20551
>>20550
Очевидно, что версия из стабильного «Дебиана».
>3.2.12-1~deb9u1
Также очевидно, что она не вырастет в ближайшие пару лет.
No. 20552  
output.gif - (19.22KB, 200×113)
20552
>>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» записано без кавычек?)
No. 20554  
Кажется, я нашёл, в чём ошибка.

Причём она была в самом начале существования репозитория 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)».

О, етить.
No. 20555  
Патч: https://bitbucket.org/Therapont/fbe-410/pull-requests/20
No. 20556  
Пристальное вглядывание в код 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 до публики, занимающейся исправлением той репы.
No. 20558  
>>20556
Передал, спасибо.
Там, кстати, немного иначе сделали.
No. 20559  
>>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'».

И теперь я такъ и сдѣлалъ.
No. 20560  
Leonmichelle_serious.jpg - (113.06KB, 1280×720)
20560
Чем вам mime_content_type() из Fileinfo не угодил, обязательно надо велосипеды городить?
No. 20561  
>>20560

Разве ImageMagick и FFmpeg ориентируются не на расширение файла, а на «магию» анализа контента его? — кажется, всё же на расширение; а раз уж на расширение, то его-то и следует сравнивать с тем или иным.
No. 20564  
К >>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» без всякой проверки, съ полнымъ довѣриемъ к результатам.)
No. 20565  
Файл
удалён
>>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.
No. 20566  
>>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
No. 20567  
По адресу 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
No. 20568  
8b36967c7f437900635ee6adbdcf388b.jpg - (713.43KB, 1680×1050)
20568
>>20567
По всем позициям: не нужно.

А конкретно «Ютуб» в виде видосов тут всегда был и есть, просто мы его не используем.
No. 20573  
bg-transparent.gif - (17.22KB, 150×150)
20573
Посмотрел на создание превьюшек через ffmpeg — теряется прозрачность в gif.
No. 20574  
По-видимому, наблюденіе >>20573 совершенно справѣдливо, и багъ https://trac.ffmpeg.org/ticket/6813 (или другой подобный) является первопричиною его.

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

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

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

Прежде всего: установлено ли на сёрвере у 410чана программное обеспéчение ImageMagick или GraphicsMagick? — и если да, то какой версии? — а если нѣтъ, то нельзя ли установить его?
No. 20576  
>>20575 Оба есть, 6.9.7.4, 3.25 (из стабильного дебиана)
No. 20577  
>>20576

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

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

Может быть, GraphicsMagick 1.3.25?
No. 20578  
>>20577 Да, ошибка при копи-пасте. Версия GM 1.3.25.
No. 20579  
example.7z - (29.20KB)
20579
>>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 я вызываю именно алгоритм Флойда и Штейнберга.
No. 20581  
locomotion.gif - (4.83MB, 334×188)
20581
Наступил понедельник 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 под конец её.)
No. 20583  
Можетъ ли кто-нибудь понятно объяснить мнѣ, какимъ образомъ получилось такъ, что даже измѣненія https://bitbucket.org/Therapont/fbe-410/commits/0f1aa5969812263c8645707004c7cfa31086bac7 въ кодѣ на сёрверѣ не привели къ устраненію ошибки, по адресу http://410chan.org/dev/arch/res/17371.html#18031 обнаруженной?
No. 20585  
KO.png - (30.01KB, 300×340)
20585
Если администрации нужна какая-нибудь помощь по допиливанию исходного кода видеообработчика, то давайте, по крайней мѣрѣ, поговорим об этом поподробнее.
No. 20586  
>>20585
Пока не тестировали этот код, так что и говорить нечего.
No. 20588  
>>20586 Код пока на локалхосте тестируется.
No. 20591  
Patreon.png - (99.56KB, 788×849)
20591
>>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 заходить. Сие не анонимно.
No. 20593  
>>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-

Впрочем, если это всё муторно, можно просто сделать в банке обезличенную карту, и потом пожертвовать с этой карты через интерфейс яндекс денег.
No. 20618  
По работе видосов замечаний пока нет, но на данный момент требуется синхронизировать ветку public-webm с изменениями, принятыми в public.
No. 20619  
C64IhZ9VAAEpVuF.jpg - (455.83KB, 1386×1969)
20619
>>20618
> замечаний пока нет
А, нет, есть. При попытке запостить ogv выдает "Filetype tampering detected"

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

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

>>20619

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

P. S.   А у нас точно есть намерение поддерживать заливку видео OGV, а не одних только WebM и MP4?
No. 20624  
>>20622
>OGV и WEBM как минимум, а также MP4
https://bitbucket.org/Therapont/fbe-410/issues/15/
No. 20625  
そですか。
No. 20626  
Жив Господь!.jpg - (205.85KB, 811×1140)
20626
>>20619

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

Проверяйте.
No. 20628  
yellow vortex.gif - (1.95MB, 450×450)
20628
Кстати, если есть какие-нибудь другие интересные пожелания, порождённые опасением «а не то напостят», то не стесняйтеся как можно ранее высказать и их — например, чтобы и их можно было сразу реализовать на нынешней неделе, если удастся.

Нужно ли проверять, какая 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чане мы и до второй половины ноября не увидим (и это ещё в лучшем случае!), так что предлагаю администрации сразу высказаться о каждой из них.
No. 20629  
>>20628
Не знаю, видел ли ты это, но Якуй не осилил: https://files.catbox.moe/7o4xyh.mp4 https://files.catbox.moe/a96733.mp4 https://files.catbox.moe/j8n6qg.mp4
No. 20631  
>>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 я сообщал уж, что считаю делом браузера готовность открыть видеофайл (или готовность с ошибкою отказаться открывать его), как это и с неподвижными картинками случается.
No. 20636  
Около десяти минут тому назад исходный код из ветви public-webm был слит в ветвь public.

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

Возрадуйтеся!
No. 20638  
Опечатка: посты с webm (и т.п.) без превью в rss. Посты с картинками показывает нормально.
No. 20639  
Прошу применить поправку https://bitbucket.org/Therapont/fbe-410/pull-requests/25/ для коррекции стилей медиапроигрывателей.
No. 20640  
>>20638

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

Нельзя просто приписать букву «s» в конце имени файла (перед точкой и расширением) и переменить название его папки «src» на «thumb» и надеяться, что получится адрес миниатюры. Это и раньше работало только с картинками, а с некартиночными файлами не работало и работать не могло, так я это понимаю.
No. 20641  
>>20639 ok.
No. 20642  
1162238297671.gif - (292.22KB, 800×733)
20642
>>20638>>20640
Но это не значит, что это не может быть починено. Сделал PR.
И прошу прощения за продолжительное отсутствие.
No. 20643  
>>20638
У меня с какого-то обновления вообще всё без превью. Учитывая что читалка ревностно относится к стандартам, проблема таки на автобусе.
No. 20645  
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?
No. 20646  
>>20645
Вы и так можете указывать любой URL, который не внесён в спамфильтр.
Умерьте пыл. Тут имиджборд, а не файлообменник.
No. 20647  
>>20646
Так понял, Мицгол предлагает использовать как файлообменник как раз не Автобус, а Флару, на Автобусе же контент только подгружать с неё.
No. 20649  
Dream with your eyes open.jpg - (1.25MB, 3914×3250)
20649
>>20647

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

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

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

No. 20650  
>>20649
Вот, что думаю: а нельзя ли полностью всю статику в ИПФС перенести, поставив демона на сервере? Это же огромная экономия места получится.
No. 20654  
>>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-сервер к админу под кровать, не полагаясь на одних читателей.)
No. 20655  
>>20654
Идея скорее в недобросовестном использовании предоставляемых Клаудфларой возможностей. А именно того, что они на своих серверах будут кешировать контент, слитый на их гейт. Опять же если я не Мугичкой поперёк прочитал.
То есть можно заливать статику на сервер, скидывать через ИПФС в гейт Флары, держать до какого-то момента, пока контент не закешируется на их серверах, после чего удалять со своего. Вопрос остаётся в доверии Фляре и её надёжности.
В конце концов, поднятие зеркала борды посредством проксирования её через Фляру тоже не очень честно по отношению к последней. Хотя такая практика имела место быть, пока кое-где не появилось хттпс с сертификатом LE.
No. 20656  
>>20655
Ты слишком lawful человек, если задумываешься о честности по отношению к этому крышевателю, подминающему под себя Всемирную паутину.
No. 20657  
>>20656
Если бы был lawful, то вообще не возникло бы идеи. Так я только за эксплуатацию корпораций.
No. 20663  
Mononoke Hime.png - (2.28MB, 1920×1040)
20663
>>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».
No. 20664  
410chan-spoiler.png - (7.12KB, 200×200)
20664
Если изложенное в реплике >>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 через гейт.
No. 20665  
>>20663
Жаль, что нет точных сроков или алгоритма выбора удаляемых из кеша ИПФС Флары, но если предположить самый вероятный из, то, скорее всего, большие файлы будут храниться совсем недолго, а вот небольшие — достаточно. Насколько помню, те же сайты, которые задудосили со стороны хоста, если Флара закешировала, то с месяц-два могла одна версия висеть. Не знаю, как сейчас, но можно выявить экспериментным путём сей алгоритм хранения и удаления, после чего можно написать скрипт, что будет дёргать файлы из кеша в момент протухания на Фляре, ждать, пока снова не закеширует и обратно удалять.
No. 20666  
сотона.png - (101.51KB, 1459×657)
20666
>>20665

А вот это ужé опасно к https://en.wikipedia.org/wiki/Tragedy_of_the_commons приближается.
No. 20667  
>>20666
Вот потому и говорил, что вовсе не lawful. В конце концов, китайцы убивают много более достойные ресурсы альтруистов, желавших сделать великое добро для человечества, терабайтами трафика, а тут считай корпорация с некислой монетизацией. Это как паразитировать на Гугле — если и заметят маленький зуд с их масштабами, то очень нескоро, как было с хостившими на Драйве порнуху годами.
No. 20671  
Dlx-MAsU8AAscWv_jpg:large.jpg - (195.69KB, 1500×1125)
20671
Одновременно со вчерашними и сегодняшними переделками на сервере, Автобус двинул на PHP7.
No. 20675  
session upload progress.gif - (1.64MB, 1920×1200)
20675
>>20671

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

Например, позволит ли она на основе https://secure.php.net/manual/en/session.upload-progress.php растущую полоску процента закачки напиливать, или там между браузером и PHPшным движком поставлено сёрверное кэширование закачиваемого файла, только затем в PHP начинающего поступать?
No. 20676  
DNpTFymUMAIgL8M.jpg - (425.14KB, 2048×906)
20676
>>20675 В минимальной, практически дефолтной, что на какое-то время сломало загрузку больших файлов.
No. 20687  
IPFS 3D ice text 2016-05-09.png - (36.57KB, 512×512)
20687
Сегодня я возвратился к идее об употреблении 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 как чрезмерно длинный и расчленяет его до неупотребимости, как вы и сами можете видеть.

(仕方がない。)
No. 20692  
>>20671

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

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

Второй из этих вариантов не радует, так как не ясно, есть ли смысл сочинять pull requests со значительным шансом на безрадостные merge conflicts.
No. 20710  
1149684946054.png - (6.69KB, 384×384)
20710
>>20692
Теоретически, вполне может быть, что необходимые изменения уже были встроены в FBE до этого момента. На практике, я не проверял.
No. 20716  
>>20692
Чем оно противоречит, если он там ставит старую Кусабу 1.0.4?
No. 20717  
>>20710

>>20716

Ага, теперь вроде чуть понятнее, как это могло получиться.
No. 20746  
1538537851663.png - (10.04KB, 657×136)
20746
Добавьте указание кодировки в html/head, пожалуйста. Как на ычане. HTTP-заголовка недостаточно, потому что сохранение страниц чем-нибудь (сам браузер, куклоскрипт, расширения) приводит к кракозябрам при открытии.
No. 20747  
>>20746

Так как, к нашему счастью, 410чан перешёл к употреблению HTML5, то мы можем использовать и более краткую форму «<meta charset="utf-8">».
No. 20755  
Если автор(ы) реплик >>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чанѣ не была принята, то тогда не пропадать же ей? — никоим образом не пропадать.
No. 20768  
file_icons.png - (52.41KB, 492×496)
20768
>>20755
А как ипфс работает с тором, например?
Вообще, они там сейчас как раз над работай с файлами думают, чтоб были тумбинашки для каждого расширения, да и не только: http://metatorjq65tshfy.onion/meta/res/405.html#4180
No. 20771  
>>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), почему бы и не удовольствоваться тем одним, что промежуточная цель (перекладывание хостинга крупного файла с сервера на публикатора) будет достигнута? — ведь одно это будет ужé очень, очень хорошо.
No. 20772  
>>20771
Вопрос скорее в том, нельзя ли будет как-то слить айпи постера.
Хорошо, передам.
No. 20776  
mission impossible.jpg - (42.35KB, 500×487)
20776
>>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/ и проч.
No. 20783  
.png - (13.72KB, 929×120)
20783
>>20776
>http://ipfs.stadja.net/upload/
Хорошо там, где нас нет.
No. 20784  
>>20776
>сделать запрос в DHT «у кого есть файл?»
Кстати, не подскажет кто-то, какой именно командой это делается?
ipfs dht findprovs <hash>
выдает id пира (или нескольких), а вот дальше по
ipfs dht findpeer <id>
пустота. Это значит можно спрятаться, или я доки читаю не тем местом?
No. 20785  
>>20784
Кое-что выяснил. Информация по собственному id не ищется, зато по соседним пирам, взятым через
ipfs dht query <my_peer_id>
очень даже. Это значит, что я просто сам себя не могу прощупать, или дело в том, что демон заперт в докере без открытия портов в окружающий мир? Но при этом ведь тот же cloudflare как-то подтягивает то, что я добавляю через
ipfs add

В общем, потребен гуру. Я больше по общей архитектуре, чем по отдельным деталям.
No. 20801  
Вчера просматривал старые треду, у звуковых файлов исчезла превьюшка. Собственно, тест, есть ли это и сейчас, или нет.
No. 20802  
1149378691928.png - (5.51KB, 384×384)
20802
>>20801
...а теперь,напомните мне, пожалуйста, я за последний месяц-полтора забыл: это в <a> неправильный аттрибут или с сервера картинка не пришла?

У меня после переезда сервера FBE ещё заново не поставлен, так что сам до ответа я дойду разве завтра.
No. 20804  
>>20802
Открой для себя инструменты разработчика в браузере. Там как раз с <a> все в порядке, а вот в <img> превьюшки ссылка
/dev/thumb/153944823978s.mp3

что очевидно полная хрень, потому что это не картинка. И на сервере такого файла нет. Подстановка .jpg, .jpeg и .png не помогает, так что вероятно превью вообще не существует.
No. 20808  
1150265064136.gif - (8.61KB, 240×240)
20808
>>20804
Инструменты открыл, <a> не раскрыл.

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

И да, >>20692, FBE с варнингами, но работает даже на 7.2.
No. 20809  
Картинка появилась, значит, ошибка устранена. Вот и славно.
No. 20810  
1149377096781.png - (9.31KB, 384×384)
20810
>>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 сделать или и так смогу поправить?
No. 20811  
>>20810 Оно тестируется, вероятно сегодня мастер будет на бою.

Лень было переделывать pr в другой бранч
No. 20812  
>>20810
> Мне PR сделать или и так смогу поправить?
Поправил в public
No. 20813  
00000071.jpg - (98.83KB, 600×338)
20813
Вообще, я хочу напомнить, что реквестоту надо делать в public.
No. 20814  
>>20813
Я последовал Мицголу, но да. Больше не повторится.
No. 20815  
Sword Art Online - unknown items.mp4 - (320.85KB, 1920×1080)
20815
>>20814

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

Я правильно понимаю, что такая отмѣна позволит в RSS видеть миниатюры видеофайлов, а предложенная в реплике >>20810 правка заменяла их значками видеотипов?
No. 20819  
>>20818
Потому что я не умею считать, и должен был таки сделать это через PR. Правиться должна была не ветка video, а финальный else, где сейчас
$items .= '<img src="'.KU_BOARDSPATH.'/'.$board_class->allowed_file_types[$line['filetype']][1].'" /></a><br />';

Очевидно, если править вместо этого ветку video, то это не миниатюры аудио чинятся, а ломаются миниатюры видео.
No. 20820  
>>20819
Ох, я надеюсь в новой версии заполняется строка-шаблон, вместо вот этой невероятной конкатенации.
No. 20821  
>>20820
>в новой версии
В новой версии чего?
No. 20822  
У меня одного превьюшки раскрываются на свой полный размер, а не на размер фрейма?

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

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

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

На всякий случай сообщаю, что превьюшки показываются в собственном своём размере с самого начала. Что же касается видеопроигрывателя, то он может быть меньше размера кадра (фрейма), если кадр в полном размере не поместился бы в видимой области окна браузера. Такое уменьшение видеопроигрывателя порождено было осознанием того, что видеопроигрыватель (в отличие, скажем, от полноразмерного изображения) типичный зритель не пожелает прокручивать вверх и вниз, отдельно рассматривая верхнюю и нижнюю часть его — следовательно, не одна только максимальная ширина, но и максимальная высота видеопроигрывателя должна быть ограничена. Естественным ограничением для неё является высота видимой части страницы за вычетом высоты верхнего меню и ещё некоторого дополнительного пространства (чтобы не принуждать зрителя снайперски прицеливаться при прокрутке, со сверхчеловеческой точностью предугадывая будущее положение верхней кромки видеопроигрывателя, ожидающееся после развёртывания миниатюры первого кадра), размер которого для простоты сейчас также предполагается равным высоте верхнего меню (равной 32 пикселам в настоящее время).
No. 20844  
29875823452345.png - (303.12KB, 1230×473)
20844
Вы что-то сломали, кажется. И вот такое вылезло.
No. 20845  
>>20844
После отправки картинки еще и такое.
No. 20849  
1150264319159.jpg - (13.43KB, 330×300)
20849
>>20845>>20844
Кот-то включил выдачу дебаг-информации. Первое было в FBE ещё до правок, array_push начал давать варнинг на undef начиная с PHP7.0.
No. 20857  
Clipboard01.png - (129.03KB, 1024×768)
20857
>>20826
Я говорю, что старые куркулятуры разворачивают картинку на её полный размер, даже если он больше размера фрейма, в итоге появляется вертикальный скролл.
No. 20858  
>>20857
А неподдерживаемые производителями браузеры никто тут поддерживать и не собирался.
No. 20910  
Привёл rss в гости к валидатору, а там пикрелейтед.
No. 20911  
>>20910
Ты, кажется, подсунул RSS валидатору Atom, а не валидатору RSS.
No. 20912  
1150265220863.gif - (8.15KB, 240×400)
20912
>>20911
Один хрен аналогичный вывод Ычана всё проходит, а на несоответствие стандарта тут жалуются. Если есть более лучший - вперёд и с песней. А я пока этими займусь.
No. 20914  
См. >>/b/138958.
No. 20915  
>>20914
А нельзя webp использовать? Должно быть лучше png.
No. 20916  
>>20915
Нельзя, потому что половина браузеров его не поддерживает.
И даже когда станет поддерживать, надо выждать время, чтобы все старые версии умерли.
No. 20917  
Фонд Мозиллы сподобился начать поддержку WebP в шестьдесят пятой версии браузера Mozilla Firefox.

Теперь дело за Apple.
No. 20925  
не Quantum.png - (2.90KB, 322×121)
20925
Впрочем, так как год назад Фонд Мозиллы начал выпускать новую версию браузера 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/Лиса_и_виноград
No. 20933  
video.webm - (3.28MB, 480×270)
20933
В честь поддержки webm пощу ностальгическое видео о доработке движка 410го чана, из 2009го года.
No. 20934  
>>20933
Ох уж этот злополучный 2009-й, с его $регистрацией и аватарками.

Туда же в тему: https://www.youtube.com/watch?v=f3fLXMNnej8
No. 20954  
По адресу https://www.twitch.tv/videos/341851040 был дан ряд советов.

Скриншот прилагаю.
No. 20956  
1166355043492.png - (13.05KB, 320×400)
20956
>>20954
>придётся перебивать все посты
Вообще, нет. Ссылку на пост может дать только последующий пост (в случае нескольких досок, пост с более поздней датой). Учитывая... семантику подобных переносов, равно как и скорость Автобуса, это максимум 100 постов. Я уж не говорю о том что БД лочиться будет на крайне короткие промежутки времени, так как большая часть работы - это чтение и обработка, ничего "падать" вообще не должно. Это, чёрт подери, Апач, он форкается.
Хотя править тексты постов всё равно придётся из Кусабы, а не пряямо в мускуле. Но ничто не мешает вывод обратно запихнуть в один стейтмент.
No. 20958  
>>20956
Там вообще человек зачем-то решил, что надо вообще все ссылки (в других нитях и досках) на перенесённые сообщения исправлять и парсить вообще всю базу. А это не нужно никому, баг № 5 подразумевает работоспособность внутренних ссылок (рефлинков) в перенесённом треде, чтобы было понятно, кто кому отвечал. То есть скрипт переноса надо просто дополнить автозаменой адреса доски и номера сообщения по регулярному выражению.
No. 20959  
9074835067_78dacc9f9d.jpg - (65.60KB, 500×281)
20959
>>20954
>сайт на полминуты будет падать
Поквантовать обновление — обновляем n постов, потом следующие n постов и так, пока посты не кончатся. Можно обновлять в нескольких потоках одновременно. Для удобства сделать виртуальную машину с единственной командой «(Replace This That)» и очередью задач. Статику не переделывать, она переделается сама при появлении нового поста.
No. 20965  
TherapontSousov - spoilers.webm - (4.88MB, 1280×720)
20965
Фрагмент стрима https://www.twitch.tv/videos/342627998 (по времени — в районе конца первого часа и начала второго часа вещания).

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

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

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

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

Ну а чего ещё вы сделаете без привлечения волшебных гномиков?
No. 20967  
1152879416085.png - (15.61KB, 384×384)
20967
>>20966
>А каким боком тут административный интерфейс?
Делать для каждой доски разные настройки спойлера?
No. 20968  
>>20967
Что ви таки собхалися там настхаивать?
No. 20969  
1151500044028.gif - (10.13KB, 500×500)
20969
>>20968
http://410chan.org/dev/arch/res/17371.html#20366
No. 20970  
>>20969
>«Опционально: возможность задать для разных досок разные заглушки»
Ну и?.. Сущности «доска» добавляется ещё одно свойство “Spoiler_Image” (с фолбеком на дефолтную кахтинку в папке ${Board.Name}/src или где у вас там хесухсы доски хъанятся). Впиливаете в бэк эту функциональность, там видно будет, стоит дальше ковыхяться с фхонтом админки или не нужно оно вообще.
No. 20971  
>>20970
>Впиливаете в бэк эту функциональность, там видно будет, стоит дальше ковыхяться с фхонтом админки или не нужно оно вообще.
Очевидно, что функциональность без удобного воплощения бесполезна, иначе бы и баны проводились через iptables.
Дальнейшую лирику вижу бессмысленной.
No. 21748  
Никто не хочет запилить https://bitbucket.org/Therapont/fbe-410/issues/17/410 уже наконец?
No. 21749  
1149378703766.png - (15.65KB, 384×384)
21749
>>21748
Ок.
> создание специального конфига
В config.php или в админке?
No. 21750  
>>21749
Лучше в админке галочку ставить, конечно.
No. 21779  
>>21750
...в общем, я взглянул на ту монструозность, что получается в SQL-запросах на модификацию опций доски и последние две ночи я прикручиваю вменяемый DBO вместо mysqli. Так как это скорее всего я и не сегодня закончу, и до тестирования этого руки у всех дойдут нескоро, то я лучше сегодня-завтра сделаю версию через конфиг. А через БД как-нибудь через месяц или когда одобрят/отклонят DBO, смотря что медленнее.
No. 21781  
>>21779
Ок, делайте через конфиг.
No. 21798  
2019-04-08_04-32-02.png - (2.25KB, 300×35)
21798
>>21748
Хочу заметить, что меню с досками Ычана нет в /r, тогда как на Ычане ссылка на радио есть.
No. 21816  
Помню, кто-то всё бухтел, что строка «[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]» ни во что не обёрнута, но после публикации исходников воз и ныне там.
No. 21818  
>>21816
Кто-то забил на украшательства и юзерстили, и теперь ему в общем-то все равно.
No. 21826  
Въ ычаноменю нѣтъ /tu.
No. 21827  
>>21826
Потому что это доска Новеря.
No. 21828  
>>21826
Действительно.
Со следующим обновлением будет.
No. 21829  
>>21828
Тогда ещё abe, vo и es.
No. 21860  
Ничего не понимаю, зачем сделали список досок ычана сверху?
No. 21865  
>>21860
>Для улучшения интеграции
No. 21866  
>>21860
Руководство Ычана, очевидно, полагает, что не все бородатые сорокалетние админы, отыгрывающие здесь маленьких девочек, знают о существовании Ычана.
No. 21868  
>>21866
Если пользоваться шапкой для навигации вместо фрейма, то при переходе в тот же дев с ычана обратно в вг так просто не вернуться. С новой шапкой можно.
No. 21869  
>>21868
Ладно, уговорил. Пусть будет.
No. 21900  
Наконец, тикет для «Быстрого ответа» готов.
https://bitbucket.org/Therapont/fbe-410/issues/21/
No. 21953  
WebP support 2019-05-12.png - (57.21KB, 1272×692)
21953
Близится середина мая 2019 года, и в настоящее время по адресу https://caniuse.com/#feat=webp сообщают уж, что поддержка WebP появилася у ≈79% пользователей браузеров во всём мірѣ — и, в частности, у ≈70% в России. (Скриншот прилагаю.)

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

Ввиду этого предлагаю мнение >>20916 пересмотреть: не «выждать время, чтобы все старые версии умерли» (чего много лѣтъ ещё, может быть, пришлось бы дожидаться), а просто-напросто подпереть старые версии посредством https://webpjs.appspot.com/ или другого аналогичного по своему дѣйствію костыля — и тѣмъ невозбранно достигнуть желаемого.
No. 21997  
По поводу 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 и не страдайте фигней.
No. 22001  
>>21997
> Для экономии трафика давно придумали mod_deflate
> tl;dr: включайте сжатие gzip и не страдайте фигней.
Для HTTPS включать сжатие по широко известным причинам нельзя без дополнительных предосторожностей, если на страницах есть элементы с других сайтов. Модуль mod_deflate уже научился отключать сжатие при использовании TLS для ответов на те запросы, у которых сторонний Referer?
No. 22002  
>>22001
Так как в теле статичной страницы не содержится ровно никакой чувствительной инфы, никаких приватных ключей, и ничего секретного, то я не вижу, как тут применим CRIME/BREACH и какие такие печньки им можно своровать.
No. 22004  
>>21997
Это далеко на самая приоритетная задача, которую никто особо не продвигает. Нам в первую очередь нужно отмеченное высоким приоритетом на трекере.
>сравним страницу /b/
Эта там, где картинкопостинг и минимум дискуссий со внутренними ссылками, лол?
No. 22020  
>>22002
> какие такие печньки
Модераторские или администраторские, пароли на удаление постов и тредов, пароль от трипкода Мицгола.
No. 22024  
>>22020
Там слово "печеньки" употреблено условно. Дело в том, что все атаки, эксплуатирующие gzip + TLS, способны только лишь расшифровать тело ответа сервера, но не заголовок ответа (который и так не сжимается), то есть если в HTML не будет написано: "пароль от трипкода Мицгола: fidonet", то и узнать его нельзя. Можно лишь расшифровать тот же текст файла .html, который и так находится в свободном доступе. А так как нет инфы, то нет и уязвимости. Включать сжатие для таких страниц можно смело.
Для страниц админки можно сжатие не включать.
>>22004
В этом тикете обозначена вполне валидная проблема, но неэффективный метод ее решения. Выбор страницы абсолютно не важен, на любой странице будет в десятки раз больше экономия места от удаления пробелов, чем от удаления расширения .html, да и почему только ".html"? Почему не удалять ".jpg", ".png", и прочие расширения из ссылок? Почему бы не сократить названия css-классов "r" вместо "reply", "t" вместо "thrdcntnr", это все уменьшит количество драгоценный байтиков еще больше. Вот только делать это бессмысленно: экономия в 1-10% погоды не сделает, в результате только еще больше изуродуется страница, а эффект от этого заметен не будет. А вот экономия трафика в районе 80% - это другой разговор.
No. 22068  
Не движок, но обсуждение, что делать с забивкой канала у 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чан будет не видно.

No. 22183  
DmW4txiVAAAWFXp.jpg - (91.58KB, 700×1084)
22183
Я ещё тут это продублирую. В субботу мы проверили пулл-реквест № 34 и увидели, что там переключалка стилей утратила вертикальное центрирование относительно навигационного меню и съехала вверх.
Пока это не будет исправлено, мы не будем принимать эти изменения.
(Я не смог сам это починить.)
No. 22207  
>>22183
В общем, отступ у селекта помог.
Впрочем, если есть более изящные решения, можете предлагать.
No. 22209  
>>22207
Это не "помог", это 3.14десу.
No. 22210  
>>22209
В мобилковерсии ещё хуже.
No. 22211  
>>22183
Убери отступ, поменяй на
.adminbar select{
vertical-align:sub
}
No. 22212  
>>22209
>>22210
>что такое кэш
No. 22213  
>>22212
>что такое абсолютно неюзабельный интерфейс, if-modified-since и другие полезные вещи
No. 22214  
Соус, ты шатаешь? Почему Автобус падает?
No. 22216  
>>22213
Понятия не имею, но действительно полезно сначала обновить кэшь (на любом сайте, где вдруг такое вылезет), а только потом идти ругаться с админами. Вряд ли есть смысл прикручивать что-то там ради изменений, делаемых крайне редко.

>>22214
Поисковый бот «Яндекса» забивает соединения. Если так и продолжится, забаним в итоге.
No. 22223  
>>22216
> Если так и продолжится, забаним в итоге
Зачем вообще роботы дозволены? Неужто в 2018 есть надежда на легитимный трафик из поисковиков?
No. 22226  
>>22223
Поисковики могут быть полезны как для поиска старых и не существующих на момент поиска нитей по фразам и словам, так и для поиска конкретных постов, обратиться к которым иначе было бы сложно, поскольку пришлось бы пересматривать многие треды для их нахождения.
Также поисковики архивируют (кэшируют) содержимое страниц: в частности тех, которые потом не оказываются в архиве официальном. Таким образом, поисковики могут быть полезны как способ найти то, чего в официальном архиве нет.
Если банить все поисковики, то, разумеется, таковой способ со временем перестанет существовать, оставив официальный архив единственным и неполным источником информации о прошлом. Помимо этого, в разы усложнится поиск постов и нитей по словам, поскольку делать это придётся почти вручную. Если, конечно, не написать для этого скрипт, чего никто делать не будет.
No. 22227  
>>22226
В кодобазе есть какая-то имплементация поиска уже.
No. 22228  
>>22226
Так как в конечном счёте решать Совусу, то заинтересованные могли бы поднять свою дампалку с любым поиском. Или попросить кого-то ещё её сделать (например, Якуя, у которого уже есть дампалка Иичана).
No. 22229  
>>22068
Ычан, кстати, за последний год добавил этот самый Crawl-delay.
No. 22242  
>>22068
И настройте VirtualHost чтобы всякая лабуда навроде 1337.410chan.org не отдавала ничего.
No. 22243  
>>22242 Чем оно мешает?
No. 22244  
>>22243
Сценарий 1: поисковик сканирует 410чан.орг и обновляет по протухаемости.
2. Поисковик сканирует 410чан.орг и любую другую комбинацию и проверяет по протухаемости каждую.
No. 22274  
Понаходил всякой нежелательной лабуды в поведении скриптов.
https://bitbucket.org/Therapont/fbe-410/issues/30/
https://bitbucket.org/Therapont/fbe-410/issues/29/

>>21997
Заморозил эту задачу, потому что она пока не нужна всё равно.
No. 22306  
Предлагаю отключить функцию "[Первые 100 сообщений] [Последние 50 сообщений]", отключается она через config.php:
$cf['KU_FIRSTLAST'] = false;
Аргументы, почему это стоит сделать:
  • эта функция не востребована, в яндекс.метрике наверно можно посмотреть статистику по посещениям файлов "x-100.html" и "x+50.html", скорее всего она нулевая.
  • на каждый тред генерируется два лишних файла, что в 3 раза увеличивает занимаемое место на диске и на столько же замедляет ответ сервера при постинге.
  • Лишние файлы генерируются для любых тредов, где ответов больше 100. Тред со 101 ответом так же получит дополнительные файлы. При этом ни одному пользователю не придет в голову экономить трафик на 1 посте. Даже на 200 ответах загружать только 100 или 50 из них не рационально, учитывая что сообщения могут состоять из одной строки.
  • Огрызки тредов индексируются поисковиками, в результате генерируется лишний трафик, в выдаче образуются дублирующиеся результаты, при переходе по которым будет видна только часть обсуждения с постами, выдранными из контекста.
  • Огрызки тредов попадают в архив, хотя казалось бы, зачем они там.

No. 22323  
Возможно — баг, возможно — фича, возможно — я что-то недопонимаю. С 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’ов не приемлемо.
No. 22324  
8675849.png - (323.49KB, 1120×698)
22324
>>22306
То есть, единственный аргумент заключается в архивации. И это не проблема данной функции, которая никому не мешает и может быть востребована на мобилках (кто-то упоминал, что пользуется ей именно в таком контексте), а проблема архивации, которую надо переосмысливать в целом. Дополнительный файл место занимает? Ну да. А всякие формы постинга и прочие бесполезные штуки в коде самих страниц место не занимают? И ещё вёрстка едет с каждым обновлением ЦСС.
Надо какой-то мегатикет под это дело сочинять, которым всё равно никто не будет заниматься.
Тут ещё всплыла проблема, что уменьшенные картинки в ответах не архивируются. Но до выходных нет возможности проверить, от движка это или от сервера.

>>22323
Образец конфига основан на 410чановском по самоочевидным причинам.
No. 22325  
>>22324
> То есть, единственный аргумент
Аргументов приведено 5 разных, и архивация на последнем месте по значимости. А пользуется ли этой функцией хоть кто-то на мобилках, должно быть ясно из метрики. Если не пользуется, то нет причин ее держать включенной.
> А всякие формы постинга и прочие бесполезные штуки
Это не бесполезные штуки, а обязательный контент страниц, без которых сайт не будет работать.
No. 22326  
1551734050636.png - (192.00KB, 396×512)
22326
>>22325
>обязательный контент страниц, без которых сайт не будет работать
И что же перестанет работать, если из архивных страниц формы постинга и прочие бесполезные для архива вещи вырезать, наркоман?
No. 22327  
>>22326
Ну при чем тут архив? Эти +50-100 занимают место в массе своей не в архиве, а в обычных тредах. Проблема FirstLast-файлов к архиву имеет мало отношения, просто интересно, чем руководствовался тот, кто писал этот код, когда решил, что из тоже нужно туда сохранять.
No. 22328  
>>22324
Кстати, вы может пароль БД и затёрли, но пароль от спец. трипов, похоже, нет.
No. 22330  
>>22324
>Образец конфига основан на 410чановском по самоочевидным причинам.
А он, в свою очередь, основан на поставлявшемся вместе с Кусабой конфиге, да. Это обстоятельство очевидно из содержимого конфига-образца.

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

Что же до нужности… Это поможет, в частности, и потенциальным новым разработчикам, в случае если они решат поставить у себя FBE, таким же, как и у меня, образом. Да и неужели задача доработки FBE до состояния, при котором его можно легко и безпроблемно развернуть в отрыве от 410чана и не в точности таким же, как на 410чане, образом, сама по себе не интересна?
No. 22332  
1459145399130.png - (51.08KB, 205×238)
22332
>>22330
>Да и неужели задача доработки FBE до состояния, при котором его можно легко и безпроблемно развернуть в отрыве от 410чана и не в точности таким же, как на 410чане, образом, сама по себе не интересна?
Кому интересна, лол? Это движок «410чана», допиливаемый в интересах «410чана». Что вы там собрались делать в отрыве — исключительно ваша личная трагедия.
Нам не хватает свободного времени, чтобы тестировать код, который исправляет действительно проявляющиеся на сайте баги и недоработки, а вы ещё предлагаете заниматься техподдержкой хѣръ знает кого ради хѣръ знает чего.
No. 22335  
>>22332
>ваша личная трагедия
Ох ты ж, какие эпитеты.
Достаточно было прямо ответить да/нет.

>вы там собрались
Поставить FBE, посмотреть, как он работает, понять, что из ticket’ов я могу и буду делать и буду ли. Пока ещё только смотрю-с.
No. 22452  
Никто не хочет заняться https://bitbucket.org/Therapont/fbe-410/issues/25/ ? По идее, там ничего сложного не должно быть.
Сами CSS-файлы можно не ковырять, с этим я сам справлюсь.
И ещё новая задача, тоже связанная с главной: https://bitbucket.org/Therapont/fbe-410/issues/32/
No. 22453  
>>22452
Первый тикет — плохая идея. Наоборот лучше оставить глобальный стиль для служебных страниц отдельным, а объединить оформление текстовых досок и картинкодосок одним условным board.css, возможно, правкой кусабашаблона первых. Все темы вынести только на уровень перекрашивания элементов и сделать единой системой для всех страниц.
Почему: на досках нет элементов со служебных страниц, в свою очередь на служебных страницах нет всех элементов досок, а объединение глобального стиля в свою очередь означает загрузку лишних свойств и утяжеление страничек служебных на много и досок на не очень. Так же с унификацией системы тем отпадает нужда в ориентации на старые костыли с ней связанные.
No. 22454  
>>22453
Плохая идея — это сейчас, когда зоопарк файлов с двумя разными переключалками стилей (одна из которых сломана).
Вы говорите, что там общих элементов нет? Так это следующий этап, лол. Туда точно надо встраивать навигационное меню, чтобы служебные страницы можно было использовать без фрейма (и вообще перестать этот фрейм людям по умолчанию совать).
Какое утяжеление страничек, лол? CSS, которые у всех и так закэшированы, на вырастут пару килобайт (причём в кэши зато не будут лежать упразднённые файлы из тех же пары килобайт)? Да и плевать, лол.

Это очень важная задача, которую я давно жду, чтобы начать дальнейшие изменения.
No. 22460  
>>22454
Имелось в виду… впрочем, ладно. Само собой вынести в global.css всё повторяющееся, а в board.css и pages.css оставить полшишечки уникальных идентификаторов.
Скажи, ты стили-темы унифицировать пока не собираешься?
No. 22462  
1562495138795.jpg - (89.26KB, 613×640)
22462
>>22460
>Скажи, ты стили-темы унифицировать пока не собираешься?
Не собираюсь. Ибо что там унифицировать, если весь каркас и так лежит в img_global.css, а во всяких umnochan.css в основном остались только цвета всякие?
Не хотите работать над существующими задачами? Тогда хватит флудить в треде.
No. 22464  
>>22462
Ну не стукай, не знал, что ты уже по большей части.
Кстати, переключалка стилей во фрейме вообще сломата. Ща потыкаю.
No. 22560  
Для задачи 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/)

А также куча старых задач, на которые всем плевать. Не знаю, зачем я это всё пишу вообще.
No. 22562  
>>22560
Попробуйте стимулировать людей чем-то кроме пораженческих настроений и "нам это не нужно".
No. 22904  
Надпись "Ныне 3156 unique user posts" зело razdrazhaet.
В config.php заменить бы сочетание "unique user posts" на "уникальных столбов". А вообще это число считает количество ip-адресов, с которых отправлялись столбы.
No. 22914  
>>22904
Уникального пользователя столбов.
No. 22930  
2018-06-28-966372.png - (175.62KB, 700×1000)
22930
>>22560
>Фоновая проверка заполнения форм
Кто-нибудь кроме меня думал, как можно такое сделать? Получится два одинаковых кода на разных языках, которые надо как-то синхронизировать. К тому же количество полей для валидации варьируется в зависимости от доски. Плюс, сами правила валидации для каждой доски могут меняться через админку ну по крайней мере в Кусабе так. Т.е. IMO, нужно будет родить небольшой фреймворк с собственным DSL для описания алгоритма валидации.
No. 22932  
>>22930
Сделать это возможно это только лишь так, как сделано в кукле: аяксом отправлять форму и при ошибке показывать попап.
Все остальное может только добавить проблем и багов. Тикет действительно написан так, что остается только чесать голову.
Только нафига оно нужно, если кукла эту проблему решает давно и хорошо.
No. 22956  
>>22930
Зачем, если есть required, maxlength и прочие accept?
No. 22959  
2015-02-25-714031.png - (174.62KB, 350×651)
22959
>>22932
В кукле и у меня тупо AJAX-постинг. Его сделать довольно просто, только это не «Фоновая проверка заполнения форм», а «Фоновая отправка форм» с последующей обработкой ответа сервера.

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

>>22956
Где есть? На бэке нету; в бэк придётся впиливать некий DSL и на его базе генерировать формы в шаблонизаторе.
No. 22963  
>>22959
Пхп сам шаблонизатор.
No. 22990  
>>22959
>только это не «Фоновая проверка заполнения форм», а «Фоновая отправка форм» с последующей обработкой ответа сервера.
Вы сами это придумали, там нигде не сказано, что надо проверять до отправки.
No. 22991  
philosorapthor.png - (228.92KB, 500×500)
22991
>>22990
Мы придумали только то, что написано здесь и в ведре. Т.е. ви таки хотите фоновую проверку, которая выглядит как AJAX-постинг, данные отсылает прямо как AJAX-постинг, результаты обрабатывает как AJAX-постинг, но не AJAX-постинг? А механизм, который по мере заполнения пользователем формы проверяет корректность введённых данных и высвечивает ошибки если не, ви таки не хотите?
No. 23128  
1430546684640.jpg - (183.44KB, 1280×738)
23128
Есть мысль по поводу «мегатикета», призванного решить все проблемы с архивом.
А что если не заморачиваться с починкой движка, а просто написать внешнюю никак от него не зависящую скриптоту на любом языке, которая тупо парист html-файлы в архиве, а взамен выдает свои html, где нет ничего лишнего, стили свои встроенные, так что ничего потом не поломается и вообще. Есстественно, проблема в том, что парсер должен быть достаточно всеядный, чтобы корректно работать со всеми изменениями за последние 10 лет.
Скрипототу можно вручную временами запускать, или же создать в cron'е задачу чтоб периодически сканировала директории с архивом на наличие новых файлов.
И потом никакая доработка движка, которой никто не будет заниматься, не исправит архив за эти 10 лет, файлы так и останутся кривыми.
No. 23210  
spoiler_under_focus.jpg - (340.76KB, 1080×1018)
23210
Пока preview’шка находится в фокусе, её картинка не меняется обратно на preview для spoiler’а. Так и должно быть?
No. 23213  
>>23210
УМВР.
No. 23253  
Uiharu_Kazari_full_502998.jpg - (135.64KB, 1280×720)
23253
>>22991
Я хочу, чтобы вы вместо кривляния тут внимательно читали тикеты, и если вам что-то непонятно, задавали вопросы по тексту, а не гадали по заголовку.
Там сказано, что костыли такое умеют, но вам надо подумать над оптимизацией этого. Потому что костыли, например, работают с HTML-кодом и поэтому дёргают в разы больше ненужного, чтобы показать пользователю простое уведомление из двух слов.

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

>>23210
Под мобилками нет концепции курсора и его наведения, так что, видимо, так и должно быть.
No. 23259  
1487216768447.jpg - (169.75KB, 1280×738)
23259
А я-то дурак думал, что вам нормальные файлы в архиве нужны. А оказывается на это вообще плевать, просто дело принципа. Тыжпрограммисты ведь как известно обладают бесконечным запасом свободного времени, и нырнуть с головой и распутать совершенно любой код им гораздо проще, чем аж написать одну команду в консоли. Поэтому вместо простого и быстрого решения задачи нужно обязательно решать ее самым сложным и долгим способом, а кто не могёт - пусть проваливает, не задерживайте очередь.
Ладно-ладно, прохожу мимо, не смею больше беспокоить.
No. 23268  
Короч, шоб всё было в жсонах, аяксах и конечно же на базе Кусабы.
No. 23269  
1564818556261.png - (599.08KB, 3840×2160)
23269
>>23259
>Тыжпрограммисты ведь как известно обладают бесконечным запасом свободного времени
Зато теоретизировать, не глядя в код, у этих мегапогромистов время есть. И обидки кидать, если их идею отклонили, будто бы им кто-то что-то должен, тоже время есть. На всё время есть, кроме написания кода, ага. А, ну и на аргументы, конечно, ведь вместо них сразу идут обидки.
Ещё раз:
>доработка движка, которой никто не будет заниматься
Потому что вы ск0зали?
Никто вчера прикрутил спойлеры? Никто прикрутил видосы? Никто исправил кучу багов?
Нет, это не никто, это всё вполне конкретные люди. Да, у нас с ними бывают разногласия, но мы им благодарны за их вклад. Вы не хотите ковырять этот движок? Это ваша проблема и ваши обидки на злого меня никак этого не изменят.
No. 23271  
15cc3d5456c4026f3.png - (202.67KB, 947×616)
23271
>>23253
Вам уже два человека говорят, что не понимают, чего вы хотите.

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

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

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

>>23269
>Зато теоретизировать, не глядя в код, у этих мегапогромистов время есть...
Если вы такие все из себя чёткие, конкретные и самодостаточные, и лучше других знаете, что, как и когда делать, то смысла выходить из привата в паблик нет. Потому что будут крокодилить, будут спрашивать об одном и том же, будут не понимать и требовать разжевывания тех вещей, которые вам ясны аки день Бажий, будут фантазировать, как бы они это сделали на своём стэке, и как это вообще можно сделать, будут шутить про отсталость и прочее «говно мамонта», предлагать переписать на Node.js или другой стэк, интересный крокодилам, будут обижаться на отказы. Вот зачем, чтобы впоследствии публично же возмущаться, что вот мол ходють тут всякие, тереотизируют всякое, спорють о чем-то своем, а к станку хозяйскому вставать не хотять; кармодрочерство на основе количества коммитов устраивать?
No. 23274  
7200283.jpg - (276.46KB, 500×752)
23274
>>23271
Ну, я в третий раз могу вас спросить: а нельзя ли оптимизировать ответ сервера после отправки и проверки этих данных, чтобы эти заглушки-уведомления генерировались и выдавались пользователю как-то более изящно, чем просто ныне существующие HTML-страницы со всем лишним мусором, обёрнутые в костыль, чтобы этот мусор спрятать?
Как мне ещё спрашивать, чтобы вы, наконец, попытались это прочитать и внятно ответить?
No. 23275  
>>23269
Конечно, кроме платинового ответа я ничего другого не ожидал.
> Потому что вы ск0зали?
Потому что вы ск0зали. Не далее чем в >>22324 посту. И я склонен с этим согласиться, та задача, в представленном виде, не выглядит выполнимой.
> Зато теоретизировать, не глядя в код
Откуда такие выводы? Тот, кто не видел код Кусабы наоборот считал бы, что все это легко допиливается. Тот же, кто его хоть раз видел, при первом упоминании о нем хватается за голову.
> На всё время есть, кроме написания кода
На написание кода время есть. Но на проделывание в десятки раз большей работы, чтобы добиться того же результата, времени и желания не будет ни у кого.
Вот AJAX-постинг. Здравый казалось бы реквест, полезная фича. Но вам нужен не просто AJAX-постинг, вам нужно чтоб ответом был не простой HTML, который можно распарсить, а JSON с кодом ошибки или еще что, чтоб не было "как в костылях", и таким образом одним росчерком пера задача на пару часов, затрагивающая только фронтенд превращается в задачу на пару недель, в которой надо перелопатить половину бекэнда. По сути, нужно поверх существующего постинга пилить API, да еще сохраняя совместимость с легаси.
Спорить о целесообразности такого решения учитывая дополнительные трудозатраты (значительные) и эффект ими достигаемый (никакой) бесполезно: "Ваши аргументы - не аргументы", "Кроме ваших аргументов у вас нет аргументов".
No. 23276  
8757161.jpg - (3.81MB, 2893×4089)
23276
>>23275
>Конечно, кроме платинового ответа я ничего другого не ожидал.
А вы большего не заслуживаете, увы. Вы не хотите разбираться в существующем коде, вы не хотите задачи на две недели, а хотите на два часа, вам не нравятся используемые технологии, вам не нравлюсь лично я и т.д. и т.п. Так хорошо же. Это ваш выбор, ваши интересы, ваше свободное время. Но нахѣръ тогда тут писать простыни о том, как вам не подходит этот проект, лол?
Нытьё о том, что эта сложна, аргументом не является.
No. 23374  
12345685.png - (583.46KB, 1154×585)
23374
А вообще, для всех мегакодеров, которые не хотят писать код, у меня тоже найдётся задание на чистом ӁС+ХТМЛ. Правда, для другого супермаркетовского сайта.
No. 23472  
Вообще, мне кажется, до отправки можно было бы проверять сам факт заполнения, чтобы нельзя было послать пустое сообщение или ОП-пост без картинки.
No. 23507  
1362318236734.gif - (421.78KB, 200×300)
23507
Новые тикеты:
  • 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/ (Быстрый ответ) уточнил параметры задачи в комментариях. Возможно, совать кнопки к сообщениям прямо в шаблон, а не скриптом, как на «Ычане» — не лучшая идея, ибо в перспективе можно будет приделать настройки (отключить быстрый [убрать значок], совместить традиционный и быстрый ответы [со значком], оставить только БО [без значка/со значком]).
No. 23508  
>>23507
>Сделать, как на «Ычане» недавно сделали
Опечатка.
No. 23602  
Ой, а я что-то забыла...

>>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 для одной бизнес-логики, и если никто о таком кейсе на этапе проектирования не думал, придётся переделывать очень многое.
No. 23632  
>>23374

реквестуем
No. 23633  
1338572811228.jpg - (70.26KB, 603×720)
23633
>>23602
В общем, реалистично было бы брать в разработку именно вариант со скриптами, которые дёргают ХТМЛ как есть, видимо.
No. 23641  
>>23633
Насколько я помню PHP, выходит что так.

З.Ы.: Ты обсуждения здесь вообще читаешь? Например, отсюда >>23614 и выше.
No. 23753  
numeration.png - (93.45KB, 980×370)
23753
Всё хотел сообщить. На страницах с частичным отображением содержимого нити нумерация не соответствует порядку постов в нити: она не учитывает неотображаемые посты. То есть, нумерация не соответствует порядку постов в нити, а вместо этого соответствует лишь их расположению на странице.
No. 23782  
12345684.png - (385.72KB, 1066×592)
23782
>>23753
При текущей реализации это не починить.

>>23602
>штатный запильщик
Отличная шутка.
No. 23784  
counter_fix_prototype.jpg - (145.58KB, 1234×693)
23784
>>23753
>>23782
Технически это возможно, если первому элементу
>.reply span.reflink
Добавить класс reflnik-first, и затем задать для него такое правило:

span.reflink-first::after {
    counter-increment: num+197 !important;
}

Вместо 197, конечно же, надо подставить количество пропущенных постов + 1 (оп-пост). Результат можно увидеть на пикрелейтед. Вопрос только в том, где и как этот кусок стиля создать и поцепить на элемент. И второй вопрос, почему это всё вообще важно?
No. 23813  
С изначальным автором кто-нибудь смог выйти на связь за эти два с половиной года? Или он реально... умер?
No. 23818  
>>23813
>С изначальным автором
Автором чего?
No. 23842  
>>23818
Промах тредом.
No. 23873  
После отправки поста меня редиректит из треда на уровень вверх - на доску. Судя по тому, что никто об этом не пишет нигде, то я подозреваю, что так задумано.
Но неудобно же.
No. 23878  
>>23873
Используй noko
No. 23927  
Ну щта, никто так и не выучил «Ӂаваскрипт», чтобы запилить «быстрый ответ»?
No. 23928  
>>23927
>>23927
Если отказаться от пункта
> Существующая версия «Быстрого ответа» упраздняется
А так же
> пользователь может потянуть за заголовок, чтобы открепить её и двигать по экрану
И просто сохраняя текущую реализацию вместо скролла наверх перекидывать форму под пост, то задача будет казаться более выполнимой.
Если такой вариант не устраивает, то возможно придется ждать еще три года.
No. 23929  
>>23928
Ок, подождём. Нам нужен нормальный «быстрый ответ» как у всех, а не фигня какая-то.
No. 24001  
>В Firefox 75 будет добавлена возможность отложенной загрузки изображений
(https://www.linux.org.ru/news/mozilla/15529229)
В хромоте уже есть, как я понимаю.
Как вы думаете, оно нам надо?
No. 24003  
>>24001
При медленном и нестабильном интернете просматривать нити будет не очень удобно. Нельзя будет подождать пару минут, пока страница сайта загрузится полностью и тогда уже её читать. Да и при несколько более быстром интернете всё равно, подозреваю, будет виден процесс подзагрузки изображений thumbnail’ов, что по-моему не очень красиво. Я предпочитаю читать цельный статичный документ без прыгающих туда-сюда текстов, стилей и ленивых дозагрузок. Как посетитель, я против.
No. 24004  
PS К тому же, в метро, если делать ленивую загрузку, треды не почитаешь: в тот краткий промежуток, когда поезд будет проезжать мимо станции и можно будет поймать связь, страница треда просто не загрузится полностью с миниатюрами приложенных к постам картинок. А в туннелях нет связи. Соответственно, любое предварительное открытие нитей, чтобы потом в офлайне их читать будет также невозможным. Таким образом, использование сайта в условиях нестабильной связи будет затруднительно.
No. 24018  
schnelle Antwort.png - (103.02KB, 1005×707)
24018
>>23929
Это выглядит вот так?
No. 24019  
>>24018
Как это должно выглядеть, можно посмотреть на «Ычане».
No. 24020  
>>24019
Но на Ычане версия из >>23928
No. 24021  
>>24020
На «Ычане» не было предыдущей версии «быстрого ответа», которую надо отломать. У нас есть. Её надо заменить на новую.
На «Ычане» верхняя форма никуда не перекидывается, её можно использовать. Но под сообщением появляется форма «быстрого ответа».
Да, на «Ычане» нельзя откреплять и двигать форму по экрану. Но у нас, в отличие от, эта функция уже есть в скриптах для формы «избранных нитей». Какая проблема её присобачить к форме «быстрого ответа»?
На >>24018 какой-то кривой вырвиглаз просто. Так оно выглядеть не должно в любом случае. На «Ычане» оно выглядит именно так, как должно выглядеть здесь.
No. 24031  
>>23928
>И просто сохраняя текущую реализацию вместо скролла наверх перекидывать форму под пост, то задача будет казаться более выполнимой.
Можно выложить эту версию?
No. 24245  
Хочется, присоединяя свой голос к просьбе >>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) году, несмотря на всѣ короновирусныя трудности.

⬇️ ⬇️ ⬇️ ⬇️
No. 24246  
А вот 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 джаваскриптового костыля, полагаясь на то одно, что желающие воспользоваться им сумѣютъ подключить его себѣ сами въ качествѣ юзерскриптового.)
No. 24252  
noWebP.webm - (727.86KB, 600×600)
24252
На двадцать шестой минуте чифира >>/b/152677 прозвучал отказ от реализации поддержки WebP (цитату прилагаю), и отказ этот заключается в повторении смысла реплики >>20916 с таким видом, как будто ни отклика >>21953 не поступало, ни костыля https://webpjs.appspot.com/ не существует на свѣтѣ.

Ну 仕方がない тогда.
No. 24298  
Что вы сделали с фотоном? Почему теперь шрифты не меняются?
No. 24309  
>>24298
Размер и расположение элементов, шрифты и прочие вещи в темах оформления приводятся к единому виду.
Шрифты себе сами ставьте, какие хотите.
No. 24316  
>>24309
Во-первых, зачем это делается? А во-вторых, ну этот фотон уже неторт получается. Шрифты ставить сложно. Не то чтобы фанат этой темы, но приятно серое нейтральное оформление.
No. 24463  
screenshot.png - (70.01KB, 979×641)
24463
>>24003

>>24004

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

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

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

Ну пришёл.
No. 24557  
screenshot.png - (58.44KB, 1041×273)
24557
По адресу https://developer.apple.com/documentation/safari-release-notes/safari-14-beta-release-notes#Media компания Apple сообщает, что поддержка формата WebP добавлена.

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

Как я говорил, кого нетерплячка бьёт, могут пойти и разгрести высокоприоритетные задачи, чтобы мы могли позволить потратить время на их хотелки.
No. 24570  
>>24569
То есть, пока не запилят новый Быстрый Ответ, можно не ждать? Ой-вей.
No. 24613  
410_quick_reply_proto_demo.mp4 - (4.65MB, 1280×698)
24613
Это конечно та самая ситуация когда 20% усилий дало 80% результата, и потом надо будет долго ковыряться в мелочах, но хотел бы узнать ваше мнение.

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

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

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

Поведение встраиванием сделать проще, чем плавающее, но над реализацией переключения режимов надо подумать. Я так понимаю, что если форму открепили то она уже должна оставаться открепленной, пока не закрепят обратно?
No. 24634  
83113404_p0.jpg - (124.20KB, 500×500)
24634
>>24626
>ок ли когда форма на странице всегда одна и просто откусывается из заголовка и доставляется куда надо для ответа силами jQuery
Нет, скрытие формы — отдельная функция, которая с быстрым ответом никак не связана.
No. 24635  
>>24634
А сейчас это как раз никакое не скрытие, потому и спрашиваю. В представленном видео форма физически откусывается из HTML в одном месте и подставляется в HTML в другом месте, указанном пользователем при клике на быстрый ответ. Так было проще всего сделать.
No. 24676  
410_quick_reply_proto_2_demo.mp4 - (4.69MB, 1280×698)
24676
>>24613
>>24619
>>24634

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

На видрелейтед можно увидеть следующую реализацию:
  • По-умолчанию быстрый ответ встраивается под пост, а-ля ичан
  • В любой момент можно потянуть форму за заголовок, и тогда она открепится, форму в таком режиме можно перемещать свободно, она будет висеть над контнетом
  • В открепленном режиме теперь работает цветочек, по очевидной причине
  • Если открепленную форму не закрывать, она так и продолжит работать в этом режиме, как и требуется
  • Если форму закрыть и открыть снова, она переключится обратно в режим "а-ля ичан"
  • Пока что всё работает вокруг принципа старого принципа "одна форма с доставкой по требованию"
Пишу этот ответ прямо из нового прототипа формы, удобно, что сказать
No. 24677  
re.png - (1.06KB, 150×46)
24677
Нельзя ли сделать редирект в архив для ссылок на старые посты?
No. 24678  
>>24677
Для этого скорее всего понадобится какая-то индексация архива, т.к. сам архив это по сути статичный HTML файлик, открепленный от движка, и функция которая достает вам пост по ссылке из базы оттуда ничего не достанет.
No. 24686  
По возможности, хотелось бы всё же узнать мнение администрации по поводу прототипа быстрого ответа №2, показанного в >>24676 мне хотелось бы знать, надо ли вносить еще какие-то изменения, или пора приступать к оформлению кода в пулл реквест.
No. 24688  
>>24686
Я вижу, что >>24634 автором успешно проигнорировано. Цветочек тоже добавлять не нужно, что нетрудно заметить на картинке в репозитории.
Закрепление/открепление сделано неинтуитивно (и неудобно), поэтому выше и предлагался вариант через отдельную кнопку, что автором также проигнорировано.
Почему автор изобретает велосипеды вместо общепринятых реализаций, мне неясно.
No. 24691  
>>24688
Хорошо, пойду готовить следующую итерацию.
С цветочком забавно вышло, я думал его просто не учли на макете.

>Почему автор изобретает велосипеды вместо общепринятых реализаций, мне неясно.
Не ознакомлен с общепринятыми реализациями, и не знаю где их искать. Я конечно вижу ичановскую реализацию, но никогда не подумал бы что она какая-то общепринятая. На первый взгляд, все имиджборды решают этот вопрос по-своему.
No. 24695  
410_quick_reply_proto_3_demo.mp4 - (4.35MB, 1280×698)
24695
>>24676
>>24688

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

Основные изменения:
  • Теперь на странице одновременно существуют две формы, обычная и быстрого ответа, с синхронизацией между ними
  • Форму быстрого ответа можно свободно откреплять и закреплять, тыкая в иконку "открепить" простая текстовая ссылка "открепить" выглядела в заголовке очень топорно, если нужно как-то иначе эту кнопку сделать - нарисуйте как, и я сделаю, при закреплении ранее открепленной формы страница прокручивается обратно к последнему выбранному ответу. При закрытии же формы никакой прокрутки не происходит.
Требуется мнение администрации, надо ли еще вносить какие-то изменения?
No. 24697  
>>24695
Было бы неплохо, если бы была оставлена как кнопка открепления, так и возможность, потянув за заголовок формы быстрого ответа, открепить форму, сразу перемещая её куда надо. Теоретически, тянуть за большой заголовок может оказаться даже удобнее, чем тыкать в маленькую кнопку, но это не точно.
мимо
No. 24698  
>>24697
Никаких препятствий для того чтобы иметь такой двойной функционал нет. Если администрация не возражает, то так и сделаю.
No. 24701  
>>24695
Активированный значок закрепления лучше с подложкой делать, как у нитей.
На соседнем сайте оно при возвращении назад в браузере умеет текст сохранять. У вас как?

>>24698
Можно, наверное.
No. 24702  
quick_reply_post_badge_fixed.png - (19.80KB, 522×286)
24702
>>24701
>Активированный значок закрепления лучше с подложкой делать, как у нитей.
Вот так как на пикрелейтед, или как-то поменять цвета?

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

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

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

Если других замечаний нет, начну оформлять код для пулреквеста.
No. 24706  
>>24704
>Быстрый ответ должен быть доступен изнутри самой нити? На соседнем сайте доступен.
Самоочевидно, что да.
>Форму быстрого ответа нужно вносить в шаблон, или она тоже должна добавляться скриптом, как и кнопки?
Да вроде смысла нет это в шаблон совать, если оно работает полностью на скриптах.
No. 24707  
>>24706
>Да вроде смысла нет это в шаблон совать, если оно работает полностью на скриптах.
Хорошо, пока оставлю так, а если что переделаем под шаблон. Буду тогда оформлять код, это скорее всего будет не быстро, но я везде напишу, как пулреквест будет готов.
No. 24710  
А есть ли где-то исчерпывающий анализ фич имиджборд?
No. 24712  
>>24710
Есть относительно исчерпывающая спискота разве.
No. 24794  
quick_reply_pop_art.png - (150.78KB, 1109×809)
24794
>>24695
>>24706

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

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

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

Пулреквест уже создан.
Форма в разных оформлениях представлена на пикрелейтед.
No. 24795  
>>24794
А почему на английском?
No. 24796  
>>24795
А, просто язык зависит от выбранной локали.
No. 24797  
>>24794
Очень сыро.
Во-первых, при вставке номеров должны быть переносы строки, иначе при ответе на несколько сообщений сразу получается каша. Ведь так сложно было посмотреть, как это сделано на любом сайте с быстрым ответом.
Во-вторых, текст из быстрого ответа должен дублироваться в форме ответа внутри нити, но нет никакого смысла совать его в форму создания треда при ответах с доски. Опять же, на соседнем сайте так сделано.
В-третьих, вот я открыл быстрый ответ, что-то там пишу, потом жму на номер другого сообщения. И меня либо кидает в нить, если я с доски отвечаю, либо кидает в верхнюю форму, если я уже в нити (и при вставке туда номера происходит рассинхрон двух форм, кстати). Надо ли мне опять упоминать соседний сайт?
No. 24799  
>>24797
>при вставке номеров должны быть переносы строки
Не должны, чтобы делать мультиссылки.
No. 24800  
>>24797
Всё это мелкие дефекты на самом деле. Собственно, чтобы их выявлять и устранять мы тут и рассматриваем всё.

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

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

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

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

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

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

Пока исправляю остальное.
No. 24806  
>>24801
>>24804

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

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

Также не мог не заметить такую строчку кода в инициализации:
if (isDollchan()) return;

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

>>24804
>Локально проверять исправления у вас до выходных возможность есть?
Нет.
No. 24823  
Ещё в русской версии должно быть «Ответ в нить № 180000», а не решётка.
Значки в «Умночане» и «Вакабе» сделайте белыми.
No. 24825  
>>24823
Ок, сделаю.
No. 24830  
white_badges_test.png - (29.89KB, 521×169)
24830
>>24823
1. На всякий случай, заголовок формы должен выглядеть как-то как пикрелейтед?

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

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

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

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

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

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

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

Эх, погорячился я с релиз-кандидатами, надо было бетой называть
No. 24835  
Задумался, что было бы очень удобно если бы после успешного постинга с быстрой формы браузер уже бы был прискроллен к хвосту соответствующей нити. Если возражений нет, то добавлю это улучшение в пулреквест.
No. 24836  
>>24835
Добавил. Если что, эти изменения легко выщелкнуть из реквеста.
No. 24837  
12345691.png - (335.71KB, 1152×632)
24837
>>24835
Лучше не выдумывать всякое непредсказуемое поведение, которое отличается при использовании разных форм.
No. 24838  
Вы напишите в пулреквесте тогда, и я выщелкну эту функцию и обновлю реквест.
No. 24839  
>>24838
Не знаю, что я там должен написать, но написал.
No. 24840  
>>24839
Я имел в виду скорее "напишите если попробуете и не понравится", но если хотите убрать сразу, давайте уберем сразу, а предлагаемое дополнительное поведение вы проверите уже отдельно потом, в рамках отдельного реквеста.
No. 24841  
>>24837
>>24839
>>24840
Функционал выщелкнул, реквест обновил.
No. 24848  
Создаю я, стало быть новую нить, захожу в неё, а кнопки быстрого ответа у ОП-поста нет. Да и в старых нитях её у ОП-постов нет.

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

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

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

Также убедитесь что у вашего апача есть права ходить и читать из папки .htsession
Проверьте, и сообщите, в этом ли дело.
No. 24852  
>>24851
^^ и писать в эту папку апач должен уметь тоже, а то куда ж он вашу сессию сохранит.
No. 24853  
>>24851
>Надо добавлять?
Надо.
Конфиги сервера пока не могу проверить, если будете делать реквест, можете это пока не учитывать.
No. 24856  
Методом пытливого выспрашивания удалось выяснить, что по адресу 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».
No. 24857  
bus.png - (261.31KB, 328×316)
24857
>>24853
Добавил кнопки к ОП-постам и создал новый пулреквест.

>Если будете делать реквест, можете это пока не учитывать.
Постинг подряд у меня работает без всяких проблем (с корректной конфигурацией), так что скорее всего дело именно в ней.
No. 24897  
demo.mp4 - (778.40KB, 986×700)
24897
В форме быстрого ответа при возврате назад не сохраняется приложенный к посту файл. В форме обычного ответа это сохранение работает. Думается, стоит добавить такой же функционал и для формы быстрого ответа.
No. 24898  
>>24897
Оно и на соседнем сайте не работает. Это ограничения технологии.
No. 24899  
bus_2.jpg - (62.09KB, 640×419)
24899
>>24897
>Думается, стоит добавить такой же функционал и для формы быстрого ответа.
К сожалению, вот так просто не выйдет. Как верно указывает >>24898 это ограничение технологии. Суть в том, что запрещено из скриптов выставлять путь к файлу в поле загрузки файла, из соображений безопасности описанных тут: https://stackoverflow.com/a/1696884
Соседний сайт живет с таким же ограничением и тоже не сохраняет файл в быстрой форме.
При синхронизации же форм и мы, и соседний сайт просто берем и копируем готовое поле, в которое до этого пользователь руками что-то добавил, так делать можно. Но сохранять его в таком готовом виде при перезагрузках страницы просто негде, поэтому как его восстанавливать пока тоже не придумали
Пока на ум приходит только костыль - сделать чтобы файловое поле быстрой формы синхронизировалось с основной формой всегда. В этом случае файл в форме быстрого ответа будет тоже "сохраняться" всегда, ведь быстрая форма клонируется из основной.

Сделать такой костыль?
No. 24900  
>>24899
Теоретически, еще один вариант для сохранения файлов в поле быстрой формы - перестать генерировать форму скриптом вообще и перенести её в шаблон. Но там такая каша в текущем коде, что страшно становится.
No. 24902  
>>24899
Файл можно сохранять в sessionStorage или localStorage, а лучше в IndexedDB. Но при отправке придется добавлять файл из хранилища к FormData и отправлять через js.
No. 24903  
>>24902
1. Вы предлагаете прямо байты из файла хранить?
2. Как после возврата показать пользователю поле загрузки с выбранным ранее файлом?
No. 24904  
>>24899
Наверное, проще оставить как есть.
No. 24905  
>>24904
Хорошо, попробуем найти что-то понадежнее тогда.

А "подкрутку" к нити после успешного постинга вам засылать на пробу, или пока не надо?
No. 24906  
>>24903
>1. Вы предлагаете прямо байты из файла хранить?
Да
>2. Как после возврата показать пользователю поле загрузки с выбранным ранее файлом?

К сожалению так как поле файла нельзя заполнить с помощью js, то придется пилить костыли (виджет который будет имитировать поведение поля для выбора файла) что бы показать пользователю что файл прикреплен.
No. 24907  
>>24906
Хммм... надо будет попробовать набросать. Это всё может оказаться как и "не очень сложно," так и "задолбаешься баги ловить"
No. 24911  
>>24905
Подобное поведение должно определяться настройками. А у меня сейчас нет времени заниматься придумыванием ТЗ под это дело (и тогда придётся большинство скриптов под настройки переделывать к тому же).
No. 24913  
>>24911
Хорошо, оставим на потом. Наверное 21ю можно тогда в Resolved перемещать?

Я пока посмотрю что можно быстро сделать из приоритетного, пока в кандидатах упрощение строки с именем файла.
No. 24925  
coaster226.jpg - (53.14KB, 640×496)
24925
>>24913
Реализовал упрощенный формат строки и создал пулреквест.

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

Для того чтобы увидеть изменения потребуется регенерация доски.
No. 24926  
>>24856
Используемая в системе версия «ImageMagick» 6.9.10-23 не поддерживает анимированные вебп.
Так что, видимо, придётся пока без них.
No. 24928  
>>24926

«Придётся пока без них» — без анимированных WebP или вообще без WebP? В этом важная разница.
No. 24929  
merge_threads.png - (46.70KB, 714×566)
24929
>>24925
Как-то негусто вышло с прошлым улучшением, поэтому набросал еще объединение нитей, пока было время.

Выглядит это примерно как пикрелейтед.

Что уже есть:
  • Валидация ввода
  • Валидация нитей
  • Сообщения об ошибках
  • Логгирование
  • Локализация (ru)
  • Автоматическая регенерация доски
Дополнительных изменений постов, кроме смены родителя сейчас не производится.
Это самая базовая реализация, сам я никогда не угадаю что там надо и как в деталях, лучше вы попробуете и мне скажете.

Тем не менее, какая-то возможность объединять нити теперь есть.
Пулреквест уже создан.
No. 24930  
>>24929
>Это самая базовая реализация, сам я никогда не угадаю что там надо и как в деталях, лучше вы попробуете и мне скажете.
На «Ычане» при объединении исправляются адреса >>ссылок в перенесённых сообщениях.
И вообще там можно отдельные ответы между нитями перекидывать (хотя это можно оформить в виде отдельной функции).
No. 24931  
Carnival Phantasm ED.webp - (4.86MB, 14400×1080)
24931
>>24928

Кажется, неанимированные WebP работают.

Очень хорошо!
No. 24932  
>>24930
>На «Ычане» при объединении исправляются адреса >>ссылок в перенесённых сообщениях.
Сделал исправление адресов ссылок, а также параметров предпросмотра, и обновил реквест.
Постарался сделать так чтобы исправлялись только сами ссылки, а не случайно совпадающий с ними текст сообщения.

>И вообще там можно отдельные ответы между нитями перекидывать
Увидеть бы как это выглядит, чтобы понять насколько сложно будет повторить.
Если очень продвинуто, то проще как отдельную функцию.
В самом минимальном варианте я могу просто не проверять, что в From поле указанна именно нить, и назвать его как-нибудь вроде From thread (post)
No. 24933  
>>24931
А вот разворот WebP по клику, кажется, не работает и всегда открывает картинку в новом окне.

Наверное не очень хорошо.
No. 24934  
Choyoyu - minna in ED.webp - (1.36MB, 1920×7406)
24934
>>24933

У меня работает. (Рекомендую обновить страницу с нажатым шифтом для очищения кэша.)

Провѣряю работу WebP высотою 7406 пикселов.
No. 24935  
>>24934
И правда, работает. Ох уж этот кэш.
No. 24940  
>>24932
Вы модерку Вакабы видели? Я вангую, там просто чекбоксы и кнопка в общем списке как на экране.

Наверное проще всего было бы в мод-режиме добавить ещё один чекбокс к постам/кнопку, но это править то, как собирается пост. И не факт что удобно администрации работать напрямую с борды, а не из инструментария.
No. 24941  
>>24925
О, вижу обновленная ссылка на файл уже добралась до /b/. Отлично.
No. 24942  
410_mobile_font_too_large.png - (22.13KB, 411×261)
24942
>>24941
А вот уменьшить шрифт для ссылки в CSS для мобилок, кажется, забыли.
No. 24943  
>>24942
Потому что это и не нужно.
No. 24945  
screenshot.webp - (82.53KB, 949×1076)
24945
Обратите внимание: IQDB по 410чановским WebP не ищет (скриншот прилагаю), но это оттого, что IQDB (по собственным словам, внизу на скриншоте видным) ищет только по JPEG, PNG и GIF.
No. 24946  
Однако не понимаю, почему сёрвер 410чана не указывает надлежащий заголовок «Content-Type», когда отдаёт файлы WebP.

Должно быть, он не настроен руководиться содержимым файла .htaccess, измѣненіемъ которого риквэстъ https://bitbucket.org/Therapont/fbe-410/pull-requests/40 начинался, так что руководится чѣмъ-то другим.
No. 24947  
badlocale.png - (31.90KB, 554×319)
24947
>>24929
>Локализация (ru)
Из-за которой послетала часть переводов в форме постинга.
В модерке локализация не так критична, как в пользовательской части.
No. 24948  
>>24947
Ох ты ж. Пойду смотреть где накосячил.
No. 24949  
>>24947
>>24948
Ага, получается в .pot-файле, который шаблон для локализаций, меньше полей чем в .po-файле, который готовый перевод. Отсюда и "разлёт" при синхронизации, которую я сделал добавляя новые поля. Наверное стоит создать тикет по поводу приведения в соответствие полей шаблона с полями переводов.

Сейчас верну старый файл как был, добавлю новые поля прямо в него, проверю, и обновлю пулреквест.
No. 24950  
bus410.jpg - (63.88KB, 664×498)
24950
>>24947
>>24948
>>24949

Починил и создал пулреквест.
Теперь всё должно быть в порядке.
По крайней мере, дифф распакованных заново файлов показывает что строчки только добавлялись, да и визуально никаких переводов больше не пропадало.
No. 25109  
screenshot.webp - (103.18KB, 1280×2480)
25109
Весь мой труд, вложенный в создание для FBE разворачивателя картинок, размытым фоном под них подкладывающего миниатюру (для мгновенного ≈предпросмотра всего скачиваемого), оказался ѿмѣнённымъ в Файерфоксе: дѣлая новый ускоренный графический движок (WebRender), разработчики сперва захардкодили бѣлый фон для JPEG (да и для WebP, кажись), а затѣмъ съ лѣта позапрошлого (2019) года забили на это, что можно по адресу https://bugzilla.mozilla.org/show_bug.cgi?id=1556156 видѣть.

Ѽ, етить.
No. 25113  
>>25109
Ну и что? Если разворачиватель будет работать с другими форматами и со всеми форматами в других браузерах, будет тоже очень хорошо.

Кроме того, у меня баг не воспроизводится на приложенном тест-кейсе (https://phoboslab.org/files/bugs/firefox-image-loading/) и всё работает как положено. Firefox 84.0.2 64-bit, Ubuntu 20.04.1 LTS.
No. 25116  
screenshot.webp - (139.95KB, 1280×1925)
25116
>>25113

Дѣло тутъ въ томъ, небось, что по адресу https://wiki.mozilla.org/Platform/GFX/WebRender_Where повѣдываютъ, что WebRender не полностью притащили ещё на Linux (и, въ частности, на Ubuntu).
No. 25118  
>>24950
Обнаружил что 11я задача, про объединение нитей, всё еще в открытом состоянии, хотя изменения уже включены в движок. Если ничего больше пока делать не надо, наверное можно её в Resolved?
No. 25123  
hanyu.png - (69.24KB, 210×200)
25123
Призываются настраивавшие локализацию в FBE.
Есть правильный, не костыльный способ переключить доску / админку с английского на другой язык?

Изменение KU_LOCALE, как и локали в настройках доски ничего не даёт.

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

Расскажите, пожалуйста, где и как это правильно делается.
No. 25124  
161206701125.png - (48.94KB, 960×418)
25124
Добавьте в шаблоне тегу <html> атрибут <html lang="ru">, иначе если в системе стоит японская локаль, текст будет отображаться вот так.
No. 25125  
>>25124
Спасибо за совет! Сейчас дело в том, что в системе стоит только C.utf8 да установлен ru_RU.utf8
Точно установлены, потому как если добавить LANG в ENV то баш начинает говорить по-русски. А вот flower bus engine — нет.
Вопрос на самом деле, что писать в locale доски для регенерации всего в локали ru.
No. 25126  
Или альтернативно, понять, как правильно поставить (и проалиасить?) локаль в систему (Debian), чтобы FBE (или _gettext() в lib/gettext/gettext.inc.php?) её увидел и хотя бы попытался воспользоваться ей для локализации страниц, потому что на вид - даже не пытается. Может вы помните, как это делали вы?
No. 25128  
>>25124
С 2018 такой тикет на трекере висит.
No. 25130  
subject.webp - (26.34KB, 982×518)
25130
>>25123
Там вроде бывает такая проблема, что неправильно валидируется тип mo-файлов локалей. Конкретнее, неверно происходит сравнение магических чисел, поскольку они неверно определены. У себя было решил, убрав из конструктора gettext_reader в lib/gettext/gettext.php строки $MAGIC1 = (int) - 1794895138; и $MAGIC2 = (int) - 569244523, раскомментировав соседние, помеченные как bug in PHP5. Видимо, в новых версиях PHP этот bug починили, оттого и проблема.
No. 25131  
>>25130
Возможно, починили и в PHP 5.6.14 (это та что используется с FBE в моём случае), попробую, спасибо за совет!
No. 25134  
Тѣмъ временем на стриме https://www.twitch.tv/videos/896572546 на рубеже четвёртого и пятого часа вѣщанія опредѣлилися, что поддержки AVIF не будет на 410чанѣ до тѣхъ поръ, пока Apple не поддержит AVIF в Safari.
No. 25151  
screenshot.webp - (89.41KB, 1200×957)
25151
Тѣмъ временем на далёком горизонте видна приуготавливающаяся необходимость поддержки ещё одного формата файлов в будущем FBE.

Сегодня около пяти часов утра (по московскому времени) по адресу https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 сдѣлалось видным, что Google начинает впиливать поддержку нового формата изображений JPEG XL в свой движок Chromium, служащий основою для браузеров Google Chrome, Opera, Microsoft Edge, Brave, Vivaldi, etc.
No. 25158  
Пока вы тут флудите, открыл новую задачу: https://bitbucket.org/Therapont/fbe-410/issues/40/newsphp
No. 25159  
>>25158
А редизайн главной на манер ычана в этот тикет не входит?
No. 25161  
>>25159
Это будет уже другой.
No. 25162  
>>25159
> редизайн главной на манер Ычана
Не дай Бог такое жуткое вырвиглазие и здесь увидеть.
No. 25177  
screenshot.webp - (65.05KB, 1280×3796)
25177
Так как по адресу https://bugs.webkit.org/show_bug.cgi?id=207750 мы видим (скриншот прилагаю), что поддержка AVIF добавлена в WebKit (движок Safari) пятого марта, то не за горами устранение названного в реплике >>25134 препятствия к внедрению AVIF на 410чане: всѣ, всѣ браузеры скоро будут поддерживать AVIF — даже Safari, а не только Google Chrome и Mozilla Firefox.

Есть ли другие ещё препятствия к этому? Как там поживает поддержка AVIF в той версии ImageMagick, которая установлена на сёрверѣ? — и если никак, то тогда нѣтъ ли там возможности так хорошо обновить ImageMagick на новую версию, чтоб одним махом получить не одну только поддержку анимированных WebP, но и поддержку AVIF заодно с нею?
No. 25178  
>>25177
Кстати, на счет версии на сервере. Возможно ли опубликовать версии пакетов на продакшене, дабы иметь возможность локально проверять на подобных версиях свои изменения?
No. 25181  
>>25178
На сервере стабильный «Дебиан» и версии оттуда.
No. 25184  
Насколько я понимаю, нынешняя (десятая) версия Debian вышла въ свѣтъ в июле 2019 года, а девятая версия — в июне 2017 года.

Если строить на основе этого прошлого свои дальнѣйшія ожидания, может быть наивно, то тогда можно ждать того, что слѣдующая (одиннадцатая) версия Debian появится к концу лѣта нынѣшняго (2021) года (или хотя бы немногим позже).

Мнѣ не извѣстно, однако же, какая будет в ней версия ImageMagick, окажется ли доступною поддержка JPEG XL, или AVIF, или хотя бы анимированных WebP только; может ли кто-нибудь просвѣтить по этому вопросу?
No. 25253  
screenshot.webp - (54.00KB, 1280×720)
25253
Кажется, надо что-то дѣлать либо насчётъ Unicode-aware обрѣзанія имёнъ файловъ, либо насчётъ меньшей строгости подхода MySQL къ допустимости непарныхъ surrogate pairs въ текстѣ.

Прошу ѿкрыть FBE issue по этому поводу.
No. 25267  
xkcd workflow.webp - (30.19KB, 278×386)
25267
Если стабильным «Дебианом» в сообщении >>25181 называется совершенно то же, что и на странице https://www.debian.org/releases/stable/ (то есть десятая версия «Дебиана»), то предлагаю подтвердить или опровергнуть утверждение автора сообщения https://014chan.org/d/res/82.html#308 о том, что в этой версии ImageMagick понимает формат AVIF.

Если стабильным «Дебианом» в сообщении >>25181 называется не совершенно то же, что и на странице https://www.debian.org/releases/stable/ (то есть не десятая версия «Дебиана», а нѣкая болѣе ранняя — скажем, девятая), то тогда не морочьте мозги, выражайтеся пояснѣе.
No. 25268  
>>25267
Меж тем, прямо в этом треде указана используемая версия ImageMagick.
No. 25290  
Переключил стиль на блумун. Теперь при загрузке страниц сначала виден дефолтный стиль, а после окончания переключение на выбранный. В итоге "мигание" на доли секунды. Может он там где-то внутри по два раза применяется?
Safari
No. 25291  
>>25290
Это вроде просто баг системы стилей, которая сначала грузит дефолтный, а потом яваскриптом применяет юзерский.
No. 25292  
>>25291
Наверное стоит сделать отдачу выбранного стиля прямо с сервера.
No. 25294  
>>25292
Сервер отдает статичный html + css + js, перестраивая их только когда добавляется пост, так что не уверен что получится.
No. 25295  
>>25292
>>25294
В целом css и так отдается с сервера, скрипт его только переключает.
No. 25296  
>>25295
я имел ввиду, что нужный css летел бы уже активным в html.
No. 25297  
>>25290
Речь про это заходила уже вроде. Тогда были какие-то изменения и сказали, что с текущим механизмом баг не исправить. А раньше вроде было работало, для чего сломали переключалку — не понятно.
No. 25298  
>>25297
Пришло время нового движка
No. 25299  
>>25297
Я подозреваю, что исправить всё можно, просто никому это не интересно.
No. 25300  
>>25299
Я посмотрел одним глазом. Похоже, там просто надо в вызовах printStylesheets() передать значение стиля, полученного из куки, вместо KU_DEFAULTMENUSTYLE. Но я php не умею.
No. 25301  
>>25300
Это ничего не даст.

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

А так все читающие доску / тред получают с сервера один и тот же HTML, CSS и JS. Поэтому прямолинейной модификацией генератора HTML проблема нормально не решится, в лучшем случае это будет "один любимый стиль для всех", что и так сделано в рамках "стиля по умолчанию"
No. 25302  
dev.png - (10.83KB, 288×216)
25302
>>25300
Пикрелейтед, как выглядит доска для движка.
Как видишь, всё уже создано заранее.
No. 25303  
>>25301
>>25302
В Кусабе есть кнопка для регенрации досок вообще-то.
No. 25304  
>>25303
Но регенерируется-то оно всё равно сразу для всех.
No. 25305  
>>25301
кек
No. 25341  
AV1chan drawn by eivarain.png - (2.66MB, 1811×2597)
25341
Нѣсколько запоздалый постскриптум к сообщению >>20564 вот каков: так как в движке FBE проверкою содержимого графического файла на соѿвѣтствіе его расширению занимается (в методе «HandleUpload» у класса «Upload» в файле inc/classes/upload.class.php) вызов функции «getimagesize» языка PHP (то есть функции, по адресу https://www.php.net/manual/en/function.getimagesize.php описанной, если чё), то у этого есть два любопытных послѣдствія.

① Так как в эту функцию (в «getimagesize») поддержку формата WebP добавили только начиная от PHP версии 7.1.0, то поддержка WebP требует и свѣжаго PHP (а не одного только свѣжаго ImageMagick, как кто-то мог бы наивно думать по умолчанию). К счастью, съ нѣкоторыхъ поръ (вѣроятно, >>20671) версия PHP на 410чане достаточно свѣжая для этого.

② По адресу https://twitter.com/markusstaab/status/1369192219618533377 можно прочесть, что поддержка AVIF появилась в libgd только в начале марта нынешнего (2021) года, и примѣрно тогда же начали впиливать эту версию libgd в PHP (в середине марта, как это можно по адресу https://bugs.php.net/bug.php?id=80828 видѣть). Стало быть, чтобы в FBE появилась поддержка провѣрки содержимого AVIF, нам придётся, по меньшей мѣрѣ, либо дожидаться окончания того впиливания (и затѣмъ ещё накатить новый PHP на 410чан), а оно непонятно когда достигнет желаемого, либо переписать метод «HandleUpload» у вышеупомянутого класса «Upload» таким образом, чтобы для новых форматов графических файлов провѣрка контента совершалася при посредстве не GD, а ImageMagick.

Совѣтую непремѣнно имѣть всё это въ виду.
No. 25354  
ChangedStyles.png - (102.71KB, 1920×1030)
25354
Сделал пулл-реквест по таску 25.

Стили меняются везде синхронно и добавлены недостающии стили для фотона (с instant-0chan).

А точно нужно заменять site_<что-то> стили на те которые без префикса? Там всё по другому будет выглядеть, если просто сделать как предложено в комменте к таску и отредактировать printStylesheetsSite в html.php. А если делать правки, чтобы всё выглядело как сейчас, то не уверен, что код будет красивее, если все стили из site_<что-то>.css и <что-то>.css поместить в один файл. Там ещё есть sitemenu_<что-то>.css, и в них тоже цвета повторяются. Их содержимое тоже должно быть объединенос с <что-то>.css?
No. 25355  
12345693.png - (472.68KB, 1146×709)
25355
>>25354
>А точно нужно заменять site_<что-то> стили на те которые без префикса?
Разумеется, никому нахѣръ не нужно по десять файлов там, где достаточно одного. sitemenu тоже упразднить. Смысл в глобальной переключалке и глобальных стилях.
Вам не требуется редактировать эти CSS, добавлять недостающие фотоны и подобную лабуду, с этим я сам буду разбираться: очевидно, что для наилучшего результата надо классы в вёрстке ковырять.
No. 25356  
>>25355
Просто навесить классы на body в меню и на служебных страницах достаточно? Чтобы потом их использовать во всех стилях из site_ и sitemenu_.

Создал другой пулл реквест.
No. 25357  
>>25290
Это тоже пофиксил. Просто нужно вызывать функцию setStylesheetFromLocalStorage, проставляющую атрибут disabled стилями, ещё во время загрузки head'а, до загрузки контента. То есть нужно не оборачиват вызов в $(), потому что так она вызовется после загузки всего DOM'а, а прямо сразу вызывать. Тогда контент загрузится сразу с правильными стилями.
No. 25358  
>>25357
Вроде всё хорошо, но использование img_global.css во фреймах так и не прописано, хотя это прямо указано в задаче.
No. 25360  
>>25358
>хотя это прямо указано в задаче
Точно...

Переделал, создал пул реквест. Общие стили перенесены в img_global.css.
No. 25367  
Создал пул реквест для задания 5.

Первый коммит фиксит ссылки в перемещаемом треде.

Второй коммит добавляет в таблицы с постами поле initial_board, чтобы отслеживать перемещение тредов. Если константа KU_INDICATEMOVEDTHREADS установлена в true, в загаловке треда появляется сообщение Moved from /board/. Чтобы добавить поле initial_board в существующие таблицы, в админке создана страница Update в разделе Site Administration c кнопкой Update. Перемещение тредов будет фейлиться без обновления таблиц, весь остальной фукнционал продолжит работать.

Ссылки фиксятся только в самом перемещаемом треде.
No. 25422  
Стили меню поломались из-за кеша. Сделал пул реквест чтобы пофиксить. После shift+f5 всё и так работает нормально.
No. 25439  
>>25367
Там перенос видосов сломан в переноске тредов.
No. 25440  
>>25439
Да, видел, исправлю.
No. 25454  
>>25440
C последними изменениями появилась бесконечная перезагрузка всех статичных страниц, и тех что через news.php, и тех что через exitWithErrorPage(), и даже меню фрейма.

Исправьте, пожалуйста.
No. 25455  
>>25454
Не знаю, не слишком ли много я прошу, но нельзя ли мне, если можно, конфиги кусабы, с которой это происходит, пожалуйста? И содержание таблицы boards ещё.

У меня на той машине всё нормально работало. Вот только что поднял на другой машине из ветки public и тоже всё работает. Может быть из-за других настроек папок что-то ломается... У меня все доски лежат прямо в перемешку с папками кусабы, css, icons, inc и т.д.

Печаль, печаль, беда... Вот уж чего я не ожидал, так это бесконечных перезагрузок...
No. 25456  
>>25455
Я и так буду разбираться в чём дело, но с конфигами было бы проще.
No. 25457  
>>25455
>>25456
Я так понимаю, что это у него тут такое. У меня такое не воспроизводится ни на одном браузере.
No. 25459  
infinite_reload.png - (62.64KB, 820×782)
25459
>>25455
>>25457

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

Как воспроизвести:
1. Заходим на https://410chan.org
2. Нажимаем в меню слева Авто/b/ус и переходим в /b/
3. Нажимаем в верхнем меню кнопку Избранные нити (иконка звезды справа от выбора стиля)
4. Убеждаемся, что панель Избранные нити открылась и её видно, не трогаем
5. Нажимаем в меню слева Главная страница и переходим на главную страницу
6. Как только откроется главная, пойдут перезагрузки.

Перезагрузки после этого будут на всех статических страницах.

Инициатором перезагрузки страницы, как видно на пикрелейтед, является kusaba.js, строка 565. Эта строчка как раз отвечает за location.reload() в этой функции:

function generateWatchedThreadsElement(){
   var $watched = $('#watchedthreads');
   if( $watched.length ) return false; // already exists

   var $topmenu = $('.topmenu');
   if( $topmenu.length < 1 ){ // incomplete or unexpected DOM
      location.reload(true);
      return false;
   }


Как уже понятно из рецепта воспроизведения, функция эта вызывается только если у вас пытается автооткрыться панель избранных нитей:

   if(
      localStorage.getItem('showwatchedthreads')
   ) generateWatchedThreadsElement()

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

Если сделать localStorage.removeItem('showwatchedthreads') или пробраться на доску без фрейма, и скрыть меню избранных нитей, поведение прекратится.
Если не получится воспроизвести, сообщите, я видео запишу.
No. 25460  
>>25459
Да, видимо коммит fef9a855 от 11.06.2021 это сломал. До него kusaba.js фейлилась гораздо раньше, а теперь стала отрабатывать до конца. Если нет элемента $('.topmenu') достаточно просто ничего не делать, не нужно перезагружать страницу.
No. 25461  
>>25460
Охлол! Получается та самая ситуация, когда совокупность одних багов берегла нас от других. Спасибо за оперативный фикс.
No. 25534  
Господа, мне кажется, или дополнительно отломалось сохранение состояния формы быстрого ответа?
No. 25560  
>>25534
Не кажется.
No. 25561  
>>25460
Сможете разобраться, что вызвало проблему >>25534 и исправить, или надо открывать тикет на починку?
No. 25562  
>>25534
>>25561
tl;dr Так вышло, что в public это уже исправлено.

Причины бага аналогичны >>25460 На странице ошибки тоже грузится kusaba.js, и в этом случае выполняется код, который пробует синициализировать форму быстрого ответа. Этот код фейлится, ошибка обрабатывается, но в обработчике выполняется deinit, а в нём _dropFormData.
В коммите 9949a077 из пул реквеста 54 кроме того, что добавлено условие для создания элемента с избранными нитями, ещё и условие для инициализации формы быстрого ответа исправлено на аналогичное. До этого там проверялось, что в адресе нет menu.php или news.php, а теперь проверяется, что у body есть классы read или board (тред или доска). Оказывается, эта проверка исправляет баг с сохранением формы (форма на странице ошибки не начинает инициализироваться, исключение не возникает, deinit не выполняется).
No. 25563  
>>25562
>tl;dr Так вышло, что в public это уже исправлено.
Это радует. Спасибо!

Получается public еще не развернули просто?
No. 25564  
>>25563
>Получается public еще не развернули просто?
да
No. 25565  
>>25564
Ок, спасибо что уточнили.
No. 25566  
>>25565
В том сымсле, что пул реквест вмёрджен в ветку publc, но что с ним будет дальше, не знаю, это не ко мне. Я всего лишь случайный автор последних правок и я здесь один, лол.
No. 25575  
Просьба администрации отписать, когда будет развернут текущий паблик, чтобы можно было проверить фиксы.
No. 25666  
>>25575
Накатили.
No. 25667  
>>25666
Спасибо за нотификацию!
На первый взгляд всё теперь хорошо, но я еще потыкаю на всякий случай.
No. 25671  
Тесто.
No. 25672  

No. 25673  
Серьёзно, 何?

Новый ImageMagick? (Какой версии?) Может быть, и новый PHP также?
No. 25674  
>>25673
Если это вопрос про "что накатили", то пачку фиксов присутствующих в бранче, но не добравшихся до сервера.
No. 25675  
>>25674
Нет, это у него был вопрос про Дебиан 11 на сервере.
No. 25676  
Стало быть, bullseye пришёл.

Хорошо.

Новинки https://www.php.net/manual/en/migration74.php также теперь доступны, функции-стрелки и всё прочее?
No. 25679  
Напоминаю о том, что директиве «upload_max_filesize» языка PHP неплохо бы придать значение, превосходящее пять мегабайтов.

(Сейчас там, по-видимому, только два.)
No. 25682  
>>25679
Чиочую. А то файлы больше двух мегабайтов не отправляются.
No. 25684  
0n0jr97m92h71.jpg - (412.81KB, 1080×1391)
25684
Таки да, у нас теперь bullseye (лол, коднеймы дебиана теперь на b?), с ffmpeg, imagick, php и вот это всё оттуда.
Лимиты на загрузку поправил.
No. 25685  
Есть ли техническая возможность перейти на нѣчто вроде https://github.com/SoftCreatR/imei/ и получить ImageMagick 7.1.0 раньше Дебиана? — спрашиваю оттого, что никакой другой возможности для поддержки формата AVIF (и затѣмъ JPEG XL) не вижу, даже если условие >>25134 когда-нибудь будет выполнено (то есть даже если Apple в нынешнем же году сподобится засунуть в macOS Monterey поддержку AVIF, напримѣръ).
No. 25686  
>>25685
Нѣтъ.
No. 25687  
Это прискорбно.

Придётся в случае чего подходить къ дѣлу извращённым способом, а именно распарсивать многострочный текстовый вывод команды «avifdec --info имяФайла» — при том непремѣнномъ условии, что https://packages.debian.org/search?keywords=libavif устанавливает avifdec; но я думаю, что устанавливает.
No. 25730  
Новая задача по мотивам старых обсуждений:
https://bitbucket.org/Therapont/fbe-410/issues/41/
No. 25731  
>>25730
А задачи №32 и №40 можно считать выполненными?
No. 25732  
>>25731
Да, закрыты.
No. 25733  
>>25732
Получается, почти весь высокий приоритет закрыли. Yay!
No. 25735  
Впрочем, >>25687 — не единственный вариант.

По наводке https://www.smashingmagazine.com/2021/09/modern-image-formats-avif-webp/ по адресу https://php.watch/versions/8.1/gd-avif вижу упоминание о том, что в API GD в PHP 8.1 (эта версия PHP, как по адресу https://php.watch/versions/8.1 сказано, выйдет в ноябре, то есть менѣе чѣмъ через два мѣсяца) будет добавлена поддержка AVIF.

Интрига в том, что эта поддержка не выглядит полною: по адресу https://github.com/php/php-src/pull/5127#issuecomment-926150566 в настоящее время сообщается, что getimagesize всё ещё не понимает AVIF, но в Google ведётся работа по допиливанию.

Ну предположим, что допилят — дык что ж с того?

Я так кумекаю, что в итоге создастся постыдно идиотская ситуация:

с одной стороны, в коде FBE (и в реальной дѣйствительности 410чана) мы отошли к началу сентября 2018 года от употребления API GD в PHP почти полностью (за исключением getimagesize, о чём в сообщении >>25341 есть подробности) в сторону ImageMagick, потому что иначе хѣровато создавались миниатюры анимаций (к сообщению >>20581 приложена первая на всём 410чане нормальная миниатюра анимации) и вообще GIFов;

с другой стороны, для поддержки AVIF мы принуждены будем частично возвратиться на API GD, если только столкнёмся съ тѣмъ, что в очередной версии Дебиана ужé будет и PHP 8.1 (или той болѣе новой версии, в которой возможности getimagesize достигнут желаемого), и пакет libavif-dev нужной версии (а он ужé в Debian 11 имѣетъ версию 0.8.4, что больше необходимой 0.8.2), а вот ImageMagick всё ещё будет оставаться на шестой своей версии и оттого поддержки AVIF не имѣть.

Ѽ, етить.

(Хорошо ещё, что это не мы идиоты: это они идиоты при выборе версии ImageMagick для Debian.)
No. 25778  
На всякий случай, если кому-то нехватает - правило ublock.

||410chan.ru/css/Akarin2.png$image,first-party

No. 25808  
Вслѣдствіе >>25684 послѣднія словá изъ высказыванія >>/d/2377 болѣе не соѿвѣтствуютъ истинному положенію дѣлъ; это прекрасно, но это должно быть объявлено, чтобъ читатели d/ могли порадоваться этому.
No. 25809  
rin.webm - (4.46MB, 250×250)
25809
Сделал пулл-реквест для задания 41. Комментарии по поводу пулл-реквеста в нём самом.
Что касается задачи максимум+. Предлагается создать в конфиге параметр-имя папки и в эту папку при каждом архивировании копировать всё содержимое папки css, при этом проверять даты изменения файлов, чтобы не совершать лишнюю работу. При регенерации треда в архиве ссылаться на стили в этой папке. Если добавляются какие-то серьёзные измененя в стили, из-за которых старые архивные треды поломаются, то в конфиге нужно поменять параметр, новые стили скопируются в новую папку, и стили из неё будут использовать только новые треды в архиве, а старые треды останутся со старыми стилями. Изменения в стилях между последним архивированием со старыми стилями и первым с новыми не будут учтены, но это, я думаю, не так важно. Если что, можно и вручную всё скопировать. Нормально?
No. 25810  
>>25809
Вёрстка ездит не только от стилей, но и то самого кода. Я вижу этот «максимум+» как некий скрипт, который бы конвертировал статичные HTML-файлы. Даже не обязательно связанный с движком, а просто запускаемый админом на сервере. У нас прямо сейчас уже есть куча файлов с поехавшей вёрсткой.
Просто скрипт надо положить в репозиторий и обновлять в случае необходимости.
No. 25811  
>>25810
А зачем конвертировать HTML-файлы, может быть лучше их просто перегенерировать? Сейчас же посты при архивации не удаляются из базы, им только проставляется флаг IS_DELETED. Или на 410чане в архиве есть треды для которых не сохранились данных в базе? Или в старых тредах есть какие-то визуальные детали, которые при регенерации могут потеряться?
No. 25812  
>>25810
Кстати, я оставил сообщения об ошибке при наведении курсора на ссылку на заархивированный пост. Это сделано только потому что концептуально в моём представлении пост с IS_DELETED=1 сервером во всех смыслах считается удалённым. Но довольно просто можно было бы сделать так чтобы и аяксом эти заархивированные посты возвращались и появлялись в превьюшках. Едиственное, их сложно будет отличить от постов удалённых как-то по-другому, которые действительно не должны нигде появляться. Видимо, это можно будет сделать только по различию deletedat у поста и ОП-поста его треда. А для ОП-постов определить как они были удалены (в ходе архивации, или, например, самим постером) будет ещё сложнее. Только по наличию html-файла в архиве, наверное.
No. 25813  
>>25812
Неправильно написал. По deletedat можно только выявить посты, которые были удалены отдельно от треда (точно удалённые на совсем). Чтобы определить, как был удалён тред, для всех постов, и открывающих, и остальных, придётся проверять наличие файла в архиве.
No. 25814  
Пулл-реквест для задания 42.

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

Используется новая таблица main_subpages; инсерт можно взять из 410chan.sql. Главная продолжит работать без добавления новой таблицы, потому что в news.php была добавлена проверка, использующая information_schema. Страница в админке, разумеется, без новой таблицы работать не будет.

Страницу radio.unix.html тоже нужно добавить в таблицу на странице Main Subpages c чекнутым флагом hidden и любым значением в поле Name.
No. 25815  
>>25814
Кстати, на странице Радио ссылка снизу "Вещание под GNU/Linux" не работает во фрейме. Надо или проставить ей target="_blank" или поменять 410chan.ru на 410chan.org, но тогда ссылка не будет работать, если заходить c 410chan.ru.
No. 25816  
>>25815
Надо просто сделать её относительной, от корня, и тогда будет работать откуда бы не зашли.
No. 25817  
>>25816
Да, так и есть. Это я знатно затупил.
No. 25818  
Пулл-реквест для задания 35.
А как работает локализация на 410чане? Я поставил в админке локаль ru у одной доски, и что-то ничего не переводится. В репозитории много .mo файлов, но они же должны компилиться из .po, правильно? А .po есть только в папке /inc/lang/cu. Я сделал title "Collapse all images" у иконки (кстати, для сворачивания отдельной иконки не нашлось), как добавить перевод не знаю.
No. 25819  
>>25811
Кроме огорода с удалёнными ещё вопрос с нагрузкой на движок от этого всего.

>>25818
Указания локали в админке должно быть достаточно, если что-то не сломано.
Файлы надо вручную декомпилировать, видимо.
No. 25820  
>>25818
>А как работает локализация на 410чане?
Выглядит так будто она почему-то сломана. Выше в этом треде пытались выяснить почему. Начинай читать с >>25123
No. 25821  
>>25818
>>25819
>Файлы надо вручную декомпилировать, видимо.

Всё так, делается с помощью poedit:
> ./poedit/bin/msgunfmt ab_AB.mo > ab_AB.po

Только помните, разные файлы локализации у нас не равнозначны.
И еще, у нас не все строки которые есть в .mo / .po файлах присутствуют в .pot шаблоне, если вы попытаетесь воспользоваться шаблоном - в конце у вас будет не корректный файл локализации.
No. 25822  
>>25814
Во-первых, по умолчанию было бы логично оставить только FAQ и Правила, как наиболее универсальные.
Во-вторых, необходимость прописывать все стандартные страницы заново, если вы, допустим, хотите добавить одну дополнительную, довольно неудобна.

>>25820
Для локали достаточно прописать название каталога с ней (т.е. «ru»). По библиотекам должен быть текущий стабильный «Дебиан», как здесь.
No. 25823  
>>25822
>Во-первых, по умолчанию было бы логично оставить только FAQ и Правила, как наиболее универсальные.
Страницы по умолчанию сделаны только для того, чтобы всё совсем не развалилось, если в админке нет настроек.
>Во-вторых, необходимость прописывать все стандартные страницы заново, если вы, допустим, хотите добавить одну дополнительную, довольно неудобна.
Предполагается, что стандартные страницы будут прописаны не когда возникнет потребность в дополнительной, а сразу. Если оставлять FAQ и Правила как страницы по умолчанию (или показывать их всегда, независимо от настроек), то всё равно придётся прописывать в админке три из пяти страниц, которые есть сейчас.
Мне показалось, что в таске имеется ввиду "English, Радио и все остальные". Но если надо, могу сделать так, чтобы FAQ и Rules появлялись независимо от настроек. Так, как сейчас в пул-реквесте, на мой взгляд универсальней. Если захочется какую-то из страниц убрать, то тоже не придётся ничего менять в коде.
Оставить как есть? Переделать?

>>25819
>Кроме огорода с удалёнными ещё вопрос с нагрузкой на движок от этого всего.
У меня на G4600 перегенерация 4000 постов в 40-ка тредах занимает около 5-ти секунд, немного меньше. В каждом посте ссылка, которая, в соответствии с послденими правками, проверяется по базе. Если нужно, в архиве php файл, который устанавливает рансомварь выдаёт информацию по наличию заархивированных тредов в базе.
Я посмотрел треды заархивированные в разные годы. В основном проблемы из-за того, что css файлы не грузятся. Не грузятся они из-за того, что c https идёт ссылка на http (http://410chan.ru). Нужно просто поменять ссылки в тегах link на относительные, чтобы они заработали. Если заходить в архив с http-адреса, то и так работает. По вёрстке там проблема только в пустом месте сверху, там где сейчас полоса меню. И ещё картинки над текстом поста, а не сбоку, а в оп-посте вообще над шапкой поста. Так и было раньше или это сломалось?
У некоторых тредов в архиве даже можно заставить работать дропдаун для выбора стиля сайта, если поменять protoaculous на jQuery. Но со старыми тредами это не рабоает.
И ещё у архивов 2018-го, 2019-го миниатюрки картинок потерялись.
No. 25824  
>>/b/167954-кун просит не скрывать кнопки в шапке поста на мобильных устройствах. Действительно, а зачем так сделано? Они не очень много места занимают по сравнению со всем остальным. Это чтобы по другой кнопке случайно не попасть? Убрать стили, которые их скрывают?
No. 25825  
>>25823
Ладно, пока оставим так.

>>25824
Оно было скрыто, потому что криво работало под мобилками. Там и сейчас на скрине какие-то лишние плюсы повылазили.
No. 25826  
>>25825
Лишние плюс там из-за 593-й строчки img_global.css
@media only screen and (max-width: 480px)

.unhidethread {
    background: transparent url(./icons/red/icons.svg) -48px 0px no-repeat;
}

No. 25830  
>>25820
>>25822
>Для локали достаточно прописать название каталога с ней (т.е. «ru»). По библиотекам должен быть текущий стабильный «Дебиан», как здесь.
У меня что на Дебиан 11, что на Винде работает только с этим фиксом: >>25130. PHP 7.4. На Дебиан нормально переводит, а на Винде местами вопросики в ромбиках. Без фикса переводится только текст под формой, но он на всех языках лежат в конфиге и берётся оттуда без gettext.

Раз уж начали разбираться с переводами, давайте и всё остальное, чего не хватает, добавим:
Collapse all images → Свернуть все изображения
Hide Thread → Скрыть
Watch Thread → Добавить в избранное
Expand Thread → Развернуть
Un-watch → Удалить
Remove Frames → Убрайть Фреймы
Frames removed. → Фреймы убраны.
Есть ещё unique user posts в тексте под формой. Это не переведено из-за того, что будет по-разному с разными числительными? Если так, то это легко можно сделать с помощью ngettext. Только там на самом деле число не уникальных постов, а уникальныx IP. Давайте на английском поменяем на "unique users", а на русском на "уникальных пользователей".

Нормально?
No. 25831  
stickied.png - (43.37KB, 359×270)
25831
Кто-нибудь, кто разбирается в вёрстке, объясните, пожалуйста, почему иконка закреплённого треда на маленьких экранах немного сдвинута вниз. Эти иконки будет видно, если в правиле для .thrdcntnr .post-badge для маленьких экранов заменить display:none, на display:inline-block. Это строка 759 в img_global.css, но проще прямо в браузере через инструменты разработчика поменять. На больших экранах стили вроде бы все те же самые, но она ровно расположена. И у всех остальных иконок тоже такие же стили, но они немного выше.
У меня даже получилось как-то сделать, чтобы она встала ровно, но потом я моргнул правилом display:inline у спана .extrabtns, в который всё это помещено, и она опять съехала вниз! Видеозаписи не сохранилось.
No. 25832  
410_wrong_block_height.png - (78.47KB, 740×410)
25832
>>25831
>объясните, пожалуйста, почему иконка закреплённого треда на маленьких экранах немного сдвинута вниз

Это неправильное срабатывание вертикального выравнивания. Почему работает неправильно? Потому что у нас выравниваются 1 строчный элемент <span> и 3 блочных <a>.

Если сделать их все <a> или все <span> начнет выравнивать нормально. с той оговоркой, что во втором случае надо еще менять правило показа кнопки ответа, а то из-за display:inline кнопка ответа начнет выше торчать

См. пикрелейтед.

Почему это случается только на маленьких экранах? Явно как-то нехорошо наложились стили друг на друга, но где точно - надо выяснять.
No. 25833  
>>25832
Собственно на пикрелейтед вверху видно, что <span> встал по верхнему краю родительского блока зеленый фон, в то время как <a> стали по центру сработал vertical-align?
No. 25835  
>>25832
Выяснилось, что это из-за разного font-size у ашек и спанов.
>>25825
>Оно было скрыто, потому что криво работало под мобилками. Там и сейчас на скрине какие-то лишние плюсы повылазили.
Плюсы пофиксил. Других проблем не обнаружилось, поэтому сделал пул-реквест. В шапке поста на мобильных устройствах немного кривая вёрстка, но я это не буду трогать (кроме съехавшей иконки, её поправил).
No. 25836  
>>25835
>из-за разного font-size у ашек и спанов.
Ну и ну! Молодец что нашел.

>Других проблем не обнаружилось, поэтому сделал пул-реквест.
Мне кажется, проблема будет с тем чтобы надежно попадать в эти микрокнопки пальцем, но увидим в эксплуатации.
No. 25839  
Janitor.png - (27.59KB, 1120×419)
25839
Соус как-то то ли на стриме, то ли на радио упоминал, что надо бы разобраться, что в движке с модераторскими аккаунтами. Я проверил, они работают.
Есть небольшие баги.
У пользователей есть уровни доступа (доступы к отдельным доскам тоже настраиваются). В частности, для удаления сообщений/нитей - уровень 3, для прикреплённых/закрытых нитей - уровень 5. При удалении со страницы доски (а не из админки) уровень доступа не проверяется. При прикреплении/закрытии нити через модпостинг то же самое. Забанить кого-то без соответсвующего уровня доступа не выйдет, потому что для этого нужно перейти на manage_page.php, где все проверки на месте. С проверкой того, есть ли вообще у пользователя модераторские права на данной доске тоже всё в порядке (только при попытке модпостинга сообщение отправляется, но флаги не срабатывают, а лучше бы, на мой взгляд, выдавалась ошибка).
Suspend не даёт пользователю залогиниться, но, пока он залогинен, никаких проверок этого флага не выполняется, и пользователь может делать всё, на что у него хватает прав.
Кроме модераторов можно добавлять дополнительных админов, уборщиков и VIP'ов.
Уборщики имеют право удалять посты/треды и смотреть кое-какую статистику. Неудобно, что кнопка удаления поста на странице доски у них не работает. И при залогинивании админка их встречает сообщением об ошибке. Ещё для уборщика работают те же уровни доступа, и, если уровень доступа меньше трёх, то он вообще ничего не сможет сделать.
Випы не работают. Судя по коду, предполагалось, что випы смогут модпостить с пометкой ✿✿ VIP ✿✿, но при модпостинге сейчас выполняется проверка, что пользователь админ или модератор. И чтобы сервер понял, какие у пользователя права, пользователь сначала должне залогиниться, а доступа к админке у випов нет.
No. 25840  
>>25830
>Убрайть Фреймы
Убрать фреймы. Заглавная не нужна.
>Un-watch → Удалить
Убрать из списка.
>Давайте на английском поменяем на "unique users", а на русском на "уникальных пользователей".
Получается, что это не уникальные пользователи, а «сообщения N уникальных пользователей». В английском оно так и есть.

>>25839
Я как раз и говорил, что с випами надо что-то порешать.
No. 25841  
>>25840
>сообщения N уникальных пользователей
А целиком как? Там сейчас начинается с "Ныне". "Hыне на доске сообщения N уникальных пользователей"?
>Я как раз и говорил, что с випами надо что-то порешать.
А, да? Подробностей вообще не помню. А зачем с ними что-то решать? Зачем они вообще нужны? Я предлагаю дать им доступ к админке, чтобы они могли смотреть пароль для постинга, и открыть только страницу Изменение пароля. Прикреплять/закрывать нити им нужно будет запретить, возможность постить html оставить, но проверять теги/атрибуты по белому списку. Надеюсь, это реалистично будет сделать с помощью DomDocument без библиотек, ещё не пробовал парсить html на php. Я думаю, и для модераторов нужно ввести проверку при постинге html, потому что слишком опасная фича. Там сейчас можно отправлять хоть одни закрывающие теги, хоть скрипты.
No. 25842  
>>25841
>А целиком как?
Я не знаю, ололо. Поэтому оно и не переведено.
>Зачем они вообще нужны?
Опыт других сайтов показывает, что иногда приходится огораживать доступ. Тут бы они и пригодились. Можно дать им возможность логиниться и последующий постинг без капчи (у админов это уже есть), а также возможность писать с паролем в закрытые для постинга разделы. ХТМЛ им не положен вообще, разумеется.
Другой вопрос, что нужен некий контроль постинга, чтобы знать, какой именно вип что написал (вообще), дабы потом отозвать у него учётку в случае нарушений.
>для модераторов нужно ввести проверку при постинге html, потому что слишком опасная фича
Подразумевается, что в модераторы кого попало не берут. Иначе они и без этого урон нанести могут. Ну или просто убрать в уровни доступа это. Вот сделать, чтобы заморозка аккаунта сразу лишала возможностей, надо.
И кнопки удаления уборщикам сделать надо, действительно.
No. 25843  
>>/b/168697
No. 25844  
modmenu.png - (5.77KB, 315×119)
25844
>>25842
>Я не знаю, ололо. Поэтому оно и не переведено.
Ok, это оставлю непереведённым, для остального создал пул-реквест, и для задания 24 заодно. Для некоторых фраз уже был перевод в словаре, они просто не использовались. Закоммитил файл kusaba.po для русского языка, в kusaba.pot тоже добавил недостающие строки (не разобрался для чего он может использоваться). Ещё пофиксил баг в kusaba.js. Для некоторых фраз всегда выдавался русский текст, независимо от локали. Сейчас русский в этих случаях выводится по умолчанию, если нет атрибута lang. Чтобы для старых нитей, у которых нет этого атрибута, переводы не сломались.

Создал пул-реквест для задания 18 (начал его на прошлой неделе, а не после стрима, лол). Чтобы не было конфликтов в .mo файле, он включает в себя правки из предыдущего пул-реквеста.
Код предупреждений по большей части основан на коде банов. Для них нужны те же самые уровни доступа. Предупреждения тоже могут отправляться для отдельных досок. Хотел сначала сделать все предупреждения глобальными, чтобы они выводились при посте на любой доске, но потом передумал. Раз уж у модераторов права разграничены, то пускай и для предупреждений это работает. У предупреждений нет даты окончания, но на странице в админке есть кнопка для удаления всех просмотренных предупреждений (только для модераторов с доступом >= 7). Немного изменено модераторское меню в футере на странице доски/нити, надеюсь, выглядит ok. Текст предупреждений поддерживает Wakaba-mark, даже ссылки на посты с предпросмотром. Была мысль сделать кнопки Вернуться/Запостить на странице предупреждения, чтобы можно было завершить отправку без возвращения к доске/треду, но непонятно где хранить прикреплённый файл, пока пользовтелю отображается предупреждение. Это можно было бы сделать, но трудоёмко, и придётся затронуть код отправки поста.

>Опыт других сайтов показывает, что иногда приходится огораживать доступ. Тут бы они и пригодились>
По вип-аккаунтам, я так понимаю, что для огораживания их фичи с мод-постингом вообще не нужны. Может быть лучше сделать ещё один тип пользователей для этих целей? И как раздавать логины-пароли? Я предлагаю раздавать всем постерам долгоживущие печеньки и сохранять их в базе (может быть можно и без базы обойтись с использованием какого-нибудь навороченного шифрования). После включения огораживания всем у кого есть печеньки при заходе на борду можно генерировать и выводить логин/пароль, с помощью которого пользователи могли бы зайти с других устройств. Для тех, у кого нет печенек, можно сделать премод. Будет что-то вроде жалоб, которые есть сейчас. Единственная проблема - пользователи должны видеть собственные посты на премодерации, а в сгенерированном hmtl треда этих постов быть не должно. Эти посты можно было бы подгружать Аяксом. У нас уже есть код для предпросмотра поста по ссылке, можно будет его приспособить для постов на премодерации. У пользователя, который отправил пост на премодерацию, будет сохраняться специальная печенька, и такой аякс будет отправляться только если она есть, то есть пользователи, которым посты на премоде не нужны, слать лишние запросы не будут.
No. 25851  
>>25843

Я, в свою очередь, упомяну дополнительные аргументы >>/b/168702 в пользу одной из идей >>/b/168697.
No. 25852  
>>25851
Там только в настройка досок поменять Максимальный размер изображения с 5120000 на 5242880 и будет работать.
No. 25856  
А на сервере установлено расширение php-intl? Проверить можно с помощью php -m | grep intl Это чтобы выводить месяцы на русском в родительном падеже без велосипедов. Установливается с помощью sudo apt-get install php-intl
No. 25860  
>>25844
>Может быть лучше сделать ещё один тип пользователей для этих целей?
Это всё звучит как костыли на костылях. Особенно премодерация. У нас всё равно уже есть эти неиспользуемые випы, так почему бы просто не доработать их?
>И как раздавать логины-пароли?
Да хоть через предупреждения, лол.

>>25856
А зачем нам нужны месяцы в родительном падеже?
No. 25861  
>>25860
>У нас всё равно уже есть эти неиспользуемые випы, так почему бы просто не доработать их?
Випы всё равно по сути не будут использоваться, даже если через них всё делать. Модпостинг им нужно будет полностью октлючить, доступ в админку - дать. И концептуально это не то.
>Да хоть через предупреждения, лол.
С предупреждениями возникнет куча проблем. Во-первых, нужно будет добавлять функционал для массовых предупреждений, потому что IP в базе лежат зашифрованные, и вручную их селектом не достанешь, и добавлять предупреждения по одному долго, прописывать в ручную логин/пароль не реально, и ещё нужно решить за какой срок брать пользователей. Но это ещё просто новый функционал - не так страшно. Во-вторых, если огораживание будет отключено, предупреждения останутся, нужно думать, что с ними делать. В-третьих, после просмотра предупреждение пропадёт, и если пользователь не скопипастил куда-то логин/пароль, не понятно как ему их восстанавливать. В-четвёртных, самая большая проблема, как раздавать логины/пароли новым пользователям/IP. По запросу в /d/? А если /d/ тоже придётся огораживать? Премод выглядит надёжнее.
>А зачем нам нужны месяцы в родительном падеже?
Чтобы красивенько выдавать дату создания предупреждения, а не так как сейчас: "Предупреждение было создано December 8, 2021, 9:47 am". Ну да, можно поменять на "Дата создания предупреждения:", но с полным именем месяца было бы лучше, по-моему. intl это же, вроде бы, основная вещь, может быть ещё зачем-то понадобится. Оно не установлено, да?
No. 25862  
>>25860
>Особенно премодерация.
А почему премодерация - костыли? На Доброчане разве не так всё работало долгое время?
No. 25865  
12345697.png - (321.73KB, 898×641)
25865
Потестировал предупреждения.
1. При выносе предупреждения оно автоматически удаляет сообщение, хотя никто не просил этого делать. Предупреждаемые сообщения не обязательно подлежат удалению. Это лучше отдельной опцией.
2. На странице предупреждения можно было бы автоматически указывать, за какое сообщение предупредили автора. В модлоге, наверное, тоже.
3. На оной странице нет навигационного меню. Если у нас с банами такая же лабуда, то надо добавить и туда.
Потестировал локализацию.
1. Плашка скрытых нитей не переведена, было бы логично тогда доделать и её.
No. 25873  
Забавный баг - у картинки переворачивается превью: http://410chan.org/b/res/169583.html#169707
No. 25881  
Если поведение >>25873 будет признано проблемою (въ соѿвѣтствіи со вторым из изложенных в сообщении >>20450 принципов), то тогда рекомендую добавить параметр https://imagemagick.org/script/command-line-options.php#auto-orient в ту командную строку, которою ImageMagick вызывается.
No. 25901  
Мне тут подсказывают, что php-intl у нас есть.
No. 25902  
Ошибка при постинге изображений: https://pastebin.com/Z7jygjny

Чаще бывает с мобильного, но в этот раз я поймал с десктопа.
Вот изображение: https://disk.yandex.ru/i/hKCqKCDmIwLzwg
No. 25903  
>>25902
Получается, имейджмеджик сломался и не смог в thumbnail, оттого и размеры пустые?
No. 25906  
Ichigo_Mashimaro_OVA-2.png - (308.17KB, 1024×576)
25906
>>25902
У меня скачанная с яндекс.диска PNG спокойно запостилась.
У яндекса может быть предобработка изображений и для скачивания с него нужны скрипты.
Лучше https://catbox.moe для картинок пользоваться.
No. 25907  
>>25903
Получается, что ошибка возникает, если ту PNGшку запихивать с JPG расширением.
No. 25921  
Да.
No. 25923  
bell.png - (10.71KB, 400×400)
25923
У меня вопрос на милионн, зачем сайту яндекс статистика?
Кроменя бесполезной информации вроде собирания юзер агента посетителей и создавания красивых графиков постов за час/день есть какая-то функция?
Последнее кстати собирают все открытые движки что я видел, правда без красивых графиков. И иногда не видны в интерфейсе.
No. 25926  
Я смотрю, исправление ссылок при объединении нитей сломалось.
Автор ещё тут хоть?
No. 25927  
>>25926
При объединении, или при переносе?
No. 25928  
>>25927
Объединении. Причём раньше работало.
Пример: >>/b/157239, начиная с >>/b/173234
No. 25929  
>>25928
Ага, вижу, превью работает корректно, а сама ссылка при этом неправильная, со старой нитью.
No. 25930  
>>25926
>>25929
Починил и создал пулреквест.
Оказалось настолько тривиально, что даже стыдно за такое.
No. 25935  
В пулл-реквесте с предупреждениями автор добавил экранирование ХТМЛ для модлога, но не учёл, что таким образом ломаются ссылки для просмотра удалённых сообщений. Мы пока вернули эту строку, дабы ссылки работали, но настоятельно рекомендуем найти способ починки этой лабуды, ибо оно не позволяет использовать ХТМЛ в предупреждениях.
No. 26068  
>>26066