Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нём некорректно. Вам необходимо обновить браузер или попробовать использовать другой.
XenForo 2.3: Оптимизация изображений, улучшенное изменение размера изображений и многое другое!
Мы надеемся, что вам понравился выпуск «Вы видели...?» серия для XenForo 2.3. Нам еще есть что вам показать, пока мы работаем над добавлением последних штрихов перед выпуском XenForo 2.3 на этом самом форуме.
На этой неделе мы поговорим о различных улучшениях, которые мы внесли, и которые в основном касаются изображений.
Ознакомьтесь с указателем ниже, чтобы перейти к конкретному сообщению:
На этой неделе это все, продолжим на следующей неделе! На следующей неделе мы сосредоточимся только на одной новой функции, это потрясающе, и мы рады еще больше вовлечь вас в захватывающий мир XenForo 2.3.
Возможно, мы могли бы поговорить об этом в нашей статье о повышении производительности, но на тот момент она была еще не совсем готова к показу. (Я начал работать над этим на этой неделе и еще не овладел искусством путешествия во времени).
Первоначально объем нашей поддержки WebP в XenForo 2.3 заключался в том, чтобы просто позволить пользователям загружать файлы WebP и корректно отображать их в строке. Это само по себе было бы положительным изменением, поскольку формат становится более распространенным в сети, но сам по себе он мало что дает для решения проблемы использования диска, что, конечно, также оказывает положительное влияние на производительность.
Но этого было недостаточно.
Если вы хотите автоматически оптимизировать все будущие загрузки изображений, вам просто нужно включить эту опцию.
При загрузке все поддерживаемые в настоящее время типы изображений (кроме GIF) будут сохранены в формате WebP. Примечание : как и сейчас, миниатюры, баннеры профилей и аватары (и все остальное, что имеет программно установленное имя файла) будут обслуживаться с расширением .jpg, независимо от основного формата файла.
Если у вас есть пользовательские типы контента, которые уже используют систему вложений, например, в Медиа-галерее и Менеджере ресурсов, изображения, загруженные в них, также будут автоматически оптимизированы.
Фактически, если ваше дополнение обрабатывает загрузку с использованием подхода по умолчанию, а именно XF\Http\Uploadclass, все новые загружаемые изображения будут оптимизированы автоматически. Это распространяется практически на все имеющиеся у нас системы, включая систему загрузки ресурсов администратора.
Как разработчик, если вы хотите по какой-либо причине отказаться от такого поведения, вы можете сделать это с помощью следующей строки:
PHP:
$upload->setImageOptimize(false);
Это касается будущих загрузок, но многим из вас будет интересно, как оптимизировать существующие файлы. Поэтому вам будет приятно узнать, что вы можете автоматически восстановить все существующие вложения, аватары и баннеры профиля.
Это несколько типичные перестройки, которые вы можете запустить из панели управления администратора на странице «Восстановление кешей».
Поскольку это довольно интенсивный и длительный процесс, если вы предпочитаете запускать его без риска тайм-аутов и контроля браузера, вы также можете использовать одну из встроенных команд:
Разработчику легко добавить поддержку собственных типов контента, расширив класс AbstractImageOptimizationJob.
Мы уже запускали это на разрабатываемой версии форума сообщества XenForo. При этом размер файла, указанный в xf_attachment_data таблице , до преобразования составлял около 40 ГБ. Размер файла, указанный после преобразования, составляет около 19 ГБ.
Это существенная экономия, которая также окажет положительное влияние на производительность.
«Не очень хорошая» новость
WebP теперь поддерживается всеми основными браузерами. Любой, кто использует современный браузер, не столкнется с проблемами при просмотре изображений. Однако некоторые устройства и браузеры Apple, выпущенные до сентября 2020 года, не поддерживают WebP.
В частности, если вы используете iOS 14 или более позднюю версию, проблем вообще нет. Safari 14 и более поздние версии тоже хороши, но для отображения изображений WebP у вас должна быть установлена как минимум macOS 11 Big Sur.
В более ранних браузерах эти пользователи просто не видели изображений WebP вообще. Они будут выглядеть как разбитые изображения.
С течением времени эта проблема, естественно, становится все менее серьезной, поскольку люди обновляют свое программное и аппаратное обеспечение. Но об этом вам следует знать и подумать, прежде чем полностью конвертировать все изображения в WebP.
В эпоху камер, которые помещаются в наши карманы и создают фотографии с постоянно растущим числом мегапикселей, я уверен, что вы могли столкнуться с ситуацией, когда XenForo жалуется, что фотография слишком велика. Либо из-за ограничений на размер файла, либо из-за ограничений, которые мы налагаем на размер изображений, размер которых мы разрешаем изменять вашему серверу.
В последнем случае ограничение по умолчанию устанавливается для изображений, содержащих не более 20 миллионов пикселей. И хотя его можно увеличить, установив собственное значение в src/config.php, этот предел был установлен более десяти лет назад, и даже самый дешевый виртуальный хостинг не взорвется, как дом, в который ударила молния, просто чтобы справиться с изменением размера. большого изображения.
Однако мы увеличили этот предел в XF 2.3 по умолчанию следующим образом:
PHP:
$config['maxImageResizePixelCount'] = 48000000;
Если вам нужен меньший (или больший) лимит, это можно сделать, добавив указанное выше значение в src/config.php файл и соответствующим образом изменив значение.
Оставив в стороне этот очень незначительный момент, позвольте мне объяснить вам, почему он имеет гораздо меньшее значение.
Начиная с XenForo 2.3, «менеджер вложений», который обеспечивает работу системы загрузки файлов для таких вещей, как ресурсы, медиа-галерея и другие вложения, теперь может изменять размер изображений до того, как они достигнут вашего сервера.
Если у вас установлены максимальные размеры ширины/высоты, XF уже изменит их размеры на стороне сервера, но в версии 2.3 мы сначала попытаемся изменить их размеры на стороне клиента.
У меня есть образец фотографии размером 14 026 x 14 026.пикселей в ширину (это почти 200 мегапикселей!). В XF 2.2, если бы я загрузил это, я, скорее всего, получил бы сообщение об ошибке, сообщающее, что файл слишком велик для загрузки. Я мог бы изменить вышеупомянутое значение конфигурации, но очевидно, что ваши пользователи не могут этого сделать. В XF 2.3 размер файла полностью изменяется на стороне клиента с помощью API JavaScript перед загрузкой на сервер.
Поскольку изменение размера изображения эффективно уничтожает любые встроенные метаданные, такие как данные EXIF, мы также представили новую стороннюю библиотеку, которая может при необходимости захватывать данные EXIF перед изменением размера. Для XenForo Media Gallery крайне важно гарантировать, что мы сможем отображать данные EXIF в галерее даже для изображения, размер которого был изменен.
Больше никаких досадных ошибок для ваших пользователей, а благодаря возможностям большинства современных устройств все происходит довольно быстро, и в целом загрузка занимает меньше времени, чем обычно, поскольку файл, передаваемый на сервер, меньше по размеру.
Эта новая функция немного более разнообразна, чем некоторые другие, хотя она включает в себя изображения, я думаю, что-то вроде...?
Я думаю, что большинство из вас упустили подсказку в первом посте @@Kier о 2.3 HYS:
Если вы пропустили это, вас можно простить за то, что вы, возможно, подумали, что Кир просто загрузил emojis в стиле Apple для своих изображений реакции, но на самом деле это не так.
Начиная с XF 2.3, теперь вы можете добавлять собственные смайлы и реакции, просто указав, какие смайлы вы хотели бы использовать.
Вы можете найти смайлик, который хотите использовать, начав вводить короткий код смайлика или даже просто используя клавиатуру смайлика на своем устройстве, чтобы напрямую ввести нужный смайлик:
Вы заметите, что по-прежнему доступны варианты загрузки собственного изображения или даже использования спрайта, но реакции по умолчанию (включая ранее созданную реакцию «палец вверх») теперь вместо этого извлекаются из смайлов.
Это означает, что реакции и смайлы с использованием эмодзи теперь также будут соответствовать параметру emojiStyle, который обычно влияет на контент публикации. Основная подсказка в посте @@Kier о HYS заключается в том, что у него включены собственные смайлы устройства, поэтому они отображаются в стиле Apple. По умолчанию мы по-прежнему используем JoyPixels, но приятно знать, что доступен выбор стилей.
Примечание : люди все еще используют Twemoji? Как мы вообще это сейчас называем? Ксемодзи? Кмодзи? Маскмоджи? модзи?
Смайлы работают точно так же. Конечно, для некоторых это менее полезно, поскольку мы предоставляем средство выбора смайлов и в любом случае поддерживаем смайлы при создании контента.
Но если вы предпочитаете отключить средство выбора emojis в средстве выбора редактора и хотите отображать только смайлы, вы можете, по крайней мере, теперь сопоставить определенные emojis, которые вы хотите предложить, со смайлами, таким образом отображая меньшее подмножество доступных emojis для использования.
Варианты размеров для загрузки ресурсов администратора
Эта функция является скорее инструментом разработки, но она связана с изображениями, поэтому подходит сюда. Эта функция в первую очередь была написана для использования в новом стиле, но до того, как было решено, что мы должны отложить это до версии 3.0.
Возможно, вы знакомы с системой загрузки ресурсов, которую мы добавили в XenForo 2.2, которая позволяет загружать определенные плагины непосредственно в панели управления администратора, не запуская программу (S)FTP.
Вы уже можете использовать это в XenForo для загрузки изображений реакций, изображений смайлов и свойств стиля для таких вещей, как логотипы.
Начиная с XenForo 2.3, эта функция может использоваться разработчиками для автоматического создания различных вариантов размера для загруженного ресурса.
Первый шаг — использовать AssetVariantTrait в вашей сущности, у которой есть один обязательный метод для реализации:
PHP:
public function getAssetVariantSizeMap(): array
{
return [
'image_url' => [
's' => 128,
'm' => [512, 456]
]
];
}
Это должно вернуть массив с ключом по имени поля, которое содержит URL-адрес загруженного актива. Затем внутренний массив кодируется кодом размера, чтобы представить размер варианта. Если значение кода размера является целым числом, размер этого варианта будет изменен на квадрат. Если указан массив, первый элемент массива — это ширина, а второй элемент массива — высота.
В приведенном выше примере будут созданы следующие файлы:
data/assets/your_asset_name/your_file.png- исходный загруженный файл в полном размере
data/assets/your_asset_name/your_file - s.png- размер ресурса изменен до квадрата размером 128 пикселей.
data/assets/your_asset_name/your_file - m.png- размер ресурса изменен и обрезан до 512 x 456 пикселей.
Мы также представили новую функцию Templater asset_display, которую можно использовать следующим образом:
Что-то, что можно было бы упомянуть в нашем HYS «Повышение производительности» , если бы кто-то (я) не забыл об этом, на этой неделе мы также публикуем новости об улучшениях, которые должны уменьшить совокупное смещение макета (CLS) для изображений с горячими ссылками в контенте.
В настоящее время, если вы встраиваете изображение по URL-адресу, у нас нет предварительной информации о размерах или соотношении сторон этого изображения. Насколько браузер знает, размер изображения составляет 0 x 0 пикселей, и когда оно начинает загружаться, для него не резервируется место на экране, поэтому макет страницы смещается по мере ее загрузки.
Это оказывает негативное влияние не только на показатели производительности, но и на общее впечатление пользователя, поскольку все начинает прыгать по экрану.
Теперь мы будем отслеживать эти размеры в предела хembed_metadata поле контента и в определенной степени может перестроить эту информацию, когда перестроение «Post embed metadata» запускается для существующего контента (если размеры были сохранены прокси-сервером изображения).
Как по мне на тему Webp не самое разумное решение преобразовывать прям все на него, но с точки зрения оптимизации и уменьшения объёмов вложений имеет смысл. До чего же не нравится мне этот Webp, но к сожалению навязывают...
Webp очень современная и хорошая технология.
Не понятно чем он может не нравится.
То что некоторые бразуеры его не поддерживают? Их уже единицы.
А для остальных, я надеюсь, можно будет сделать конвертацию в реалтайме.
В любом случае можно будет сделать костыль на стороне веб-сервера (с помощью тех же lua в nginx/openresty)
Скорей больше претензия к программам просмотра, даже базовые от винды его открывают через браузер, что не очень удобно и для удобства приходится доставлять актуальные менеджеры для просмотра. В остальном то особо нареканий нет к формату, он сжимает лучше. Правда есть вопросы к конвертации на этот формат. Взять тот же сайт nexusmods, у них она порой криво работает, что некоторые загруженные изначально jpg и png он конвертирует в webp и при загрузке картинки получаются битыми, что для загрузки в иные источники вызывает проблемы. Хотя открываются как ни в чём не бывало, что даже банальный paint может их не загрузить для правки. Неприятный мой случай, но возможно он единичный только с ними был. Больше с ним напрягает изначально это ограниченная его поддержка на разных платформах. С браузерами может и нет проблем, но в других областях ещё пока есть. Этим пока и отталкивает формат, но это скорей уже придирка. Я на своём XF давно реализовал поддержку загрузки webp, но это больше костыль. Приятно знать, что к новой версии появится официальная поддержка, правда хрен купишь продление лицензии...
модзи?
