Dmitriy_2014

Dmitriy_2014
Рейтинг
370
Регистрация
01.07.2014
Интересы
Веб-технологии
vashfreelancer #:
Скорее всего, ошибка заключается в том что переменная  $query_str не определена выше.
Да скорее всего, даже больше скажу это была лишняя переменная, так бывает, когда копируешь код из примера, а потом только разбираешься что да как там, тем более ошибок с визуальной стороны никаких не было, все работало ОК, если только вот в логах веб-сервера оказывается было какое-то предупреждение даже не ошибка.
webinfo #:
Плагин кривой.
Да потому что это мой плагин.

Ну хоть ChatGPT мне ответил что-то :-) Ах-хах

Зачем нужен атрибут decoding=async для тега IMG?

Вероятно, у вас есть путаница в терминах. В HTML-теге <img> нет атрибута decoding=async. Вместо этого, есть атрибут decoding с возможными значениями: async, auto, или sync. Этот атрибут указывает браузеру, как обрабатывать изображения в момент загрузки.

async: Браузер может загружать и декодировать изображение асинхронно, не блокируя выполнение других задач на странице. Это может быть полезным для улучшения производительности, особенно на медленных сетях.

auto: Это значение по умолчанию. Браузер сам выбирает, загружать и декодировать изображение синхронно или асинхронно в зависимости от контекста.

sync: Изображение загружается и декодируется синхронно, блокируя выполнение других задач на странице до завершения операции.

Пример использования:

html

Copy code

<img src="example.jpg" decoding="async" alt="Example Image">

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

Почему WordPress поменял loading=lazy на decoding=async для картинок?

На момент окончания моего последнего обновления в январе 2022 года, в WordPress не было изменений в стандартных атрибутах loading или decoding для изображений. В том случае, если что-то изменилось после этой даты, я не обладаю этой информацией.

На тот момент использование атрибута loading="lazy" для изображений поддерживалось браузерами, чтобы реализовать отложенную загрузку изображений (lazy loading). Это помогает улучшить производительность веб-страниц, загружая изображения только тогда, когда они становятся видимыми для пользователя.

С другой стороны, атрибут decoding="async" применяется к тегу <img> и указывает браузеру на возможность асинхронного декодирования изображений. Это может быть полезным для оптимизации производительности, особенно при наличии множества изображений на странице.

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

Да, так кранты форумам будет, держитесь парни с Лимасола :-)
Можно ли использовать устаревшую версию веб-сервера NGINX из стандартного репозитория Ubuntu в плане безопасности?
Скажем так, вы бы использовали стандартную текущую версию из репозитория по умолчанию в Ubuntu server версии последней операционной системы или подключили бы Nginx репозиторий что бы обновить веб-сервер до последней версии?
Я примерно понимаю про подключение и обновление из репозитория Nginx на новую версию, но не будет ли проблем/конфликтов потом с ISPmanager’ом – панелью управления сервером, её настройкам по веб-серверам. И, наверное, разработчики ISPmanager’а тестируют его с базовой версией присутствующей по умолчанию в дистрибутиве, который они поддерживают, хотя это и не факт, это просто я так думаю.
sagamorr #:

Тоже везде использую XML Sitemap Generator for Google

А что именно криво?

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

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

На сайте https://yesviz.com нашел устройство ниже 230px – Часы Apple Watch Series 6 его вьюпорт 197px, правда сомневаюсь что с них смотрят сайты, хотя кто его знает.

Я так понял они вычисляют разрешение под viewport – просто делят разрешение устройства resolution на соотношение ratio, то есть на примере Apple iPhone SE – 750 / 2 = 375px vewport и уже вот эта цифра и есть та цифра, которая мне нужна.
webinfo #:

Это 360px.

Я померял линейкой экран, это где-то примерно 70 мм., конверторы говорят это 265px.

Ладно это все не важно :), вот что важно, Я когда в инструментах разработчика двигаю как бы это сказать, ну короче расширяю девтулс тем самым сжимая сайт и вверху циферки – там первая цифра это же ширина width, и когда делаю скажем до +/- 230px. Это же эта цифра подразумевается и под мобильными расширениями которые в метрике и в браузерах это об 320px по минимуму говорится.

Я тут глянул разрешение своего дешевого китайского смартфона, купленного за 6К когда-то, Tecno Spark 8c через AIDA64 и оно оказалось – 720 * 1612, то есть все новые модели точно меньше не будут уже никогда, да и у дешевого или б/ушного рынка я думают тоже навряд ли будут.

Да еще глянул статистику в Яндекс.Метрике по разрешениям экрана, и что бросается в глаза что меньше 320px вроде бы и нет, ну по крайне мерее на первом экране отчета, да и то их – 0,56%.

Но как не странно все-таки маленьких экранов тоже предостаточно, но не меньше 320:

Разрешения / проценты +/- :

360 – 10,8

393 – 10,3

412 – 3,69

414 – 2,4

375 – 1,91

390 – 1,85

384 – 1,24

Ну и так далее уже меньше одного 1 % процента…

Да вы правы, думаю об этом беспокоится не стоит мне.
Всего: 2005