Kamaсегодня2 EN

Релиз WordPress 7.1

Релиз WordPress 7.1 запланирован на 19 августа 2026 года. В этой версии более 310 изменений в ядре, свыше 180 исправлений ошибок и почти 600 улучшений из Gutenberg.

Релиз состоялся по плану 19 августа 2026 года и получил кодовое имя «Mary Lou» в честь джазовой пианистки и композитора Мэри Лу Уильямс.

Среди наиболее важных изменений:

  • появились адаптивные стили и состояния блоков.
  • редактор записей теперь всегда работает внутри iframe.
  • изображения могут обрабатываться в браузере.
  • панель инструментов (админ-бар) стала постоянной.
  • появился публичный SVG Icon API.
  • Abilities API получил новые возможности.

Ниже разберём, как всё это работает.

Оглавление:

Адаптивные стили блоков

Главное визуальное изменение WordPress 7.1 - встроенное редактирование стилей для разных размеров экрана. Раньше адаптивные различия приходилось описывать вручную через медиазапросы или реализовывать собственный интерфейс в блоке. Теперь стили для планшета и телефона можно задать:

  • в глобальных стилях для определённого типа блока;
  • в настройках отдельного экземпляра блока;
  • непосредственно в theme.json темы.

Редактор позволяет включить режим «Адаптивные стили», выбрать планшет или телефон и увидеть результат в соответствующем размере области просмотра. Поддержка распространяется на блоки и вариации стилей блоков, которые используют стандартные Block Supports: типографику, цвет, фон, границы, размеры, отступы и настройки раскладки.

Обычный стиль блока остаётся базовым и действует при любой ширине. Значения для планшета и телефона переопределяют только указанные свойства. Отдельного состояния @desktop нет.

Адаптивные стили в theme.json

Для мобильных и планшетных значений используются ключи @mobile и @tablet:

{
	"version": 3,
	"styles": {
		"blocks": {
			"core/group": {
				"spacing": {
					"padding": {
						"top": "3rem",
						"right": "3rem",
						"bottom": "3rem",
						"left": "3rem"
					}
				},
				"@mobile": {
					"spacing": {
						"padding": {
							"top": "1rem",
							"right": "1rem",
							"bottom": "1rem",
							"left": "1rem"
						}
					}
				}
			}
		}
	}
}

В этом примере группа получает отступы 3rem по умолчанию и 1rem на мобильном экране. Если в @mobile не указано какое-либо свойство, продолжает применяться его базовое значение.

В разметке отдельного блока адаптивные значения сохраняются в существующем атрибуте style:

<!-- wp:paragraph {"style":{"@mobile":{"typography":{"fontSize":"1rem"}}}} -->
<p>Текст с адаптивным размером шрифта.</p>
<!-- /wp:paragraph -->

На сайте WordPress преобразует эти данные в CSS внутри медиазапросов и добавляет блоку стабильный сгенерированный класс. Для значений отдельного экземпляра блока некоторые декларации получают !important, чтобы переопределить обычные inline-стили блока. Раскладка и blockGap обрабатываются существующим механизмом Layout Support.

Собственные панели управления блоком не становятся адаптивными автоматически. Новый механизм работает только для свойств, подключённых через стандартные Block Supports.

Настройка контрольных точек

По умолчанию WordPress использует следующие диапазоны:

Состояние Медиазапрос
@mobile @media (width <= 480px)
@tablet @media (480px < width <= 782px)

Блочная тема может изменить обе границы через новое свойство верхнего уровня settings.viewport:

{
	"version": 3,
	"settings": {
		"viewport": {
			"mobile": "30rem",
			"tablet": "45rem"
		}
	}
}

Разрешены неотрицательные значения в px, em и rem. Проценты, CSS-функции, безразмерные числа и другие единицы игнорируются. Если граница планшета меньше или равна границе телефона, WordPress использует только мобильное состояние. Настройка является общей для темы и не может различаться для отдельных блоков.

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

Отключение UI адаптивных стилей

Плагин или тема могут скрыть элементы интерфейса, позволяющие пользователям создавать адаптивные переопределения:

add_filter( 'block_editor_settings_all', 'my_plugin_disable_responsive_editing' );

function my_plugin_disable_responsive_editing( $settings ) {
	$settings['responsiveEditingEnabled'] = false;

	return $settings;
}

Это отключает только интерфейс редактирования. Уже сохранённые значения в theme.json, глобальных стилях и атрибутах блоков продолжают работать и выводиться на сайте.

Интерактивные состояния блоков

WordPress 7.1 также позволяет задавать стили состояний :hover, :focus, :focus-visible и :active через

  • глобальные стили
  • настройки отдельного блока
  • theme.json.

В этой версии пользовательский интерфейс доступен только для блоков «Кнопка» и «Ссылка навигации».

Новый UI для блока кнопка в настройках глобальных стилей.

В theme.json состояния записываются внутри объекта блока:

{
	"version": 3,
	"styles": {
		"blocks": {
			"core/button": {
				"color": {
					"background": "black",
					"text": "white"
				},
				":hover": {
					"color": {
						"background": "blue"
					}
				},
				":focus-visible": {
					"color": {
						"background": "purple"
					}
				}
			}
		}
	}
}

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

"@mobile": {
	":hover": {
		"color": {
			"background": "var:preset|color|contrast"
		}
	}
}
Navigation > Custom Link

Для блока «Ссылка навигации» появился ранний механизм пользовательских состояний. Через ключ -current тема может оформить текущий пункт меню:

{
	"styles": {
		"blocks": {
			"core/navigation-link": {
				"-current": {
					"color": {
						"text": "var:preset|color|contrast"
					}
				}
			}
		}
	}
}
Настройка стилей состояния для блока навигации Custom Link.

Пользовательского интерфейса для -current пока нет: значение задаётся только в theme.json.

Отключение интерактивных состояний

Редактирование интерактивных состояний можно отключить отдельно:

add_filter( 'block_editor_settings_all', 'my_plugin_disable_block_states_editing' );

function my_plugin_disable_block_states_editing( $settings ) {
	$settings['blockStatesEditingEnabled'] = false;

	return $settings;
}

Как и responsiveEditingEnabled, эта настройка скрывает интерфейс, но не удаляет ранее сохранённые стили.

Редактор записей теперь всегда работает внутри iframe

Раньше редактор записей мог работать в двух режимах:

  • внутри iframe;
  • непосредственно в документе административной страницы.

В WordPress 7.0 режим зависел от блоков в записи. Если все используемые блоки имели apiVersion: 3 или выше, редактор открывался в iframe. Если хотя бы один блок использовал старую версию Block API, WordPress отключал iframe ради совместимости.

Из-за этого одна запись могла открываться в iframe, а другая без него. Один и тот же код плагина в разных записях вёл себя по-разному.

Начиная с WordPress 7.1 редактор записей всегда загружается внутри iframe. Тип темы, версии Block API зарегистрированных блоков и содержимое записи на это больше не влияют.

Редактор сайта, редактор шаблонов и предварительный просмотр устройств уже давно используют iframe. Теперь редактор записей работает по той же схеме.

Редактор записи в WordPress 7.1 с выделенной границей iframe
Зачем нужен iframe

Iframe изолирует содержимое записи от интерфейса административной страницы. Это позволяет:

  • загружать в холст стили темы без риска изменить интерфейс редактора;
  • точнее показывать внешний вид записи на сайте;
  • отделить события и стили содержимого от панели редактора;
  • сделать поведение разных редакторов WordPress одинаковым.

Обработка изображений в браузере

Как изображения обрабатывались раньше

Обычно браузер отправлял оригинальный файл на сервер. После этого PHP с помощью GD или Imagick:

  • исправлял ориентацию по EXIF;
  • уменьшал очень большие изображения;
  • создавал размеры, зарегистрированные через add_image_size();
  • менял формат и качество изображения;
  • записывал метаданные вложения.

Обработка могла завершиться ошибкой из-за ограничения памяти PHP, слабого сервера или отсутствия поддержки нужного формата в GD или Imagick.

Как работает новый механизм

В WordPress 7.1 поддерживаемый браузер обрабатывает изображение до отправки файлов на сервер. Для этого используется wasm-vips - сборка библиотеки libvips в формате WebAssembly. Тяжёлая работа выполняется в Web Worker и не блокирует интерфейс редактора.

Последовательность выглядит так:

  1. Браузер получает от WordPress настройки изображения и список зарегистрированных размеров.
  2. Оригинал декодируется в браузере.
  3. Браузер изменяет размер, ориентацию, формат и качество изображения.
  4. Для каждого зарегистрированного размера создаётся отдельный файл.
  5. Оригинал и созданные размеры загружаются на сервер отдельными REST API запросами.
  6. Финальный запрос завершает обработку и обновляет метаданные вложения.

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

Вкладка Network инструментов разработчика во время загрузки большого изображения.

Что делается в браузере

  • создаёт стандартные и зарегистрированные через add_image_size() размеры изображений, изменяя их размер и выполняя обрезку в соответствии с параметром $crop;
  • сжимает JPEG, PNG, WebP, AVIF и GIF; качество JPEG можно изменить через фильтры wp_editor_set_quality и jpeg_quality;
  • преобразует изображения в другой формат в соответствии с настройками фильтра image_editor_output_format;
  • исправляет ориентацию изображения на основании EXIF-данных; это поведение можно изменить через фильтр wp_image_maybe_exif_rotate;
  • создаёт progressive JPEG и interlaced PNG, если это включено через фильтр image_save_progressive;
  • декодирует HEIC и HEIF, загружает веб-версию в формате JPEG, а исходный файл сохраняет как сопутствующий source_image;
  • обрабатывает AVIF, включая создание промежуточных размеров, даже если серверные GD или Imagick не поддерживают этот формат;
  • преобразует непрозрачный анимированный GIF в более компактное MP4- или WebM-видео при загрузке через отдельный блок «Изображение». Прозрачные GIF и изображения внутри блоков «Галерея», «Медиа и текст» и «Обложка» не преобразуются.

Для HEIC оригинальный файл сохраняется как сопутствующий source_image и удаляется вместе с вложением.

Прозрачные GIF остаются изображениями. Автоматическая замена GIF на видео применяется только к отдельному блоку «Изображение». GIF внутри блоков «Галерея», «Медиа и текст» и «Обложка» не преобразуется.

По данным команды WordPress, создаваемые libvips JPEG-файлы примерно на 15% меньше файлов, созданных GD или Imagick с сопоставимыми настройками.

Поддержка браузеров

Полный механизм требует SharedArrayBuffer и заголовка Document-Isolation-Policy. На момент выпуска WordPress 7.1 он доступен в Chrome и Edge версии 137 или новее.

Браузер Обработка в браузере
Chrome 137+ Полная поддержка
Edge 137+ Полная поддержка
Firefox Автоматическая обработка на сервере
Safari Автоматическая обработка на сервере, но доступно декодирование HEIC

WordPress также проверяет характеристики устройства и соединения. Обработка в браузере включается, если у устройства более 2 ГБ памяти, не менее двух ядер CPU, соединение не помечено как 2g или slow-2g, не включён Save-Data и CSP разрешает создание worker из blob:.

Если хотя бы одна проверка не пройдена, WordPress без сообщения пользователю использует прежнюю серверную обработку.

Какие php хуки продолжают работать

Браузер получает настройки с сервера, поэтому продолжают учитываться фильтры:

Размеры, добавленные через add_image_size(), также создаются в браузере. Если несколько размеров имеют одинаковые параметры, WordPress создаёт один физический файл.

Фильтр wp_generate_attachment_metadata продолжает вызываться:

  • с контекстом create после первоначальной загрузки;
  • с контекстом update после загрузки всех размеров и финализации.

Какие php хуки не вызываются

При обработке в браузере серверный редактор изображений не используется. Поэтому не вызываются:

Как отключить

Клиентскую обработку можно отключить фильтром:

add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );

Состояние механизма можно получить через функцию:

if ( wp_is_client_side_media_processing_enabled() ) {
	// Клиентская обработка разрешена настройками WordPress.
}

Функция показывает, разрешён ли механизм на стороне WordPress. Фактический выбор клиентского или серверного пути зависит также от браузера и устройства пользователя.

CSP и внешние ресурсы редактора

Для Web Worker политика Content Security Policy должна разрешать blob::

Content-Security-Policy: worker-src 'self' blob:;

Если blob: запрещён, WordPress перейдёт на серверную обработку.

В Chromium 137+ на экранах редактора WordPress отправляет заголовок:

Document-Isolation-Policy: isolate-and-credentialless

Внешним скриптам автоматически добавляется crossorigin="anonymous". Загрузка ресурсов с другого домена через fetch() может быть заблокирована политикой CORS.

Новые REST API роуты

Для нового процесса добавлены:

  • POST /wp/v2/media/{id}/sideload - загрузка отдельного созданного файла;
  • POST /wp/v2/media/{id}/finalize - завершение обработки вложения;
  • параметры generate_sub_sizes и convert_format;
  • флаг replace_file для сопутствующего HEIC-файла;
  • поля ответа exif_orientation, missing_image_sizes, filename и filesize.

Новый редактор медиафайлов

Старая встроенная панель кадрирования заменена отдельным модальным окном редактирования изображения. Кнопка «Обрезать» осталась на привычном месте, но теперь открывает единый интерфейс, в котором доступны:

  • свободное кадрирование;
  • кадрирование с выбранным соотношением сторон;
  • отражение по горизонтали и вертикали;
  • точный и пошаговый поворот;
  • редактирование метаданных изображения.

Новый интерфейс используется блоками «Изображение» и «Обложка».

Изменения в медиатеке

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

В редакторе также упрощена работа с файлами текущей записи:

  • во вкладке «Медиа» в добавителе блоков появился раздел с изображениями, прикреплёнными к записи;
  • блок «Галерея» может автоматически получать и сортировать прикреплённые медиафайлы;
  • галерею или колонки можно преобразовать в блок «Сетка» без потери вложенного содержимого;
  • для декоративного изображения можно явно включить скрытие от программ чтения с экрана;
  • фоновые изображения и градиенты можно использовать одновременно там, где блок поддерживает оба типа фона.

Постоянная панель инструментов в редакторах

В WordPress 7.1 верхняя панель инструментов WordPress показывается в редакторе записей и редакторе сайта по умолчанию. Она скрывается только в режиме «Без отвлечения».

Панель теперь всегда видна

Расширенные заметки и упоминания

Заметки в редакторе больше не ограничены одним обсуждением на весь блок. В WordPress 7.1 можно:

  • создать несколько обсуждений для одного блока;
  • прикрепить заметку к выделенному фрагменту текста;
  • использовать полужирное и курсивное начертание, код и ссылки;
  • упомянуть другого пользователя через @ и отправить ему уведомление по электронной почте;
  • сворачивать длинные заметки, чтобы они не занимали всю боковую область.

Новый публичный SVG Icon API

В WordPress 7.0 появился встроенный набор SVG-иконок для редактора и блока «Иконка». В WordPress 7.1 эта система получила публичный API.

Выбор иконки в блоке «Иконка»

Теперь плагин может один раз зарегистрировать коллекцию иконок, после чего использовать её:

  • в выборе иконок блока «Иконка»;
  • при серверном рендеринге через PHP;
  • через REST API;
  • в собственном интерфейсе редактора.

Коллекции и имена иконок

Каждая иконка принадлежит коллекции. Полное имя состоит из коллекции и имени иконки:

my-plugin/star

Пространство имён предотвращает конфликт, например между core/plus и my-plugin/plus.

Сначала нужно зарегистрировать коллекцию, затем иконки:

add_action( 'init', 'my_plugin_register_icons' );
function my_plugin_register_icons() {
	wp_register_icon_collection( 'my-plugin', [
		'label'       => 'My Plugin Icons',
		'description' => 'Icons provided by My Plugin.',
	] );

	wp_register_icon( 'my-plugin/star', [
		'label'   => 'Star',
		'content' => '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">
			<path fill="currentColor" d="M12 2l2.9 6.9 7.1.6-5.4 4.7 1.6 7L12 18l-6.2 3.2 1.6-7L2 9.5l7.1-.6z" />
		</svg>',
	] );

	wp_register_icon( 'my-plugin/heart', [
		'label'     => 'Heart',
		'file_path' => plugin_dir_path( __FILE__ ) . 'icons/heart.svg',
	] );
}

Для SVG нужно передать либо content, либо абсолютный file_path, но не оба параметра сразу. Файл из file_path читается только при первом запросе содержимого. Поэтому регистрация может пройти успешно даже при ошибочном пути, а проблема проявится позже пустым SVG.

Удалить отдельную иконку можно через wp_unregister_icon(), а коллекцию вместе со всеми её иконками - через wp_unregister_icon_collection().

Вывод иконки в PHP

Функция wp_get_icon() возвращает готовую SVG-разметку:

echo wp_get_icon( 'my-plugin/star', [
	'size'  => 32,
	'label' => 'Featured',
	'class' => 'my-plugin-star',
] );

Параметры:

  • size - ширина и высота, по умолчанию 24 пикселя;
  • class - дополнительные CSS-классы элемента <svg>;
  • label - доступное название для программы чтения с экрана.

Если label не передан, иконка считается декоративной и скрывается от программ чтения с экрана.

Если иконка не зарегистрирована, функция возвращает пустую строку.

Ограничения SVG

При регистрации WordPress очищает SVG через wp_kses(). В WordPress 7.1 разрешены только элементы <svg>, <path> и <polygon> с ограниченным набором атрибутов.

Скрипты, обработчики событий, inline-стили и неподдерживаемые SVG-элементы удаляются. Атрибут stroke пока не разрешён, поэтому иконки, построенные только линиями, могут отображаться неправильно. Фигуры с fill поддерживаются.

Чтобы цвет отдельной иконки, выведенной через wp_get_icon(), наследовался от текста, можно добавить fill="currentColor" к <path> при регистрации или задать CSS:

.my-plugin-star {
	fill: currentColor;
}

Иконки в редакторе и REST API

Блок «Иконка» группирует иконки по коллекциям. В интерфейсе есть отдельная вкладка для каждой коллекции и общая вкладка со всеми иконками. Поиск работает внутри выбранной коллекции.

Доступны read-only эндпоинты:

GET /wp/v2/icon-collections
GET /wp/v2/icon-collections/{collection}
GET /wp/v2/icons
GET /wp/v2/icons/{collection}
GET /wp/v2/icons/{collection}/{name}

REST API позволяет получить зарегистрированные коллекции и очищенную SVG-разметку, но не позволяет регистрировать или изменять иконки. Для запросов нужен авторизованный пользователь с правом редактировать записи или эквивалентным правом для доступного через REST API типа записи.

Новые блоки «Плейлист» и «Вкладки»

В ядро добавлены два новых блока, которые раньше обычно требовали отдельного плагина.

Плейлист (core/playlist)

То, как выглядит новый блок плейлист с его UI.

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

Внутренняя структура построена на блоках core/playlist и core/playlist-track.

Вкладки (core/tabs)

То, как выглядит новый блок вкладки, его UI.

Блок «Вкладки» позволяет распределить содержимое по переключаемым панелям. Он состоит из родительского блока и внутренних блоков списка, панелей и отдельных панелей: core/tabs, core/tab-list, core/tab-panels и core/tab-panel.

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

Новые Block Supports

Фоновый градиент

Блок может отдельно заявить поддержку градиента поверх фонового изображения через background.gradient в block.json. Это позволяет одновременно использовать изображение и градиент, не объединяя их вручную в одно CSS-свойство.

{
	"supports": {
		"background": {
			"backgroundImage": true,
			"backgroundSize": true,
			"gradient": true
		}
	}
}

Минимальная ширина

Новый Block Support для минимальной ширины даёт совместимым блокам стандартное управление min-width. Разработчику блока больше не нужно создавать собственный атрибут и отдельную панель только для этой настройки.

Редактируемые блоки в предпросмотре HTML

Поддерживаемые блоки, вложенные в блок «Пользовательский HTML», могут оставаться редактируемыми в режиме предпросмотра.

Тень текста в theme.json

В styles.typography появилось свойство textShadow, которое напрямую преобразуется в CSS-свойство text-shadow. Оно поддерживается:

  • на глобальном уровне
  • для отдельных типов блоков и элементов, включая их состояния
{
	"version": 3,
	"styles": {
		"typography": {
			"textShadow": "1px 1px 2px rgb(0 0 0 / 30%)"
		},
		"blocks": {
			"core/paragraph": {
				"typography": {
					"textShadow": "none"
				}
			}
		}
	}
}

В WordPress 7.1 это только возможность theme.json. Интерфейса, набора пресетов и Block Support для настройки тени у отдельного блока пока нет.

Темизация интерфейсов через WordPress Design System

WordPress 7.1 закладывает основу для темизации административных React-интерфейсов. Зарегистрированы новые style- и script-handle с именем wp-theme.

Таблица стилей предоставляет семантические CSS-переменные для цветов, границ, скруглений, размеров и других частей интерфейса. Плагин может добавить wp-theme как зависимость и использовать токены вместо жёстко заданных значений:

.my-plugin-card {
	background: var(--wpds-color-background-surface-neutral-strong);
	color: var(--wpds-color-foreground-content-neutral);
	border: var(--wpds-border-width-xs) solid var(--wpds-color-stroke-surface-neutral-weak);
	border-radius: var(--wpds-border-radius-lg);
	padding: var(--wpds-dimension-padding-2xl);
}

Пакет @wordpress/theme экспортирует React-компонент ThemeProvider. Он позволяет задать основные цвета, степень скругления и вид курсора для отдельного дерева компонентов:

import { ThemeProvider } from '@wordpress/theme';
import { Card } from '@wordpress/ui';

function Application() {
	return (
		<ThemeProvider
			color={ {
				primary: '#3858e9',
				background: '#11004d',
			} }
			cornerRadius="pronounced"
		>
			<Card.Root>
				<Card.Content>Plugin content</Card.Content>
			</Card.Root>
		</ThemeProvider>
	);
}

Поддерживаются исходные цвета primary и background, пресеты cornerRadius, настройка cursor.control и флаг isRoot. Цветовая шкала генерируется автоматически.

Это пока фундамент будущей переработки административной части. Он не означает, что весь wp-admin в WordPress 7.1 уже переведён на новый дизайн.

Настройка экранов Site Editor

Для экранов страниц, шаблонов, частей шаблонов и паттернов появились четыре фильтра конфигурации View Config:

  • [get_entity_view_config_posttype_page]() — ERROR: not_found
  • [get_entity_view_config_posttype_wp_template]() — ERROR: not_found
  • [get_entity_view_config_posttype_wp_template_part]() — ERROR: not_found
  • [get_entity_view_config_posttype_wp_block]() — ERROR: not_found

Через них плагин может изменить:

  • default_view - тип представления, сортировку и видимые поля;
  • default_layouts - доступные пользователю варианты раскладки;
  • view_list - предустановленные представления в боковой панели;
  • form - поля и порядок формы быстрого редактирования DataForm.

Например, следующий код делает сетку представлением по умолчанию для страниц, сортирует записи по заголовку и добавляет поле даты:

add_filter( 'get_entity_view_config_posttype_page', 'my_plugin_filter_page_view_config' );

function my_plugin_filter_page_view_config( $data ) {
	$patch = array(
		'default_view' => array(
			'type'   => 'grid',
			'sort'   => array(
				'field'     => 'title',
				'direction' => 'asc',
			),
			'fields' => array( 'date' ),
		),
	);

	$data->merge( $patch, 1 );

	return $data;
}

Фильтры относятся к новым экранам Site Editor на базе DataViews и DataForm. Они не заменяют хуки классических таблиц записей в wp-admin.

Улучшения доступности

Публичные функции подсказок

Для административных интерфейсов появились функции wp_get_tooltip() и wp_get_toggletip().

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

echo wp_get_tooltip(
	__( 'Show or hide the menu', 'my-plugin' ),
	array(
		'icon' => 'dashicons-menu',
	)
);

CSS загружается в административной части глобально. Если подсказка используется на сайте, стиль нужно подключить явно:

wp_enqueue_style( 'wp-tooltip' );
wp_enqueue_script( 'wp-tooltip' );

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

Изменилась разметка таблиц записей

В списках записей, страниц и пользовательских типов записей заголовок строки теперь размечается как <th scope="row">, а ячейка с флажком выбора стала обычной <td>. Это делает таблицу понятнее для программ чтения с экрана.

Улучшения Abilities API

Abilities API появился в WordPress 6.9. Он позволяет плагинам регистрировать отдельные действия с формально описанными входными и выходными данными, проверкой прав и единым способом выполнения. Такие действия могут использовать REST API, инструменты автоматизации и AI-клиенты.

В WordPress 7.1 API стал удобнее для валидации, аудита и программного обнаружения возможностей.

Дополнительная проверка входных и выходных данных

Класс WP_Ability проверяет данные по JSON Schema. Теперь плагины могут добавить правила, которые невозможно выразить используемой реализацией схемы:

  • wp_ability_validate_input - дополнительная проверка входных данных;
  • wp_ability_validate_output - дополнительная проверка результата.

Обработчик должен вернуть true или объект WP_Error. Если стандартная проверка уже вернула ошибку, её нужно сохранить:

add_filter( 'wp_ability_validate_input', 'my_validate_send_message_input', 10, 3 );

function my_validate_send_message_input( $is_valid, $input, $ability_name ) {
	if ( 'my-plugin/send-message' !== $ability_name || is_wp_error( $is_valid ) ) {
		return $is_valid;
	}

	if ( empty( $input['recipient'] ) || ! str_ends_with( $input['recipient'], '@example.com' ) ) {
		return new WP_Error(
			'invalid_recipient',
			__( 'The recipient must use the example.com domain.', 'my-plugin' )
		);
	}

	return true;
}

Ключи схемы validate_callback и sanitize_callback, знакомые по REST API, внутри Abilities API не выполняются. Для дополнительной проверки следует использовать новые фильтры.

Событие при каждом запуске ability

Новый экшен wp_ability_invoked вызывается в самом начале WP_Ability::execute():

do_action( 'wp_ability_invoked', $this->name, $input, $this );

Он срабатывает до нормализации данных, проверки схемы, проверки прав и short-circuit-фильтра. Поэтому событие возникает даже для неправильного или запрещённого вызова.

Это полезно для аудита, телеметрии, трассировки и подсчёта вызовов. Входные данные на этом этапе сырые и могут содержать персональную или секретную информацию, поэтому не следует без разбора записывать $input в журнал.

Существующие экшены wp_before_execute_ability и wp_after_execute_ability теперь дополнительно получают объект WP_Ability последним аргументом. Старые обработчики продолжат работать, но для получения нового аргумента нужно изменить сигнатуру callback и значение $accepted_args.

Больше информации о текущем пользователе

Ability core/get-user-info теперь возвращает дополнительные поля:

  • first_name;
  • last_name;
  • nickname;
  • description;
  • user_url.

Через новый входной параметр fields можно запросить только нужные свойства:

$ability = wp_get_ability( 'core/get-user-info' );

$result = $ability->execute( [
	'fields' => [
		'display_name',
		'first_name',
		'last_name',
	],
] );

Неизвестное имя поля отклоняется схемой до запуска callback. Правило доступа не изменилось: пользователь должен быть авторизован.

core/get-environment-info также поддерживает параметр fields. Схемы core/get-site-info, core/get-user-info и core/get-environment-info приведены к единому формату и содержат понятные названия и описания свойств. Это упрощает работу REST, MCP, WebMCP и AI-клиентов, которые строят интерфейс или выбирают данные по схеме.

Типизация входных данных REST-запроса

В GET и DELETE запросах значения query string приходят строками. Раньше ability могла получить строку "10" вместо числа 10 или строку "true" вместо логического значения.

WordPress 7.1 приводит значения к типам из input_schema до выполнения permission callback и основного callback. Например:

?input[limit]=10&input[featured]=true&input[ids]=1,2,3

при соответствующей схеме превратится в:

[
	'limit'    => 10,
	'featured' => true,
	'ids'      => [ 1, 2, 3 ],
]

Это устраняет необходимость вручную преобразовывать типы в каждом callback.

jQuery UI обновлён до версии 1.14.2

WordPress обновил jQuery UI с версии 1.13.3 до 1.14.2. Новая версия больше не поддерживает Internet Explorer и старый Microsoft Edge, что соответствует текущей политике поддержки браузеров WordPress.

Для совместимости WordPress устанавливает jQuery.uiBackCompat = true. Благодаря этому старый API jQuery UI 1.11 в основном продолжает работать.

Однако следующие внутренние свойства и методы удалены:

  • $.fn._form;
  • $.ui.ie;
  • $.ui.safeActiveElement;
  • $.ui.safeBlur.

Ядро WordPress эти свойства и методы не использует.

Изменения в @wordpress/components

Высота полей формы теперь всегда 40 пикселей

Компоненты форм из @wordpress/components теперь по умолчанию имеют высоту 40 пикселей. Ранее разработчик мог заранее включить новый размер через свойство __next40pxDefaultSize. В WordPress 7.1 это свойство больше ничего не делает.

Изменение затрагивает в том числе TextControl, SelectControl, NumberControl, SearchControl, ComboboxControl, UnitControl, RangeControl, ToggleGroupControl, TreeSelect, FontSizePicker и ряд других компонентов.

Переход с Emotion на SCSS Modules

WordPress постепенно переводит компоненты пакета @wordpress/components с Emotion на SCSS Modules.

Emotion - это библиотека CSS-in-JS: стили описываются в JavaScript через css, cx() или styled, а необходимые CSS-классы создаются во время работы приложения. Это удобно для динамических стилей, но увеличивает объём JavaScript и связывает компоненты с конкретной библиотекой.

SCSS Modules используют обычные .module.scss-файлы. Стили создаются во время сборки, а имена классов автоматически изолируются, поэтому они не конфликтуют со стилями других компонентов. Такой подход уменьшает количество выполняемого JavaScript и делает CSS более предсказуемым.

Большинство плагинов не заметит изменений. Однако свойство css компонента View больше не применяет стили. Для этого используются className или style:

<View className="my-plugin-view" />

При объединении Emotion-стилей через cx() порядок каскада сохраняется, когда фрагменты передаются в один вызов css():

const classes = cx(
	css( baseStyles, condition && overrideStyles ),
	className
);

В WordPress 7.1 миграция затрагивает Divider, Surface, Truncate, View, Flex и Spacer. В следующих версиях этот список будет расширяться.

Удалён компонент Navigation

Устаревшие Navigation и его дочерние компоненты удалены из @wordpress/components. Они были помечены устаревшими с WordPress 6.8. В пакете остаётся компонент Navigator.

Это несовместимое изменение: импорт удалённого компонента может привести к ошибке JavaScript и остановить загрузку интерфейса плагина.

Также удалена экспериментальная утилита __experimentalApplyValueToSides. Сам BoxControl продолжает работать.

--

https://ru.wordpress.org/download/releases/7-1/

До этого из: Релиз Wordpress
2 комментария