Так, надоело.
После того, как почистил куки, стали раскрываться скрытые треды, предположительно после перезагрузки браузера.
Сейчас проверю.

>>20344
Да, после перезапуска браузера слетает скрытое.

1) Какой браузер?

2) Если открыть отладочную консоль и ввести «getCookie('hiddenthreads')», каков будет отклик?

>>20348
1) Всё та же Канарейка.
2) Со скрытым закреплённым тредом: "["19666dev"]". После перезапуска браузера: ""
Скриншот консоли после перезапуска прилагается.

>>20350

Я нашёл опечатку в исходном коде, предотвращающую хранение сохранённых нитей в cookies при перезапуске браузера.

Приношу извинения за неё, однако исправлять её ужé поздно, так как и без того в репозитории менее часа назад этот исходный код был убран¹ из ветви public в пользу более новой реализации (вообще не использующей cookies, а использующей localStorage), так что остаётся дождаться её внедрения на сайте 410чана и исчезновения ошибки этим способом.

________

¹ Речь идёт о правке https://bitbucket.org/Therapont/fbe-410/commits/b027855c74cc804d60b9f031b39e60b0359c7c3c

До этой правки опечатка содержалась в строке 355 в файле kusaba.js.

Несколько отвлечённый вопрос: Issue #8: Картинки-спойлеры. Вам когда-нибудь захочется поменять спойлер-картинку и оставить на уже запощенных к тому моменту постах с картинкой-спойлером старую версию? Или иметь больше одного вариантаа спойлер-картинки? Если да, то я предлагаю хранить в БД путь к уменьшенной копии изображений(файлов), как к Вакабе.

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

>>20356
Там некая работа по картинкам-спойлерам уже была начата, вроде. Надо на это ориентироваться.

>>20356

> иметь больше одного варианта спойлер-картинки?

По умолчанию отвѣтъ «да, по возможности», так как по адресу https://bitbucket.org/Therapont/fbe-410/issues/8 сказано: «Опционально: возможность задать для разных досок разные заглушки».

>>20366
Разные спойлеры на разных досках != разные спойлеры на одной доске. Спрашивалось про второе.

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

>>20369
Совас, скоро обновишь на серваке?

>>20370
Да всё обновлено, вроде.

>>20372
Скрытое всё ещё сбрасывается перезапуском браузера, а стили сбрасываются по обновлению страницы. Куки и кеш чистил.

>>20372

Сейчас 410чан всё ещё пользуется той версией кода ветви public, которая была 22 июля, а не той, которая сформирована 28 июля.

Впрочем, так как по адресу >>20272 сказано «тестирование предложенных изменений будет только тогда, когда будет возможность. Обычно, это какие-нибудь выходные», то надо думать, что на этих выходных не представилося возможности.

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

Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0; Funtoo; скрипты 410chan’а включены.

>>20378
>обновлении страницы
fixed

>>20378

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

С сегодняшнего утра 410чан работает на новом коде сайта, за что вдругорядь благодарю администрацию. А теперь — несколько слов о произошедших изменениях.

Во-первых, генерируемый код HTML сильно почищен. В нём не будет атрибутов «onclick» у миниатюр, не будет тегов «audio» у звуковых файлов, не будет скриптов скрытия у каждой нити обсуждения, не будет генератора окошка «Избранные нити», не будет вызовов функции «highlight». (Функции, ранее исполнявшиеся этими разрозненными кусками кода, теперь исполняет kusaba.js.) Ожидаемый эффект — уменьшение размера страниц, ускорение их поступления с сервера.

Во-вторых, упрощён селектор, на который подвешен обработчик гиперссылок «Полный текст». Ожидаемый эффект — основанное на https://api.jquery.com/on/#event-performance ускорение обработки события. В качестве побочного эффекта на кэшированных страницах (особенно на ненулевых страницах досок) эти гиперссылки вернутся к прежнему поведению (открытие страницы обсуждения, а не раскрытие хвоста реплики) — но только на время, то есть до тех пор, пока кэш не обновится по мере создания новых нитей обсуждения.

В-третьих, сделан первый шаг к реализации пожелания >>18017 о хранении как можно большего количества данных не в cookies, а в localStorage. Сейчас именно localStorage используется для хранения данных о выбранном стиле (Umnochan, Burichan, Futaba, Photon, Kusaba, Bluemoon), о скрытых нитях обсуждения, о видимости и положении и размерах окна «Избранные нити». Ожидаемый эффект — заметное уменьшение объёма cookies и оттого заметное ускорение передачи обращений к серверу 410чана. Эффект наступит по мере того, как ранее установленные cookies протухнут (через год для стилей, через месяц для остальных данных), но он наступит мгновенно для новых посетителей 410чана и для тех из вас, кто вручную очистит cookies. В качестве побочного эффекта сегодня для всех обнулены настройки стилей, и скрытых нитей, и видимости и положения и размеров окна «Избранные нити»: их придётся заново задать в пустом новом хранилище localStorage. В качестве другого побочного эффекта пользователи различных адресов сайта получают различные (первоначально пустые) хранилища, а во браузерах различными сайтами считаются даже http://www.410chan.org относительно http://410chan.org (без www) или https://410chan.org относительно http://410chan.org (без HTTPS). Это техническое ограничение, насколько мне известно, задано непреложно и непреодолимо, поэтому читателям придётся один раз определиться с адресом и протоколом и впредь его придерживаться.

В-четвёртых, отмеченные по адресу >>20344 и >>20312 ошибки должны были исчезнуть (первая — ввиду перехода на localStorage, вторая — ввиду попытки обхода найденного по адресу https://crbug.com/843887 бага). Если они не исчезли, прошу сообщить.

>>20381
Good Job!

За изменения, конечно, спасибо, но побочек столько, что лучше бы их [изменений этих] не было.

>>20381
Всё работает, спасибо!

К сожалению, номерные гиперссылки (при нажатии на номер реплики справа от слова «No.» в заголовке реплики вставляющие >>номер в поле ввода), хотя и продолжают преспокойно работать на страницах досок, перестали работать на страницах отдельных обсуждений.

Это заранее не предвиденный побочный эффект от сáмого первого и далеко не завершённого ещё шага в попытке подступиться к решению проблемы, упомянутой по адресу >>/d/1432 и затем ещё https://bitbucket.org/Therapont/fbe-410/issues/22 (проблемы, состоящей в том, что номерные ссылки перебрасывают на страницу обсуждения со страниц «Первые 100 сообщений» и «Последние 50 сообщений»).

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

>>20386

> надеюсь завершить в скором времени

И завершил: https://bitbucket.org/Therapont/fbe-410/pull-requests/8

Более-менее официальное объявление https://twitter.com/jredmond/status/1024474544784850944 (согласующееся с моими изложенными по адресу https://twitter.com/FidonetRunes/status/1024591330310324225 наблюдениями) гласит, что путинисты зароскомнадзорили BitBucket.

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

>>20388
Вроде в битбакете уже поменяли еще раз на незаблокированные:
https://twitter.com/PavelVorobyov/status/1024538968774324225
https://twitter.com/zloy_i_tupoy/status/1024543583729266688
Собственно, битбакет же сейчас в процессе смены адресов, о чем они предупреждали последнюю неделю, так что будет шатать.

>>20388
>>20389
Попробуй пока в хосты руками прописать незаблокированный айпи, и сообщай результаты.

Спасибо, пока что всё прошло без каких-либо моих действий — не знаю, надолго ль.

Снова отрубился доступ.

Поневоле пришлось совету >>20390 пока что последовать. Результаты положительные: доступ восстановился.

>>20396
Я подключил себе ipv6 от Hurricane Electrics. Через него открывается

Упомянутый в реплике >>17704 вызов «alert» и упомянутый в реплике >>17733 атрибут «onlick» убраны из ветви public два часа назад.¹

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

________

¹ Коммит https://bitbucket.org/Therapont/fbe-410/commits/ab5e49eb6cdda202cb896a5f33dc34733917d0ae

>>19198

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

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

>>17376

> А вы учли, что есть ещё кнопка «Развернуть все изображения», которая появляется в нитях, где много картинок?

Надо бы не забыть перетащить и её логику с сёрвера во браузер, облегчив всѣ такие страницы.

>>17408

> <meta name="twitter:card" content="summary">

Хорошая была идея.

>>18182

> Он может исчезнуть в любой момент без особенных проблем.

Кажись и исчез, кстати.

>>18819

> Можно ffmpeg.

Установлен ли FFmpeg на сёрвере в настоящее время?

Как выглядит результат работы команды «fmpeg» без параметров? — или хотя бы каков номер версии, в первой строке выводящийся?

Спрашиваю это оттого, что мысль >>20325 выглядит плодотворною по отношению к коммиту https://gitgud.io/devarped/instant-0chan/commit/351c5f0230ec52e2738a589c1ee0fefca08639b8 в коде Зерочана, который добавляет поддержку FFmpeg в качестве генератора миниатюр (не только миниатюр видеозаписей, что понятно, но и миниатюр обычных файлов, то есть в качестве альтернативы для внутриPHPшной библиотеки GD). Что позволит https://ru.wikipedia.org/wiki/Фильтр_Ланцоша напилить и вообще КАЧЕСТВО.

(Ожидаемый эффект — резкий рост качества и скорости генерации миниатюр; ожидаемый побочный эффект — рост требований к количеству свободной оперативной памяти, потому что наряду с PHP в ней будет время от времени FFmpeg крутиться. Много ли на сёрвере свободной оперативной памяти, хорошо ли настроен swap?)

Реплику >>20401 следует, поразмыслив, дополнить (и дополняю) упоминанием о том, что, хотя коммит https://gitgud.io/devarped/instant-0chan/commit/351c5f0230ec52e2738a589c1ee0fefca08639b8 был шагом в правильном направлении, он оставляет ещё желать много лучшего и подлежит, по меньшей мере, полудесятку более или менее значительных улучшений, если впиливать его в код FBE.

И улучшил, и впиливаю: https://bitbucket.org/Therapont/fbe-410/pull-requests/12

По адресу http://ii.yakuji.moe/d/res/232761.html#232834 нетрудно видеть, что чуть более двух лет тому назад я счёл, что одной из важных проблем современного имиджбордизма является одновременное достижение двух следующих целей, находящихся друг ко другу в кажущемся противоречии:

1) Преодоление лимита объёма файлов.

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

Наличие в коде конфигурации Кусабы настроек с названиями «$cf['KU_WEBCORAL']» и «$cf['KU_BOARDSCORAL']» ясно говорит нам, что необходимость такого достижения сознавал (чуть более, чем наполовину)¹ и создатель Кусабы — и предусмотрел возможность, позволяющую возложить задачу файлораздачи на сеть узлов https://en.wikipedia.org/wiki/Coral_Content_Distribution_Network (действовавшую с 2004 по 2015 год).

Два года назад такое возложение было бы ужé не возможным (ввиду гибели Coral CDN), однако я предположил, и небезосновательно, что P2P-распределённая файловая система IPFS могла бы взять на себя задачу хранения и раздачи крупных файлов, тогда как на имиджборде оставалось бы только поставить ссылку, в IPFS ведущую.

Последовало пространное обсуждение, и наконец после ряда экспериментов (которые сейчас по адресу http://ii.yakuji.moe/b/res/4157230.html можно видеть) автор репозитория https://github.com/Kalaver/ii2ipfs сочинил юзерскриптовую реализацию моей мысли.

Теперь же впору подумать о том, как подобная реализация могла бы выглядеть в рамках FBE.

Прежде всего, попытка загрузки крупного файла на имиджборд могла бы сопровождаться появлением заглушки «крупный файл» (функционально аналогичной заглушке «спойлер», то есть всегда одной и той же для однотипных случаев) с гиперссылкою, ведущею в IPFS, если у читателя сайта, пытавшегося загрузить файл на доску, была установлена минимальная поддержка IPFS — работающий демон с доступным API (либо по адресу «localhost:5001» непосредственно от демона, либо как объект «window.ipfs» от расширения-компаньона²). Это избавило бы от хостинга крупных файлов, в то же время позволив как бы публиковать их.

Кроме того, вероятно, отдельные настройки могли бы предусмотреть IPFSизацию всего (или почти всего) того, что в настоящий момент настройками «$cf['KU_WEBCORAL']» и «$cf['KU_BOARDSCORAL']» корализируется — и что можно в подкаталог /ipfs/ засунуть, после чего запустить «ipfs add --nocopy» и опереться на https://github.com/ipfs-shipyard/ipfs-companion/issues/16#issuecomment-336641844 (раз уж на https://github.com/ipfs/notes/issues/104 опереться нельзя за отсутствием реализации). Это избавило бы от крупного траффика в тяжёлых случаях пиковой нагрузки.

То и другое потребует, разумеется, оповестительных изменений в FAQ, ведéния пропаганды IPFS среди читателей. Возможно, администрация не готова к тому — и сообщество также не готово — по соображениям, в реплике >>18109 изложенным («У людей даже от мелочей зловещая долина каждый раз»).

____________

¹ Я пишу «чуть более, чем наполовину», так как корализация решает только задачу избавления сайта от крупного траффика, но не задачу избавления от хранения крупных файлов. Первая задача несколько больше второй, так как способна порождаться не одним только скачиванием крупных файлов, но также и изобильным скачиванием мелких — например, в результате slashdot-эффекта, или хабраэффекта, или пиковой популярности некоторой имиджбордовской публикации в какой угодно другой обширной социальной сети.

² По адресу https://github.com/ipfs-shipyard/ipfs-companion#ipfs-api-as-windowipfs есть о том подробности.

>>20401

> Надо бы не забыть перетащить и её логику с сёрвера во браузер, облегчив всѣ такие страницы.

И перетащил: https://bitbucket.org/Therapont/fbe-410/pull-requests/14

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

>>20410
1. Нехѣръ перекатывать нити администрации.
2. Нехѣръ перекатывать нити до того, как они сколько-нибудь утонут.

Оке.

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

В настоящий момент она утонула ниже всего одной другой нити, не считая прикреплённой.

Надо вернуть возможность после использования «Развернуть все изображения» одновременно свернуть все картинки обратно, иначе это крайне неудобно.

>jpeg в kusaba.js
Кусаба внутри переименовывает все jpeg в jpg.

>>20418

Исходный код для устранения обнаруженной чрезмерности был помещён в запрос на слияние, по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/16 опубликованный.

>>20417

Исходный код для реализации предложенной отмены поведения был помещён в запрос на слияние, по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/17 опубликованный.

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

Обнаруженный в реплике >>20386 недочёт устранён, и с ним устранена ещё та проблема (ранее в реплике >>/d/1432 и затем ещё по адресу https://bitbucket.org/Therapont/fbe-410/issues/22 упоминавшаяся), которая состояла в том, что номерные ссылки напрасно перебрасывали на страницу обсуждения людей, находившихся на страницах «Первые 100 сообщений» или «Последние 50 сообщений». Устранена она с бóльшим размахом, так что теперь и во включённом режиме «Быстрый ответ» нажатие на номер реплики вставляет >>номер в текстовое поле, никуда не переходя.

Дополнительно одержана победа и над склонностью формы ввода подлазить под верхнюю навигационную панель в момент нажатия на гиперссылку «Быстрый ответ».

Обнаружен и обойдён в движке https://github.com/tannernetwork/resizable такой баг, который иногда сообщает о нулевой ширине и высоте блока. Он проявлялся время от времени как изменение ширины и высоты оконца «Избранные нити» к прежним значениям по умолчанию, совершавшееся в момент его открытия. Теперь не проявляется, потому что теперь нулевые значения отбрасываются, игнорируются.

Автором реплики >>/d/1837 было обнаружено, что автоматическая вставка в текстовое поле того >>номера, который в адресе страницы после «#i» указывается, нужна не во всех случаях: иногда он в том поле указан уж, особенно если страница открыта переходом по кнопке «Назад» после сообщения об ошибке (например, о протухшей фапче или о превышении предельного размера реплики или размера файла). Теперь повторная автоматическая вставка >>номеров предотвращается.

Автором реплики >>/d/1835 было обнаружено, что на страницах издавна стоит джаваскрипт, пытающийся на лету отредактировать стили страницы в Chrome или в WebKit, но терпящий в том неудачу и оттого порождающий ошибку. Этот скрипт был уничтожен физически; заодно и скрипт, совершающий проверку состояния «проезд оплачен» у фапчи, был убран со страниц сайта и переставлен в kusaba.js, чтобы не утяжелять страницы собою, а кэшироваться.

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

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

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

Вот в ответах «Сообщение слишком длинное. Полный текст.» разворачивает сообщение, а в ОП-постах — нет.

>>20422

Исходный код для устранения обнаруженного недочёта был добавлен в запрос на слияние, по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/16 опубликованный.

К предложению >>20248 прилагаю адрес http://ignitersworld.com/lab/radialIndicator.html одного из тех плагинов, которые способны стать подспорьем в намерении достигнуть желаемого.

>>20279

Читал https://bitbucket.org/Therapont/fbe-410/pull-requests/15

Много думал.

Возникло полдесятка вопросов, и задам их.

Вопрос №1. Как получилось, что в начальном сопроводительном тексте значение «mediatype='image'» задаётся не только для «'jpg'» и «'png'» и «'gif'», но также и для «'xcf'» и «'svg'»? Точно ли в коде FBE есть средства, способные обеспечить генерирование миниатюр для них? (Кроме того: не следует ли вообще подумать об отказе от принятия файлов SVG на хост 410chan.org ввиду того, что подобный https://stackoverflow.com/a/5381905 джаваскрипт внутри SVG может потырить cookies, если автор SVG не добронамерен?)

Вопрос №2. Как получилось, что в начальном сопроводительном тексте есть SQL-инструкции для назначения значений «mediatype='image'» и «mediatype='audio'», но не «mediatype='video'»? (Это потому, что в настоящее время в SQL-базе не предполагается наличие ранее заданных типов, которых надобно обозначить в качестве видеофайлов? Или есть другая причина?)

Вопрос №3. Точно ли в командной строке, вызывающей FFmpeg, нужен параметр «-r 1» в том случае, когда параметр «-frames:v 1» там также ужé есть? Зачем?

Вопрос №4. Правильно ли я понимаю, что изменения, внесённые в файл «inc/classes/upload.class.php» с двухсот восьмой по двести тридцать седьмую строку (вычисление процентного отношения и умножение с последующим округлением, в случае видео подменяющие простой вызов «getimagesize($this->file_thumb_location)») — это костыль, вызванный к жизни тем обстоятельством, что при вызове FFmpeg в командной строке использован параметр «'-s '.$new_w.'x'.$new_h», который не радует тем, что миниатюра всегда приобретает форму прямоугольника размером $new_w на $new_h пикселов (при настройках по умолчанию — и вовсе форму квадрата), тогда как её хочется видеть пропорциональною размерам кадра? В таком случае почему бы вообще не отказаться от употребления параметра «-s» в пользу употребления видеофильтра «scale» (по адресу https://ffmpeg.org/ffmpeg-all.html#scale-1 разъясняемого) подобно тому, как это делает коммит https://bitbucket.org/Therapont/fbe-410/commits/0225b5f335cce9b51cd891f151e94963328685f6 внутри условия, занимающего строки со 103 по 107 в файле «inc/func/posts.php»?

Вопрос №5. Как так получилось, что в командной строке при вызове FFmpeg не используется ни параметр «-q 1», ни какое-нибудь другое средство контроля за качеством генерируемой миниатюры? Точно ли можно полагаться на настройки качества, используемые FFmpeg для JPEG по умолчанию?

>>20444
Вам, наверное, не понравятся мои ответы.
>1
Оно там потому что я углядел эти расширения тут в списке доступных к постингу типов. Если тут миниатюра не генерируется на xcf, то, конечно, нужен mediatype='misc'. Но svg прописан отдельным исключением в inc/classes/upload.class.php, строки 113-118 этого PR. Что делать с уже существующем прецедентом принятия таких файлов, решать не мне.
>2
Потому что я старался делать минимальные изменения, а значит не вводить новых типов в установку по-умолчанию. В любом случае, нужно б написать более полное ридми, что и зачем требуется при добавлении типов.
>3
Кажется, я просто скопировал это с моего патча для Ычана, а то было взято откуда-то ещё. Если я правильно читаю документацию -r, это может немноого помочь в случае, если кто-то поигрался с временем ключевых кадров.
>4
Потому что я не дочитал до доков по этому фильтру.
>5
Потому что дефолтное качество работает на моей машине. И, кажется, во всяких форках Вакабы.

Впрочем, я вполне могу поправить 4 и 5, скажем, завтра? Или вы можете отослать PR, который затем... и далее по списку.

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

>>20446
Вовсе нет, если для тебя xfc - это просто ещё один формат картинок, который должен быть скушан комбайном без всяких проблем.

У меня одного отвалилась капча?

>>20448
В общем, xcf таки не может быть скормлен комбайну. Ладно. Обновлю тогда через пару часов.

А капча отваливалась из-за таймаута.

Новая нить: >>20450