Ычан: [d | au / b / bro / hr / l / m / mu / o / s / tran / tu / tv / vg / x | a / aa / c / fi / jp / rm / tan / to / vn]
[Назад] [Вся нить] [Первые 100 сообщений] [Последние 50 сообщений]
Ответ в нить [Последние 50 сообщений]
Имя
Animapcha image [@] [?]
Тема   ( ответ в 26066)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, WEBP, XCF, ZIP размером до 5120 кБ.
  • Ныне 3652 unique user posts. Посмотреть каталог
  • Предельное количество бампов нити: 500
410.png - (24.25KB, 500×500)
26066
No. 26066  
В сей нити мы упорядочиваем усилия по доработке местного движка.

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

Предыдущая нить: >>20450
140 сообщений пропущено. Показаны 50 последних сообщений
No. 27375  
>>27372
>чтобы горизонтальная прокрутка была только у провинившегося поста, а не у всей страницы
На контейнеры
overflow-x: hidden;
,
width/max-width: 100vw;
/
...: 100%; box-sizing: border-box;
. На сам пост
max-width: 100%; overflow-x: auto
.
No. 27378  
>>27375
Спасибо, похоже на правду, но идеально воспроизвести у меня не получается (остаётся небольшая горизонтальная прокрутка у всей страницы, а “overflow-x: hidden” это костыль). И ещё я не понимаю, про какие контейнеры ты говоришь. Можешь показать пример страницы, где такое сделано?

Ну и ждём вердикта Соуса.
No. 27379  
>>27372

> В этом и заключается надлежащее решение.

Что, дѣлать нечитаемыми URLы, в которых есть японские сѵмволы или кириллица? Ради чего? Чтобы что?
No. 27380  
google_and_cp1251_0xff.png - (63.47KB, 925×558)
27380
>>27379
Против urldecode в парсере разметки у меня есть три возражения:

(1) Эта функция попросту не предназначена для того, чтобы ей скармливали целый URL (а не некую подстроку URL). Она может исказить его (из URL с одним параметром запроса получится URL с двумя):
$ php -r 'printf("%s\n", urldecode("https://example.org/path?query=x%26y%3Dz"));'

https://example.org/path?query=x&y=z


(2) Вызов этой функции может привести к тому, что корректная с точки зрения стандарта ссылка не сможет быть запощена:
https://example.org/path?query=%FF
является корректной ссылкой, ибо нигде не сказано, что URL encoded-сегменты обязаны быть валидным UTF-8. Более того, и по сей день существуют серверы, которые принимают запросы в кодировках, отличных от UTF-8: например, поиск Google по адресу
https://www.google.com/search?q=%FF
у меня (ваш результат может отличаться) интерпретирует этот один байт 0xFF как букву «я» в кодировке cp1251 (скриншот прилагаю). А в результате декодирования получается невалидный UTF-8, который невозможно вставить в БД.

(3) Это браузер пользователя делает URLы читаемыми или же нечитаемыми: можно запостить
https://ru.wikipedia.org/wiki/Красота
, а можно и
https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B0%D1%81%D0%BE%D1%82%D0%B0
. Я всего лишь предлагаю отображать ссылки так, как их запостил пользователь. То, что ваш браузер вставляет «%D0%9A%D1%80%D0%B0%D1%81%D0%BE%D1%82%D0%B0» вместо «Красота» при копировании URL, так это особенность вашего браузера, которую, скорее всего, можно решить его настройкой.

На практике декодирование вызывает (вместе с принудительным разбиением на слова) проблему >>/d/3043, а также другую проблему. Если эти проблемы будут тем или иным образом решены, то вопрос о том, нужно ли декодировать, с моей точки зрения, не будет очень существенным. Просто оно для этого не предназначено.
No. 27381  
Хорошие контраргументы.

(Правда, если ими руководиться, то тогда опосля надо будет передѣлать парсер, насколько я понимаю — чтоб русские буквы принималися в URLы, а не означали конец URLов.)
No. 27382  
>>27381
> опосля надо будет передѣлать парсер
Это не так: и старое, и новое (предложенное yakui-lover в открытом PR) регулярное выражение считают кириллицу частью URL.
No. 27386  
Ну что же, открыл pull request, который реализует надлежащее (по моему мнению) декодирование URL.
No. 27391  
Насколько я понимаю, предположение >>27134 превратилось въ нынѣшнемъ мѣсяцѣ въ увѣренность: теперь 410чан дѣйствуетъ на новом PHP и притом ещё, кажется, на новой версии операционной системы.

Настаёт время вдругорядь возвратиться к содержимому сообщения >>27133 и разсмотрѣть его под таким углом: если сёрвер 410чана всё ещё не обзавёлся AVIF-понимающею версіею ImageMagick, то как там хотя бы с наличием поддержки AVIF в GD в PHP?

Собрали ли PHP с поддержкою AVIF?

Сразу скажу ещё, что вглядывание в содержимое трёхлѣтней давности коммита https://github.com/libgd/libgd/commit/f2aa2836ed910ca3510585a47a8a064b5140e148 в репе GD открывает в нём (а именно в коде файла src/gd_avif.c) ряд небезынтересных обстоятельств.

Во-первых, в коде GD жёстко прописана цвѣтовая субдискретизация для AVIF в том случае, когда желаемое качество изображения, измѣряемое баллами от 0 (минимальное качество) до 100 (максимальное качество), указано меньше 90. На мой личный взгляд это жестковато, я бы поставил 80 пороговым значением.

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

В-третьих, в коде libavif качество задаётся величиною так называемого квантователя: чѣмъ эта величина больше, тѣмъ качество хуже, а доходить она может до 63. Поэтому в коде GD предусмотрена формула для перевода значений качества (0…100) в значения квантователя (0…63).

Формула эта вот какова: из значения максимального качества (100 баллов) вычитается значение указанного качества, а результат умножается на частное отъ дѣленія максимальнаго квантователя (то есть 63) на максимальное качество (то есть 100), опосля чего округляется. В итоге должна получаться вот какая таблица соѿвѣтствія между баллами качества и величинами квантователей:

0 → 63
1 → 62
2 → 62
3 → 61
4 → 60
5 → 60
6 → 59
7 → 59
8 → 58
9 → 57
10 → 57
11 → 56
12 → 55
13 → 55
14 → 54
15 → 54
16 → 53
17 → 52
18 → 52
19 → 51
20 → 50
21 → 50
22 → 49
23 → 49
24 → 48
25 → 47
26 → 47
27 → 46
28 → 45
29 → 45
30 → 44
31 → 43
32 → 43
33 → 42
34 → 42
35 → 41
36 → 40
37 → 40
38 → 39
39 → 38
40 → 38
41 → 37
42 → 37
43 → 36
44 → 35
45 → 35
46 → 34
47 → 33
48 → 33
49 → 32
50 → 32
51 → 31
52 → 30
53 → 30
54 → 29
55 → 28
56 → 28
57 → 27
58 → 26
59 → 26
60 → 25
61 → 25
62 → 24
63 → 23
64 → 23
65 → 22
66 → 21
67 → 21
68 → 20
69 → 20
70 → 19
71 → 18
72 → 18
73 → 17
74 → 16
75 → 16
76 → 15
77 → 14
78 → 14
79 → 13
80 → 13
81 → 12
82 → 11
83 → 11
84 → 10
85 → 9
86 → 9
87 → 8
88 → 8
89 → 7
90 → 6
91 → 6
92 → 5
93 → 4
94 → 4
95 → 3
96 → 3
97 → 2
98 → 1
99 → 1
100 → 0

Впрочем, эта послѣдняя строка ея остаётся фактически недосягаемою ввиду вышеупомянутаго переключения в режим lossless.

Каждое из этих трёх обстоятельств остаётся и по сей день.
No. 27396  
Если в сообщении >>27391 правильно угадано положение дѣлъ (то есть если поддержка AVIF есть в GD в PHP, однако ея нѣтъ въ ImageMagick), то тогда оснащать FBE поддержкою AVIF придётся как-нибудь вот как:

① приподнять в файле inc/func/posts.php условие «elseif (KU_THUMBMETHOD == 'gd')» (и послѣдующія инструкціи GD-обработки изображений) до того уровня, на котором сейчас находится условие «elseif (KU_THUMBMETHOD == 'imagemagick')» (и послѣдующія инструкціи IM-обработки изображений), да притом ещё дополнить это условие «elseif (KU_THUMBMETHOD == 'gd')» до состояния «elseif (KU_THUMBMETHOD == 'gd' || $filetype == 'avif')» для того, чтобы оно всегда срабатывало насчёт файлов AVIF;

② в функции «gd_create_thumbnail» прибавить к вызовам «gif_gd_create» и «jpg_gd_create» и «png_gd_create» вызов функции «avif_gd_create» для файлов AVIF;

③ только что упомянутую функцию «avif_gd_create» сочинить по образцу функции «png_gd_create» как-нибудь вот как:

function avif_gd_create($source, $destination, $resize_x, $resize_y) {
   $avif = imagecreatefromavif($source);
   $thumbnail = gd_resize(
      $avif, $resize_x, $resize_y, $source, $destination, true, true
   );
   imageavif($thumbnail, $destination, 90, 3);
   imagedestroy($thumbnail);
   imagedestroy($avif);
   return true;
}

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

При этом в вызове функции «imageavif» я в явном виде прописываю качество 90, поскольку это позволит подавить субдискретизацию цвѣта.

Сразу скажу, что если миниатюры такого качества всё же окажутся неприемлемо крупными по объёму, то можно будет обсудить дальнѣйшее снижение качества. Но напомню, что 6 ноября 2020 года (при добавлении в FBE поддержки WebP) обнаружил, что миниатюры WebP с указуемым качеством 85 получаются по объёму меньше, чѣмъ миниатюры JPEG с указуемым качеством 80, а визуально — лучше. Поэтому тут жду примѣрно того же, только ещё +5 баллов.

Предупреждаю, что движок FBE при работе с ImageMagick (то есть въ послѣдніе годы) создаёт миниатюры JPEG с указуемым качеством 80 (и это сносно), но при работе с GD создаёт миниатюры JPEG с качеством по умолчанию, которое (как это по адресу https://www.php.net/manual/en/function.imagejpeg.php говорится) равно 75 — этакие миниатюры и сами собою не так хороши, и как отправная точка для сравнения с миниатюрами AVIF (совершаемого по объёму файла) не очень полезны, потому что могут побуждать похѣрить ещё и их качество ради экономии объёма файла.
No. 27397  
И так как в сообщении >>26066 сказано, что только администрация 410чана принимает рѣшенія, то предлагаю на ея разсмотрѣніе идею >>27396.
No. 27399  
Переход на ПХП8 состоялся, но всякие мелочи ещё остались, поэтому с рассмотрением новых функций и всякого такого пока притормозим.

Тут я описал некоторые известные проблемы:
https://codeberg.org/FBE410/fbe-410/issues/15#issuecomment-1655734

Рекомендую включить показ ошибок в ПХП (https://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors ).
No. 27401  
Предлагаю к теме «Futaba» крашеный скроллбар въ цвѣтахъ логотипа:

html { scrollbar-color: #1b7942 #fdffc7; }

Чтобы предпросмотрѣть, введите в отладочную консоль:

$('html').css('scrollbar-color', '#1b7942 #fdffc7')
No. 27402  
>>27401
Оно должно быть в цветах «Футабы», а не логотипа, никак с ней не сочетающихся. Отказано.
No. 27417  
Я считаю, что ни avif, ни webp, ни jxl не нужны. PNG, APNG, GIF и JPEG прекрасно справляются. А новомодные форматы лишь плодят фрагментацию, выбивают станые версии браузеров и вносят уязвимости в новые. Не так давно RCE в webp была. А что творится в AVIF и JXL — вообще мало кто знает. Лучше отключить, а неадекватными сайтами, сделавшими ставку на смузимусор — не пользоваться.
No. 27420  
Так как файл >>/a/19707 занимает ровнёшенько 5 мегабайтов (5 242 880 байтов), то можно быть совершенно увѣренными в том, что ограничение работает в формулировке «не больше 5120 килобайтов», а не «до 5120 килобайтов», как это сейчас сообщается.

Отсюда возникает предложение строку интерфейса привести к виду «не больше ░▓▒ килобайтов», чтобы она адекватно описывала собою дѣйствительность.
No. 27421  
>>27420
«До» не обязательно исключающее же.
No. 27422  
>>27421

В общем-то да, но тогда бы неплохо опосля килобайтов добавить (через пробѣлъ) слово «включительно», которого там по умолчанию нѣтъ.
No. 27436  
Сохраняющиеся после последнего обновления совместимости с ПХП8 проблемы:
https://codeberg.org/FBE410/fbe-410/issues/15#issuecomment-1807945
No. 27447  
NICE BOAT.7z - (59.77KB)
27447
>>27417

Если повторявшиеся много сотен раз обнаружения чудовищных уязвимостей движка Flash (по адресу https://en.wikipedia.org/wiki/Adobe_Flash_Player#Security и https://en.wikipedia.org/wiki/Adobe_Flash#Security упоминаемые) всё же ничуть не помѣшали существовать имиджбордам, поощрявшим употребление Flash (по адресу http://boards.swfchan.net/13147/ перечислявшимся шесть лѣтъ назад), то тѣмъ болѣе всего-навсего одна-единственная (пускай громадная) уязвимость декодировщика WebP, найденная болѣе чѣмъ за десятокъ лѣтъ его жизни, не должна отвратить нас собою от употребления этого формата со всеми его достоинствами (по адресу https://t.me/readMithgol/760 перечислявшимися), тѣмъ болѣе что исходный код декодировщика всегда открыт мириадам глаз, с недавних пор много болѣе внимательным и придирчивым.

Что творится в AVIF — не неизвѣстно, а очень хорошо извѣстно, потому что этот формат является нехитрою переупаковкою видеокадров AV1, употребляющихся с 2019 года (а не то и ранѣе) цѣлою кучею видеосайтов, начиная от крупнейших (Netflix, YouTube и проч.) и заканчивая краткими видеоцитатами на 410чанѣ. За это время всякая сколько-нибудь крупная уязвимость была бы обнаружена с высокою вѣроятностью. Для сравнения я напоминаю, что та крупная уязвимость в WebP, которой посвящён предшествующий абзац, обнаружена была не в обработчике той части формата, которая создана нехитрою переупаковкою видеокадров VP8, употреблявщихся с 2008 года (по лицензии On2) и с 2010 года (когда компания Google объявила неотзывный отказ от требования патентных отчислений) цѣлою кучею видеосайтов. Нѣтъ! — обнаружена она была в другой части формата, а именно в новинках WebP 2011 года, служащих для сохранения изображений без потерь, совершаемого по другому алгоритму, ужé никак на видеокодеке VP8 не основанному. Однако же в формате AVIF никаких таких невидеодополнений не существует, так что разрѣшеніе использовать AVIF — это всего только разрѣшеніе использовать видеокадры AV1 (которых и без того вдоволь на 410чанѣ) под другим заголовком. (Оборотной стороною желания неуклонно обходиться в AVIF без подобных невидеодополнений сдѣлалася малоэффективность такого сохранения изображений, которое совершается без потерь, так что в сравнении с AVIF формат WebP лучше подходит для такой задачи, когда и если пикселы не болѣе чѣмъ двадцатичетырёхбитны. Но это ужé не вопрос безопасности формата.)

Поддержка формата JPEG XL движком 410чана пока ещё не может служить предметом обсуждения, потому что формат этот поддерживается только браузерами Safari компании Apple, да и то не в полном объёме (без анимации). Господин Соусов долгие годы здѣсь воздерживался от дозволения таких форматов, которые браузерами Safari ещё не поддерживалися (несмотря на небольшую распространённость таковых браузеров) — слѣдовательно, ужъ тѣмъ болѣе рановатым должны быть признан всякий такой формат, который одними только браузерами Safari поддерживается покамѣстъ.

Чтобы нынѣшнее положеніе дѣлъ со сжатием изображений не осталося непроиллюстрированным, я прилагаю здѣсь небольшой архив (7-Zip) с тремя файлами, продолжающими собою челлендж 2021 года, по адресу https://410chan.org/b/arch/res/158687.html#158725 начатый — иными словами, прилагаю итог сжатия тутошнего мема «NICE BOAT» до величины чуть меньше 20 260 байтов. Один из файлов показывает итог сжатия в формате AVIF (при помощи libavif v1.0.4, то есть сáмой свѣжей релизной версии), два других — в формате JPEG XL, достигнутом двумя вариантами сжатия (модульным и VarDCT) сегодняшнею версиею кодировщика.
No. 27448  
jxl давно в Firefox поддерживается. Может не полностью, но поддерживатся. А на сжатие мема - я уже сказал, пофиг. Никакие несущественные прибавки в качестве или коэффициенте сжатия не не компенсируют слом совместимости.
No. 27449  
А на флеш плеер вообще пофиг, с 2009 года его не использую. Ну а кто хочет - может жрать.
No. 27450  
>>27448

> jxl давно в Firefox поддерживается. Может не полностью, но поддерживается.

Поддерживается-то поддерживается, но здѣсь необходимо сдѣлать как минимум два важных уточнения:

① только в nightly-сборках Файерфокса,

② и притом ещё только у таких пользователей, которые загодя заглянули на страницу «about:config» и вручную перекинули там переключатель «image.jxl.enabled» в значение «true».

То есть, можно сказать, почти ни у кого не поддерживается.
No. 27451  
110631548_p0.webp - (4.26MB, 3186×4096)
27451
>>27448
В случае с lossless JXL они там весьма существенные. -50% от PNG-шного размера анимешных картинок не редкость. Под -20% для JPEG-ов с возможностью реконструкции.
Исходник этой вот картинки 9 019 028 байт. Если дожать с zopflipng -m, то получится 6 234 680. А если воспользоваться cwebp, то оно без проблем и потерь пролезает в /b/ (4 461 710). Размер lossless JXL-ки с некоторыми параметрами: 3 360 511.
Существенно оно для мелкочанов с маленьким пределом на размер файла и для дешёвых VPSок. Ещё существенней для архивов.
No. 27452  
>>27451

Несомнѣнно.

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

https://410chan.org/b/arch/res/158687.html#159029
No. 27453  
Пока работа, видимо, в очередной раз встала, напомню, что у нас есть много всяких задач, заведённых от многих месяцев до многих лет назад: https://codeberg.org/FBE410/fbe-410/issues

Отдельно отмечу https://codeberg.org/FBE410/fbe-410/issues/11 — хотелось бы уже избавиться от избыточного фрейма по умолчанию.

Также до сих пор не завершена работа с переходом на ПХП8: https://codeberg.org/FBE410/fbe-410/issues/15

Любители пофлудить за форматы могли бы допилить поддержку ВЕБП уже, наконец: https://codeberg.org/FBE410/fbe-410/issues/9

Вопрос >>27068 также всё ещё актуален.
No. 27454  
112041438_p0.jpg - (1.17MB, 1388×1636)
27454
>>27453
> issues/9
Погляжу на выходных и, скорее всего, кину исправления в тред. Не даёт codeberg по throw-away'ке регаться.
> issues/11
Если нужно, чтоб по https://410chan.org/ показывалось news.php, то достаточно в .htacess поменять DirectoryIndex с kusaba.php на news.php.
No. 27455  
webp.webp - (48.82KB, 2106×1051)
27455
Таки поглядел прямо сейчас, там всё просто.
В строке 4372 у inc/classes/manage.class.php, в if со списком форматов добавить сравнение $line['filetype'] == 'webp'.
No. 27457  
101528376_p0_sample.webp - (4.97MB, 3686×5898)
27457
> issues/15
На выходных тогда посмотрю, много ли там работы по устранению deprecated-ов.

> Вопрос >>27068 также всё ещё актуален.
Думаю, можно попробовать спросить у по https://bulochka.org/b/. Есть подозрение, что автор скриптов нынче где-то там. Ну, или на Ичане. Или в /b/.
Но если добавлять, не лучше ли в суперскрипт вместо количества постов ставить какую-нибудь ✿-пометку, если новые посты есть? Иначе ведь действительно ширина менюшки скакать будет.
No. 27458  
>>27454
Если движок штатными средствами назначает главной kusaba.php, то он штатными средствами должен назначать news.php. Кому-то следует изучить этот вопрос.
Тем более, что в задаче требуется оставить рабочие опции с использованием фрейма для его фанатов.

>>27455
Ок, попробую добавить.

>>27457
Я не буду кого-то искать неизвестно где. Разве что в /b/ напишу, наверное. Если человек сюда не ходит, ему оно вряд ли интересно. Если автора нет, то кто-то ещё мог бы предложить свою реализацию.
>Иначе ведь действительно ширина менюшки скакать будет.
Да вроде у нас и меню не такое большое, и числа, чтобы это критично было. Вот для мобилок можно было бы альтернативную индикацию попробовать сделать.
No. 27461  
Вослѣдъ >>27455 хорошо бы туда же добавить «'avif'» — так сказать, «на вырост».
No. 27463  
Super Katawa Shoujo - Kenji.webp - (10.14KB, 640×480)
27463
За год и ещё за три недѣли, со дня вопроса >>27068 прошедших, никто не откликнулся.

Руководясь этим, предлагаю впредь предполагать, что вообще никто не сохранил этот скрипт — и что было это оттого только, что у того скрипта было мало и недостаточно пользователей. Спрос был невелик и не пережил груза лѣтъ.

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

Навскидку малопрояснёнными выглядят вот эти четыре самых начальных группы вопросов:

① Должен ли это быть юзерскрипт (для ViolentMonkey или аналогичнаго расширения во браузере)? — или же это должен быть сайтовый скрипт (часть движка FBE)?

② Как часто он должен стучаться на сайт, не заставляя опасаться того, что пара-тройка-другая десятков пользователей скрипта, одновременно эдак стучась, перегрузит сайт собою? (Раз в минуту? Нѣсколько раз в минуту? Один раз въ нѣсколько минут?)

③ Должен ли этот скрипт скачивать и сканировать заглавную страницу каждаго раздѣла в поисках номеров сообщений, превосходящих запомненный номер? — или же можно нифигушеньки не сканировать, а использовать какой-нибудь готовый API, нарочно для этой цѣли в движке FBE заготовленный?

④ Достаточно ли (как это предложил нам автор сообщения >>27457) ограничиваться демонстрациею однобитного флага «есть новыя сообщенія», или всё же необходимо их количество? Если их количество необходимо, то достаточно ли руководиться разностью между номером свѣжайшаго сообщенія, существующего въ подраздѣлѣ, и номером ранѣе запомненнаго сообщенія, пользователем прочитаннаго при заходе въ подраздѣлъ? — или же этого одного не достаточно, а скрипт должен нѣкоторымъ способомъ провѣрить промежуточныя сообщения на стёртость, чтобы при необходимости уменьшить показываемую разность на ту величину, которая равна количеству стёртых сообщений? (А для той провѣрки в FBE есть ли API чуть лучше, чѣмъ обращение по AJAX на адрес «ku_boardspath + '/expand.php'» для получения текста каждого сообщения?)
No. 27464  
Кстати вот ещё:

⑤ Должен ли счётчик непрочитанных сообщений обнуляться в тот момент, когда пользователь навѣстилъ подраздѣлъ? — или всё же неплохо бы https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API задѣйствовать для того, чтобы новое сообщение считалося прочитанным тогда только, когда оно реально вплывает в видимую часть окна браузера, причём не началом, а концом своим? — да не стóит ли дополнительно навѣсить таймер и смотрѣть, долго ли новое сообщение остаётся в области видимости, чтобы исключить ложныя срабатыванія во время быстрой прокрутки страницы?
No. 27465  
109929796_p0.webp - (2.67MB, 1000×1778)
27465
>>27463
>>27464
① Судя по всему, речь о внесении изменениний в FBE;
② Пока вполне можно захардкодить проверку раз в 5 минут и не париться. Доски у нас не очень быстрые. Потом можно вынести это дело в config.php или на страницу управления. Ещё можно запилить динамический интервал, с умножением его по каждой проверке на какой-то коэффицент до достижения потолка: сначала проверяется через 1 минуту, через n не обнаруживших изменения проверок - раз в 5 минут;
③ Вроде там никакого API для этого нет. Вместо скачивания нулевой можно скачивать https://410chan.org/b/rss.xml. Но проще по-быстрому PHPшку написать, которая select max(id) from posts_(?) будет отдавать;
④ Судя по всему, не достаточно. Можно отдавать разницу меж максимальным ID и текущим записанным в печеньки/local storage. Вряд ли уж сильно критично, если количество новых постов получаемое таким образом иногда будет не очень точным. Чтобы сильно ссылки на борды не скакали, когда разница та больше 9, можно вместо +9 отображать +∞ или >9;
⑤ Пока в качестве MVP запилить что попроще, а космолёт потом строить, если надо будет.
Таковы мои мысли по этому поводу.
No. 27466  
htaccess_update.webp - (54.89KB, 2365×816)
27466
>>27458
.htaccess, который в KU_ROOTDIR, кусабовскими скриптами, кроме как для добавляния забаненных IP, не меняется. То бишь, этот Apache'шный конфиг до метки "## !KU_BANS:" совершенно статичен и единственное место, где настраивается файл главной.

По замене DirectoryIndex-а в .htaccess скрипт https://410chan.org/kusaba.php будет продолжать работать, можно сделать симлинк f.php, чтобы фанатам было нетрудно набирать. Нужно будет также убрать target="_top" из <a>'шки-домика, иначе по клику на домик во фрейм-контексте человека вернёт на https://410chan.org без фрейма.
No. 27467  
removeframes.webp - (16.96KB, 1916×239)
27467
> Заодно стоит починить скриптовую функцию “Убрать фреймы” во фрейме, которая, кажется, сломана.
Функция эта в текущем варианте меняет ссылки на доски во фреймовом меню так, что при клике на них человек перейдёт на страницу без фреймов. То бишь, «Фреймы убраны» — это про то, что они убраны из ссылок на доски, а не из поля зрения.
No. 27469  
главная.webp - (132.09KB, 2553×939)
27469
Вообще, есть такая идея, как поступить с фреймами.

Само по себе меню со списком разделов слева и news.php в центре выглядит отнюдь не плохо, как дизайн главной. Куда лучше уродливой ичанской главной, например. Может, сделать, чтобы по переходе на доску из фреймового меню переход убирал фреймы по умолчанию, аналогично поступив с ссылками, приведёнными в news.php? И тогда поменять опцию “Убирать фреймы” на “Оставить фреймы”.
No. 27470  
>>27464
Ещё, может быть, надо учесть кейс с несколькими открытыми вкладками и долгоживущими вкладками.
Как ведут себя значения в localStorage читаемые и записываемые из нескольких вкладок. Не придется ли тут синхронизацию какую городить через postMessage.
No. 27471  
>>27465
На самом деле, нам действительно не помешало бы АПИ или что-то такое, дабы оптимизировать работу скриптов и запилить вещи типа https://codeberg.org/FBE410/fbe-410/issues/6
Просто я в этом ничего не понимаю. Надо, чтобы кто-то проанализировал существующие реализации. Я могу только задачу на трекере завести официальную, лол.

>>27469
Этот десигн ничем не лучше ычановского. И вообще пока висит как заглушка, потому что новости не используются из-за https://codeberg.org/FBE410/fbe-410/issues/14
Список досок на главной надо будет сделать, но это уже следующая фаза. И опять же его надо будет делать относительно новостей.
No. 27472  
1542829893169.jpg - (23.38KB, 347×402)
27472
Deprecated: Optional parameter $thread_id declared before required parameter $time is implicitly treated as a required parameter in lib/search.php on line 43
> lib/search.php 43: function create_search_record($post_id, $thread_id = 0, $board, $message, $time)
Вроде используется оно только в board.php и только в одном месте, где при вызове $thread_id указан.
> board.php 553: create_search_record($post_id, $thread_replyto, $post['board'], $raw_message, $time);
Поэтому значение по умолчанию для $thread_id из объявления функции в search.php можно спокойно убрать.

Deprecated: Optional parameter declared before required parameter $note is implicitly treated as a required parameter in inc/classes/bans.class.php on line 84
> inc/classes/bans.class.php 84: function BanUser($ip, $modname, $globalban, $duration, $boards, $reason, $appealat=0, $type=0, $allowread=1, $note)
Везде, где оно используется, аргументы для параметров, у которых значения по умолчанию, передаются явно.
Можно смело убирать присваивания, но после того, как будет указан недостающий $note аргумент тут
> inc/classes/manage.class.php
> 2999: $bans_class->BanUser($ban_ip, mysqli_real_escape_string($tc_db->link, $_SESSION['manageusername']), $ban_globalban, 0, $ban_boards, mysqli_real_escape_string($tc_db->link, $_POST['reason']), 0, 0, 1);
И тут
> board.php
> inc/classes/posting.class.php
> 235: $bans_class->BanUser($_SERVER['REMOTE_ADDR'], 'SERVER', '1', $results[0]['bantime'], '', 'Posting a banned file.<br>' . $results[0]['description'], 0, 0, 1);

Там местами по коду, когда $note брать неоткуда, в качестве $note пихается то, что запихано в $reason, так что указанные строки можно по аналогии поменять на
> $bans_class->BanUser($ban_ip, mysqli_real_escape_string($tc_db->link, $_SESSION['manageusername']), $ban_globalban, 0, $ban_boards, mysqli_real_escape_string($tc_db->link, $_POST['reason']), 0, 0, 1, mysqli_real_escape_string($tc_db->link, $_POST['reason']));
И
> $bans_class->BanUser($_SERVER['REMOTE_ADDR'], 'SERVER', '1', $results[0]['bantime'], '', 'Posting a banned file.<br>' . $results[0]['description'], 0, 0, 1, 'Posting a banned file.<br>' . $results[0]['description']);
Соответственно. Но можно и тупо пустую строку '' запихать.

Сделать это, убрать дефолтные значения для параметров, и deprecated-ы на странице входа в management оно не пишет. Warning-а при переходе на страницу управления банами, кажется, нет. Может, из-за этих изменений.

Also, там по вызовам то стоит mysqli_real_escape_string, то не стоит. Поди разберись, где оно надо, а где надо.
No. 27474  
phpstan.webp - (49.47KB, 2324×1306)
27474
phpstan говорит, что с FBE проблем немножко больше, чем может показаться на первый взгляд. Надо будет поглядеть, на что именно статический анализатор ругается, и пофиксить то, где он ругается не зря.
No. 27477  
board-post_class.webp - (47.12KB, 1945×871)
27477
>>27471
> https://codeberg.org/FBE410/fbe-410/issues/6
> полностью пустое сообщение, к ОП-посту не приложен файл, слишком длинный текст, слишком большой или кривой файл, не введена капча и т.д.
Кривой файл или нет, это пусть проверяет сервер, наверное. Разве что проверять, соответсвтует ли заголовок файла его расширению для некоторых форматов во избежание >>26890-ситуации.
А так, по перечисленному, информация для проверки на стороне клиента вроде вся, кроме максимальной длины текста, есть. Только её вывод в board-post.class.php и добавить рядом с MAX_FILE_SIZE. Что-то радикально новое со стороны сервера тут не нужно.

> Этот десигн ничем не лучше ычановского.
Ещё скажи, что хуже, лол.
No. 27478  
1495319689399.jpg - (39.99KB, 496×375)
27478
>>27477
>Ещё скажи, что хуже, лол.
Я скажу, что тут просто никакого десигна нет. И при появлении блока новостей оно будет вообще выглядеть почти аналогично.
На «Ычане» только надпись надо выравнять, вместо неё картинки были раньше.
No. 27479  
uguu.jpg - (141.55KB, 1280×720)
27479
>>27478
> И при появлении блока новостей оно будет вообще выглядеть почти аналогично.
Ugh. Значит, лучше не приступать.
No. 27480  
>>27479
Можно просто на главную не ходить, если какие-то психологические проблемы. На неё и так никто не ходит, кроме жертв фрейма.
No. 27481  
113599466_p0.webp - (2.25MB, 3508×2480)
27481
>>27480
Сомневаюсь я, что, например, вот этот >>/ci/1605 вот постер набрал https://410chan.org/ci, а не перешёл туда с главной.
Пусть наша приветственная страница выглядит хорошо.
No. 27482  
117002670_p0.jpg - (712.55KB, 1000×1386)
27482
> color: #800000;
> font-weight: bold;
Так и задумано? Или postername-стиль в umnochan.css по ошибке поменялся?
Предыдущие значения были:
color: #310000;

font-family: sans-serif;

No. 27483  
>>27482
Да, теперь во всех стилях имя оформлено одинаково.
No. 27485  
>>27477

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

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

Сперва получаем список файлов (а поскольку параметра «multiple» у тега нѣтъ, то там либо один файл, либо ни одного):

const flist = $('[name=imagefile]')[0].files;

if( flist.length < 1 ) return;

Там может быть «[1]», если обрабатывается плавающая формочка быстраго ѿвѣта.

Затѣмъ надо достать ArrayBuffer оттудова, причём процесс это асинхронный:

const freader = new FileReader();
freader.onload = function(evt){
   const fBuffer = evt.target.result;
};
freader.readAsArrayBuffer(flist[0]);

Внутри обработчика события onload мы можем вызывать буферу провѣрку на заголовок графического файла как-нибудь так (в хронологическом порядке форматов):

function whatImageFile( fileBuffer ){
   const view = new DataView(fileBuffer);

   if(
      view.getUint32(0) === 0x47494638
   ) return 'GIF';

   if(
      view.getUint16(0) === 0xFFD8
   ) return 'JPEG';

   if(
      view.getUint32(0) === 0x89504E47 &&
      view.getUint32(4) === 0x0D0A1A0A
   ) return 'PNG';

   if(
      view.getUint32(0) === 0x52494646 &&
      view.getUint32(8) === 0x57454250
   ) return 'WebP';

   if( view.getUint32(4) === 0x66747970 && (
      view.getUint32(8) === 0x61766966 ||
      view.getUint32(8) === 0x6176696F ||
      view.getUint32(8) === 0x61766973
   )) return 'AVIF';

   return false;
}
No. 27486  
У нас здѣсь на имиджборде всё так устроено (и мы так привыкли), что сообщение никак нельзя редактировать опосля отправки.

Но в результате получается примѣрно так (и нерѣдко), что поставлена гиперссылка, на https://410chan.org/b/res/156266.html#156266 ведущая (этот примѣръ в сообщении >>/b/194168 взят), а нифигушеньки не работает, потому что тема обсуждения ужé оказалася заархивированною и оттого по адресу https://410chan.org/b/arch/res/156266.html располагается.

Нешто трудно, пусть и не редактируя давния сообщения, «на лету» (во время обращения по ссылке) прибавлять HTTP-перенаправление (на arch/ перебрасывающее браузер читателя) в таких случаях, когда обсуждения нѣтъ, но архив его зато есть?
No. 27487  
>>27486
Это никак не относится к работе движка.
Удалить сообщение []
Пароль  
[Mod]