[WT] [Архив]  [Поиск] Главная Управление
[Совместно с Ычаном]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 20450)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, XCF, ZIP размером до 5000 кБ.
  • Ныне 3164 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
153385789892.png-(34.48KB, 500×500, 410.png)
20450
No. 20450 watch    
После публикации исходников мы можем обсуждать доработку не только ранее общедоступных частей интерфейса, но и движка в целом.

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

Предыдущая нить: >>17371
83 сообщений пропущено. Показаны 50 последних сообщений Развернуть все изображения
No. 20650    
>>20649
Вот, что думаю: а нельзя ли полностью всю статику в ИПФС перенести, поставив демона на сервере? Это же огромная экономия места получится.
No. 20654    
153728455986.png-(675.15KB, 1114×1600, Kanojo wa Rokurokubi screenshot 1.png)
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    
153734160124.png-(2.28MB, 1920×1040, Mononoke Hime.png)
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    
153734175396.png-(7.12KB, 200×200, 410chan-spoiler.png)
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    
153734374828.png-(101.51KB, 1459×657, сотона.png)
20666
>>20665

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

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

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

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

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

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

>>20716

Ага, теперь вроде чуть понятнее, как это могло получиться.
No. 20746    
153853785379.png-(10.04KB, 657×136, 1538537851663.png)
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    
153883907775.png-(52.41KB, 492×496, file_icons.png)
20768
>>20755
А как ипфс работает с тором, например?
Вообще, они там сейчас как раз над работай с файлами думают, чтоб были тумбинашки для каждого расширения, да и не только: http://metatorjq65tshfy.onion/meta/res/405.html#4180
No. 20771    
153900105491.png-(1.01MB, 1031×1470, Procell feeds on emotions (LN vol4 i11).png)
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    
153900494138.jpg-(42.35KB, 500×487, mission impossible.jpg)
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    
153919412877.png-(13.72KB, 929×120, .png)
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    
153944823978.mp3-(3.88MB, Housewife radio orig.mp3)
20801
Вчера просматривал старые треду, у звуковых файлов исчезла превьюшка. Собственно, тест, есть ли это и сейчас, или нет.
No. 20802    
153944878418.png-(5.51KB, 384×384, 1149378691928.png)
20802
>>20801
...а теперь,напомните мне, пожалуйста, я за последний месяц-полтора забыл: это в <a> неправильный аттрибут или с сервера картинка не пришла?

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

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

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

И да, >>20692, FBE с варнингами, но работает даже на 7.2.
No. 20809    
Картинка появилась, значит, ошибка устранена. Вот и славно.
No. 20810    
15394745863.png-(9.31KB, 384×384, 1149377096781.png)
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    
153953967266.jpg-(98.83KB, 600×338, 00000071.jpg)
20813
Вообще, я хочу напомнить, что реквестоту надо делать в public.
No. 20814    
>>20813
Я последовал Мицголу, но да. Больше не повторится.
No. 20815    
153956689351.mp4-(320.85KB, 1920×1080, Sword Art Online - unknown items.mp4)
20815
>>20814

В своё оправдание могу сообщить только то одно, что запросы на слияние с ветвью «master» стремился по возможности создавать только тогда, когда та опережала ветвь «public» и притом опережала в тех файлах, которые затронуты были запросом. Дѣлалъ это для того, чтобы merge conflicts избѣгнуть. И о том по адресу https://bitbucket.org/Therapont/fbe-410/pull-requests/27 объявил въ послѣднемъ абзацѣ.
No. 20818    
153964365053.mp4-(280.52KB, 1920×1080, Kono Subarashii Sekai ni Shukufuku wo! - Kazuma ev.mp4)
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    
153974153193.mp4-(86.95KB, 1920×1080, Himouto! Umaru-chan - zonama disappears.mp4)
20826
>>20822

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

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

На всякий случай сообщаю, что превьюшки показываются в собственном своём размере с самого начала. Что же касается видеопроигрывателя, то он может быть меньше размера кадра (фрейма), если кадр в полном размере не поместился бы в видимой области окна браузера. Такое уменьшение видеопроигрывателя порождено было осознанием того, что видеопроигрыватель (в отличие, скажем, от полноразмерного изображения) типичный зритель не пожелает прокручивать вверх и вниз, отдельно рассматривая верхнюю и нижнюю часть его — следовательно, не одна только максимальная ширина, но и максимальная высота видеопроигрывателя должна быть ограничена. Естественным ограничением для неё является высота видимой части страницы за вычетом высоты верхнего меню и ещё некоторого дополнительного пространства (чтобы не принуждать зрителя снайперски прицеливаться при прокрутке, со сверхчеловеческой точностью предугадывая будущее положение верхней кромки видеопроигрывателя, ожидающееся после развёртывания миниатюры первого кадра), размер которого для простоты сейчас также предполагается равным высоте верхнего меню (равной 32 пикселам в настоящее время).
No. 20844    
154010330851.png-(303.12KB, 1230×473, 29875823452345.png)
20844
Вы что-то сломали, кажется. И вот такое вылезло.
No. 20845    
154010357583.txt-(5.90KB, pageerrortext.txt)
20845
>>20844
После отправки картинки еще и такое.
No. 20849    
15401605792.jpg-(13.43KB, 330×300, 1150264319159.jpg)
20849
>>20845>>20844
Кот-то включил выдачу дебаг-информации. Первое было в FBE ещё до правок, array_push начал давать варнинг на undef начиная с PHP7.0.
No. 20857    
15403461199.png-(129.03KB, 1024×768, Clipboard01.png)
20857
>>20826
Я говорю, что старые куркулятуры разворачивают картинку на её полный размер, даже если он больше размера фрейма, в итоге появляется вертикальный скролл.
No. 20858    
>>20857
А неподдерживаемые производителями браузеры никто тут поддерживать и не собирался.
Удалить сообщение []
Пароль  
[Mod]