API Rewrite: типы записей и таксономии

() translation by (you can also view the original English article)

Это вторая часть серии, посвященной API переписывания WordPress. В первой части мы ознакомились с основами API переписывания WordPress. В этом уроке мы рассмотрим настройки перезаписи, доступные нам при регистрации типа записи или таксономии. Хотя пользовательские типы сообщений и таксономии (в отличие от сообщений, категорий и тегов по умолчанию) не имеют преимуществ от интерфейса «Настройки» -> «Постоянная ссылка», настройка перезаписей для пользовательских типов все еще довольно проста. Мы также будем использовать методы, представленные в первой части, поэтому, если вы еще этого не сделали, я рекомендую вам прочитать WordPress 'Rewrite API Part One: Основы.

Сброс правил переписывания

Когда вы регистрируете пользовательский тип, WordPress также регистрирует правила перезаписи (на самом деле, не совсем, и я объясню почему в разделе «Permastructures»). Как упоминалось в первой части, эти правила будут включены только после того, как правила перезаписи будут «сброшены». Темы и плагины могут вызвать эту «очистку», вызывая flush_rewrite_rules (). Это необходимо и нужно сделать только один раз при активации, а затем снова при деактивации (чтобы очистить себя).

Очевидно, что перед сбросом правил перезаписи вам необходимо добавить их. Однако ловушка init инициализации, для которой типы записей должны быть зарегистрированы, уже была запущена, и когда это было так, ваш плагин или тема еще не были активны, и поэтому ваши типы записей и таксономии еще не зарегистрированы. Для того чтобы зарегистрировать правила перезаписи, которые поставляются с вашими типами постов и таксономиями, это означает, что вам нужно «вручную» зарегистрировать их при активации перед сбросом правил перезаписи. Итак, это должна быть ваша установка:


function wptuts_register_types() {
  //function which registers your custom post type and taxonomies
}
add_action('init','wptuts_register_types');

function wptuts_plugin_activation() {

	// Register types to register the rewrite rules
	wptuts_register_types();

	// Then flush them
	flush_rewrite_rules();
}
register_activation_hook( __FILE__, 'wptuts_plugin_activation');

function wptuts_plugin_deactivation() {

	flush_rewrite_rules();
}
register_activation_hook( __FILE__, 'wptuts_plugin_activation');

Темы могут использовать ловушки after_switch_theme для активации и switch_theme для деактивации.

Пользовательские типы сообщений

Когда вы регистрируете тип записи с помощью register_post_type, один из доступных вам аргументов - это аргумент rewrite. Это должен быть массив со следующими ключами:

slug - слаг, используемый для определения типа записи в URL. К этому сообщению добавляется слаг для постоянной ссылки, например. www.example.com/books/the-wizard-of-oz
with_front - true (правда) или false (ложь). Если структура постоянных ссылок вашего сообщения начинается с постоянной базы, такой как «/ blog», - это также можно добавить в структуру постоянных ссылок вашего пользовательского типа, установив для нее значение true, например. Истина даст www.example.com/blog/books/ и ложь www.example.com/books/
каналы - правда или ложь. Нужно ли создавать правила перезаписи корма, например, www.example.com/books/feed/rss и www.example.com/book/rss. Значением по умолчанию является значение has_archive.
страницы - правда или ложь. Создавать ли правило для «милой» нумерации страниц для архива типов записей, например, www.example.com/books/page/2 вместо www.example.com/books?page=2. По умолчанию true.
ep_mask - раньше это был отдельный аргумент: permalink_epmask. Начиная с 3.4 он будет перемещен в массив перезаписи. По умолчанию используется EP_PERMALINK.

Ключи 'feeds' и 'pages' относятся только к архивной странице пост-типа (для которой необходимо установить для аргумента has_archive значение true). Из этого массива переписывания WordPress автоматически генерирует правила перезаписи для ваших типов записей. В качестве примера:


$labels = array(
	'name' => __('Books', 'your-plugins-translation-domain'),
	//array of labels
);

$args = array(
	'labels' => $labels,
	'has_archive'=>true,
	'rewrite' => array(
		'slug'=>'books',
		'with_front'=> false,
		'feed'=> true,
		'pages'=> true
	)
);
register_post_type('book',$args);

Даст следующие правила переписывания:

Постоянная ссылка на книгу «Волшебник страны Оз»: www.example.com/books/the-wizard-of-oz
Архив всех книг www.example.com/books (и www.example.com/books/page/2)
The feed вышеуказанного архива: www.example.com/books/feed/rss (и www.example.com/books/rss)

Таксономии (сисмематика)

Функция register_taxonomy () предлагает меньше вариантов:

slug – a slug - для определения таксономии, например www.example.com/genre/history
with_front – как указано выше.
иерархический - правда или ложь. Если установлено значение true и таксономия является иерархической, термин постоянная ссылка отражает иерархию. По умолчанию false.
ep_mask – Добавлено в 3.4. EP маска разделе ниже.

Первые два варианта аналогичны приведенным выше. Параметр иерархии дает термину постоянные ссылки ту же структуру, что и страницы. Например, пусть «История» будет жанром, а «Военная история» - поджанром. При иерархическом значении false «Военная история» будет иметь постоянную ссылку:

1
2	www.example.com/genre/military-history

Принимая во внимание значение true, оно будет иметь:

1
2	www.example.com/genre/military/military-history

Регистрация таксономии автоматически регистрирует каналы ваших таксономических терминов:

1
2	www.example.com/genre/military-history/feed

Вы можете получить постоянную ссылку на ссылку канала для любого термина таксономии с помощью $ feed_link = get_term_feed_link ($ term_id, $ taxonomy, $ feed)

Сообщение типа архивов

По умолчанию WordPress не создает «симпатичных» постоянных ссылок для архивов года, месяца или дня вашего пользовательского типа записей (ни для архива автора, но мы оставим его пока). В то время как:

1
2	www.example.com/?post_type=book&year=2012&monthnum=05

Правильно дает архив всех книг, опубликованных в мае 2012 года:

1
2	www.example.com/books/2012/05

Выдаст ошибку 404. Однако мы можем просто добавить дополнительные правила перезаписи, используя доступные методы API перезаписи, которые мы рассмотрели в первой части. Один из способов - добавить следующий список правил перезаписи при регистрации типа сообщения:


// Add day archive (and pagination)
add_rewrite_rule("books/([0-9]{4})/([0-9]{2})/([0-9]{2})/page/?([0-9]{1,})/?",'index.php?post_type=book&year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&paged=$matches[4]','top');
add_rewrite_rule("books/([0-9]{4})/([0-9]{2})/([0-9]{2})/?",'index.php?post_type=book&year=$matches[1]&monthnum=$matches[2]&day=$matches[3]','top');

// Add month archive (and pagination)
add_rewrite_rule("books/([0-9]{4})/([0-9]{2})/page/?([0-9]{1,})/?",'index.php?post_type=book&year=$matches[1]&monthnum=$matches[2]&paged=$matches[3]','top');
add_rewrite_rule("books/([0-9]{4})/([0-9]{2})/?",'index.php?post_type=book&year=$matches[1]&monthnum=$matches[2]','top');

// Add year archive (and pagination)
add_rewrite_rule("books/([0-9]{4})/page/?([0-9]{1,})/?",'index.php?post_type=book&year=$matches[1]&paged=$matches[2]','top');
add_rewrite_rule("books/([0-9]{4})/?",'index.php?post_type=book&year=$matches[1]','top');

Это может легко запутаться, особенно если учесть, что вам нужно будет добавить дополнительные правила, если вы хотите, чтобы ваши архивы поддерживали красивые URL для своих каналов. Однако приведенное выше иллюстрирует важный факт о добавлении пользовательских правил: порядок, в котором добавляются правила, важен.

Напомним, что эти правила добавляются в массив перезаписи в том порядке, в котором вы вызываете add_rewrite_rule. При анализе запроса WordPress использует первое правило соответствия. Попробуйте изменить порядок добавления правил архивирования года и месяца. Вы найдете, что www.example.com/books/2012/04/ перенесет вас в архив 2012 года. Это связано с тем, что этот URL соответствует шаблонам для архивов года и месяца, но первый был добавлен первым. Не забудьте всегда добавлять более определенное правило в первую очередь.

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

Permastructures

Есть простой способ достичь вышеупомянутого: add_permastruct. Эта функция используется WordPress для создания «», из которых она генерирует правила перезаписи (как выше), которые обрабатывают нумерацию страниц и каналы. Когда вы регистрируете пользовательский тип записи, WordPress не создает автоматически все правила перезаписи. Вместо этого он регистрирует permastructure - и только тогда, когда правила генерируются (то есть, когда они очищаются), WordPress использует эти permastructures для генерации реальных правил перезаписи.

Примером permastructure является тот, который вы используете в Настройки -> Постоянные ссылки. Они принимают любые «жестко запрограммированные» слагы или любые теги, которые существуют по умолчанию или были добавлены с помощью add_rewrite_tag, который мы рассмотрели в первой части. Например, permastructure% year% /% category% /% author% будет генерировать следующие правила перезаписи:

www.example.com/2012/url-rewriting/stephen
www.example.com/2012/URL-Rewriting/Stephen/Page/2
www.example.com/2012/URL-Rewriting/Stephen/Feed/RSS

www.example.com/2012/URL-Rewriting/
www.example.com/2012/URL-Rewriting/Page/2
www.example.com/2012/URL-Rewriting/Feed/RSS

www.example.com/2012/
www.example.com/2012/Page/2
www.example.com/2012/Feed/RSS

`Add_permastruct функция`

Функция add_permastruct принимает четыре аргумента:

name - уникальный слаг для идентификации вашей permastructure
struct - сама permastructure, например, '% Год% /% Категория% /% Автор%'
with_front – true или false. Это тот же самый аргумент как при регистрации типа пост
ep_mask – маска EP см ниже

Здесь необходимо сделать пару предупреждений об использовании add_permastruct. Во-первых: вам нужно убедиться, что пользовательская структура не конфликтует с правилами переписывания WordPress для постов и страниц. Это может быть сделано, предварительно ожидая Ваш обычай permastructure с чем-то трудно закодированным. Например:

1
2	'something-hard-coded/%year%/%monthnum%/%day%'

Во-вторых, правила добавляются в таком порядке, поэтому, если ваши теги являются «слишком общими», последние правила могут никогда не применяться. Например, приведенная выше структура (которую вы можете попробовать на странице «Настройки» -> «Постоянные ссылки») в целом работает хорошо, за исключением того, что:

1
2	www.example.com/2012/page/2

Интерпретируется как страница постов автора '2' в категории 'page' в 2012 году. Если вы хотите использовать add_permastruct и правильно разбивать правила разбивки на страницы и каналы, то вам нужно будет использовать теги, которые не являются "общими" (под этим я подразумеваю, что выражения регулярных выражений не являются общими). % author% и % category% являются хорошими примерами универсального тега, поскольку они обычно соответствуют любому символу.

Пример пользовательской пермаструктуры: Тип публикации Дата Архивы

С другой стороны, теги year(год), month (месяц) и day (день) очень специфичны - они соответствуют только положительным целым числам длины четыре и два, поэтому мы можем использовать add_permastruct для нашего архива дат типа записей. Из-за специфики тегов даты,нам нужно, чтобы эти правила были добавлены перед тем как есть правила постоянной ссылки на тип сообщения - поэтому добавьте следующее непосредственно перед регистрацией типа сообщения:

1
2	// Please note that this will only work on WordPress 3.4+ http://core.trac.wordpress.org/ticket/19871
3	add_rewrite_tag('%book_cpt%','(book)s','post_type=');
4	add_permastruct('book_archive', '%book_cpt%/%year%/%monthnum%/%day%');

В приведенном выше примере пользовательский тег% book_cpt% действует как жестко заданный элемент, чтобы отличать эту структуру от других правил (согласно первому предупреждению). Сгенерированные правила будут применяться только в том случае, если% book_cpt% соответствует 'books', и в этом случае часть 'book' захватывается и интерпретируется как значение для post_type. Обратите внимание, что add_rewrite_tag (переписать тег) принимает только третий аргумент начиная с WordPress 3.4. Тем не менее, вы можете использовать следующие обходные пути:

1
2	global $wp_rewrite;
3	$wp_rewrite->add_rewrite_tag('%book_cpt%','(book)s','post_type=');

Установив архивы книг, вы также можете ожидать, что

1
2	www.example.com/books?year=2012

Приведет нас к книжному архиву 2012 года. Однако, тестирование показывает, что вместо этого мы переходим на страницу архива после года:

1
2	www.example.com/2012/

WordPress перенаправил нас на другую страницу из-за того, что известно как канонизация.

Каноническое перенаправление

Как правило, есть много URL, которые могут указывать на один и тот же контент на вашем сайте. Например:


www.example.com/year/2012

www.example.com/year/2012/page/1

www.example.com/2012/////////page/1

www.example.com/index.php/2012/

www.example.com/index.php////2012///page/1

Все вы попадете на первую страницу вашего архива 2012 года. С точки зрения SEO это не очень хорошо - мы не можем предполагать, что поисковые системы будут распознавать эти URL как один и тот же ресурс, и эти URL могут в конечном итоге конкурировать друг с другом. Google может также активно наказывать вас за дублирующийся контент, и, хотя он хорошо определяет, когда это дублирование не является «вредоносным», он все же рекомендует перенаправить эти лишние URL-адреса на один предпочтительный «канонический» (или стандартный) URL-адрес. Это называется канонизация.

Это не только помогает консолидировать рейтинги, такие как популярность ссылок, но и помогает вашим пользователям. Если они используют некрасивый или «неправильный» URL-адрес - их перенаправляют на «правильный» URL-адрес, и то, что находится в их адресной строке, - это то, к чему они с большей вероятностью вернутся.

Начиная с версии 2.1.0 WordPress обрабатывал каноническое перенаправление, даже принимая обоснованное предположение о требуемом контенте, если исходный запрос возвратил 404. К сожалению, в этом случае WordPress перенаправляет на неправильный URL-адрес. Это потому, что URL-адрес, который мы на самом деле хотим, не является понятным для WordPress и игнорирует часть URL-адреса «тип публикации». К счастью, однако, мы можем использовать фильтр redirect_canonical, чтобы исправить это.


add_filter('redirect_canonical', 'wptuts_redirect_canonical', 10, 2);
function wptuts_redirect_canonical($redirect_url, $requested_url) {

	global $wp_rewrite;

	// Abort if not using pretty permalinks, is a feed, or not an archive for the post type 'book'
	if( ! $wp_rewrite->using_permalinks() || is_feed() || ! is_post_type_archive('book') )
		return $redirect_url;

	// Get the original query parts
	$redirect = @parse_url($requested_url);
	$original = $redirect_url;
	if( !isset($redirect['query'] ) )
		$redirect['query'] ='';

	// If is year/month/day - append year
	if ( is_year() || is_month() || is_day() ) {
		$year = get_query_var('year');
		$redirect['query'] = remove_query_arg( 'year', $redirect['query'] );
		$redirect_url = user_trailingslashit(get_post_type_archive_link('book')).$year;
	}

	// If is month/day - append month
	if ( is_month() || is_day() ) {
		$month = zeroise( intval(get_query_var('monthnum')), 2 );
		$redirect['query'] = remove_query_arg( 'monthnum', $redirect['query'] );
		$redirect_url .= '/'.$month;
	}

	// If is day - append day
	if ( is_day() ) {
		$day = zeroise( intval(get_query_var('day')), 2 );
		$redirect['query'] = remove_query_arg( 'day', $redirect['query'] );
		$redirect_url .= '/'.$day;
	}

	// If paged, apppend pagination
	if ( get_query_var('paged') > 0 ) {
		$paged = (int) get_query_var('paged');
		$redirect['query'] = remove_query_arg( 'paged', $redirect['query'] );

		if ( $paged > 1 )
			$redirect_url .= user_trailingslashit("/page/$paged", 'paged');
	}

	if( $redirect_url == $original )
		return $original;

	// tack on any additional query vars
	$redirect['query'] = preg_replace( '#^\??&*?#', '', $redirect['query'] );
	if ( $redirect_url && !empty($redirect['query']) ) {
		parse_str( $redirect['query'], $_parsed_query );
		$_parsed_query = array_map( 'rawurlencode', $_parsed_query );
		$redirect_url = add_query_arg( $_parsed_query, $redirect_url );
	}

	return $redirect_url;
}

Вышеуказанная функция длинная, но не очень сложная. Он может быть улучшен и предназначен только как пример того, что вы можете сделать с фильтром redirect_canonical. Сначала он проверяет, включены ли постоянные ссылки, что мы следим за нашим «книжным» архивом, а не за фидом. Затем он проверяет по очереди:

Это архив года, месяца или дня? Если это так, удалите переменную year из строки запроса и установите URL-адрес перенаправления на www.example.com/books/[year].
Это архив месяца или дня? Если это так, удалите переменную monthnum из строки запроса и добавьте значение к URL-адресу перенаправления: www.example.com/books/[year]/[monthnum]
Это дневной архив? Если это так, удалите переменную 'day' из строки запроса и добавьте значение к URL-адресу перенаправления: www.example.com/books/[year]/[monthnum]/[day]]
Наконец, если есть переменная с постраничной передачей, добавьте ее в URL перенаправления.

Теги в типе поста Постоянные ссылки

Еще одна функция, которая не поддерживается для типов записей или таксономий «из коробки», - это использование тегов в структуре постоянных ссылок. Хотя теги, используемые в 'slug' массива переписывания типа записей (или таксономии), интерпретируются правильно, WordPress не заменяет эти теги соответствующими значениями при генерации постоянных ссылок - нам нужно заменить их самим. Однако использование таких тегов также нарушает страницу архива типа записи, поэтому мы будем использовать другой метод. В качестве примера, давайте предположим, что мы хотим, чтобы наш пользовательский тип записи «книга» имел структуру:

1
2	www.example.com/books/[some-genre]/[a-book]

Я использую пример пользовательской таксономии, но те же методы можно использовать для любой пермаструктуры (например, включая дату, автора или даже пользовательское поле). Прежде всего, мы добавим правило перезаписи:


function wptuts_custom_tags() {
	add_rewrite_rule("^books/([^/]+)/([^/]+)/?",'index.php?post_type=book&genre=$matches[1]&book=$matches[2]','top');
}
add_action('init','wptuts_custom_tags');

Теперь, например, www.example.com/book/fiction/the-wizard-of-oz указывает на книгу «the wizard-of-oz». Однако постоянная ссылка, генерируемая WordPress, все еще производит www.example.com/book/the-wizard-of-oz. Следующим шагом является изменение созданной постоянной ссылки.

Мы сделали нечто подобное в первой части, когда хотели использовать пользовательский тег в структуре post-permalink. Затем мы использовали фильтр post_link; на этот раз мы используем эквивалент для пользовательских типов записей, фильтр post_type_link. Используя этот хук, мы можем внедрить нашу структуру в постоянные ссылки книг.


function wptuts_book_link( $post_link, $id = 0 ) {

	$post = get_post($id);

	if ( is_wp_error($post) || 'book' != $post->post_type || empty($post->post_name) )
		return $post_link;

	// Get the genre:
	$terms = get_the_terms($post->ID, 'genre');

	if( is_wp_error($terms) || !$terms ) {
		$genre = 'uncategorised';
	}
	else {
		$genre_obj = array_pop($terms);
		$genre = $genre_obj->slug;
	}

	return home_url(user_trailingslashit( "books/$genre/$post->post_name" ));
}
add_filter( 'post_type_link', 'wptuts_book_link' , 10, 2 );

Управление переписыванием WordPress

Давайте расширим указанную выше структуру постоянных ссылок для достижения следующего:

Отдельная книга: www.example.com/books/[some-genre]/[a-book]
Все книги в жанре: www.example.com/books/[some-genre]
Все книги: www.example.com/books/

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

Итак, сначала мы регистрируем нашу пользовательскую таксономию 'жанр' с помощью:


$args = array(
	...
	'rewrite' => array(
		'slug'=>'books'
	),
	...
)
register_taxonomy('genre',$args);

Это добавляет следующую permastructure:

Книги в жанре: www.example.com/books/[some-genre]

После регистрации таксономии мы регистрируем наш собственный тип записи следующим образом:


$args = array(
	...
	'rewrite' => array(
		'slug'=>'books'
	),
	...
)
register_post_type('book',$args);

Это будет регистрировать следующие правила:

Все книги: www.example.com/books/ (которые нам нужны)
Конкретная книга: www.example.com/books/[a-book] (чего мы не делаем)

Однако второе противоречит (и «побивается») конкурирующему правилу, добавленному при регистрации нашей таксономии. Полученная структура:

Книга под названием «slug»: (Слаг) www.example.com/books/fiction/slug
Книги в жанре 'slug': www.example.com/books/slug
Все книги: www.example.com/books/

EP_Masks

Ранее, когда мы смотрели на регистрацию типов записей, таксономий (или иным образом, структур), WordPress позволил нам указать нашу собственную «ep_mask». Так что они?

В первой части мы рассмотрели, как мы можем добавлять конечные точки с помощью add_rewrite_endpoint. Второй аргумент в этой функции - это константа (или комбинация констант, использующая побитовые операторы), которые определяют, где добавляется конечная точка. Например:

1
2	add_rewrite_endpoint( 'form', EP_PAGES );

Добавляет форму перезаписи c (/(.*))?/?$ к каждой странице постоянная ссылка и:

1
2	add_rewrite_endpoint( 'json', EP_PAGES \| EP_PERMALINKS);

Добавляет переписать json (/(.*))?/?$ к каждому сообщению и постоянной ссылке на страницу. Таким образом, эти константы задают «местоположение» (то есть «в конце постоянной ссылки»), и они называются масками конечных точек (или масками ep).

Когда вы регистрируете тип записи, WordPress регистрирует permastructure - и связанную с ним маску конечной точки. Затем, когда создаются правила перезаписи, он также добавляет все правила перезаписи конечной точки, которые были добавлены к этой маске конечной точки.

Например, когда WordPress регистрирует тип записи «Страница» по умолчанию - он связывает маску конечной точки EP_PAGES с пермаструктурой страницы. Затем любые правила перезаписи конечной точки, добавленные в EP_PAGES, фактически добавляются в пермаструктуру этой страницы. Когда вы регистрируете тип сообщения, вы можете указать собственную маску конечной точки или использовать существующую. По умолчанию это EP_PERMALINKS - это означает, что любые правила перезаписи конечной точки, которые добавляются в EP_PERMALINKS, добавляются в правила перезаписи вашего пользовательского типа записи.

Конечно, вы можете не захотеть добавлять правила конечной точки для вашего типа поста (в этом случае вы можете использовать маску конечной точки EP_NONE), или вы можете захотеть добавить некоторые правила перезаписи конечной точки только к вашему типу поста. Для этого сначала нужно создать маску конечной точки, которая является не чем иным, как константой, которая удовлетворяет:

Значение константы представляет собой положительное число и степень 2: 2^x (например, 2097152 = 2²¹).
Это значение уникально

Требование степени 2 необходимо, потому что WordPress использует двоичную логику, чтобы определить, куда следует добавить правила конечной точки. К сожалению, это почти невозможно проверить, поэтому лучший совет - добавлять маски конечных точек только при необходимости и придавать им очень высокое значение (например, 2²¹). На момент написания 2⁰ до 2¹³ используются Core.

Определите маску конечной точки непосредственно перед регистрацией типа сообщения или таксономии:


	define('EP_BOOK', 8388608); // 8388608 = 2^23

	$args = array(
		'labels' => $labels,
		'has_archive'=>true,
		'rewrite' => array(
			'slug'=>'books'
			'with_front'=> false
			'feed'=> true
			'pages'=> true
			'ep_mask'=> EP_BOOK
		)
	);

	register_post_type('book',$args);

	// Then you can endpoint rewrite rules to this endpoint mask
	add_rewrite_endpoint('loan', EP_BOOK);

(Примечание. Выше используются аргументы WordPress 3.4. Если вы используете более старую версию WordPress, вам придется использовать устаревшую permalink_epmask.). Начиная с WordPress 3.4, вы также можете указать маску конечной точки при регистрации таксономии.

Краткое изложение

В этом уроке я рассмотрел основы API перезаписи для типов записей и таксономий, а также некоторые более сложные темы. Обработка переписываний в WordPress (обязательно) сложна, и лучший способ понять это - изучить исходный код и проверить его с помощью того, что вы узнали, и плагина анализатора перезаписи.

На данный момент есть пара заявок, проходящих через разработку WordPress Trac, касающихся API Rewrite. В будущем мы увидим гораздо более простой и бесконфликтный способ передачи масок конечных точек.