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

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

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

Когда вы регистрируете пользовательский тип, WordPress также регистрирует правила перезаписи (на самом деле, не совсем , и я объясню почему в разделе «Permastructures»). Как упоминалось в первой части, эти правила будут включены только после того, как правила перезаписи будут «сброшены». Темы и плагины могут вызвать эту « flush_rewrite_rules() », вызывая 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 для switch_theme .

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

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

slug — слаг, используемый для определения типа записи в URL. К этому сообщению добавляется слаг для поста, например, www.example.com/ books /the-wizard-of-oz
with_front — true или false. Если структура постоянных ссылок вашего поста начинается с постоянной базы, такой как ‘/ blog’ — это также можно добавить к структуре постоянных ссылок вашего пользовательского типа поста, установив для нее значение true, например, true даст www.example.com/blog/books/ и false www.example.com/books/
feeds — правда или ложь. Создавать ли правила переписывания www.example.com/books/feed/rss например, www.example.com/books/feed/rss и www.example.com/book/rss . Значением по умолчанию является значение has_archive .
pages — правда или ложь. Создавать ли правило для «милой» нумерации страниц для архива типов записей, например, 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);

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

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

Taxonomies

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

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

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

www.example.com/genre/military-history

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

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

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

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

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

Почтовые архивы

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

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

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

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 — уникальный слаг для идентификации вашей пермаструктуры
struct — сама permastructure, например, ‘ %year%/%category%/%author% ‘
with_front — true или false. Это тот же аргумент, что и при регистрации типа сообщения
ep_mask — см. раздел маски EP ниже

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

‘something-hard-coded/%year%/%monthnum%/%day%’

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

www.example.com/2012/page/2

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

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

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

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

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

global $wp_rewrite;
$wp_rewrite->add_rewrite_tag(‘%book_cpt%’,'(book)s’,’post_type=’);

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

www.example.com/books?year=2012

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

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 не заменяет эти теги соответствующими значениями при создании постоянных ссылок — нам нужно заменить их самим. Однако использование таких тегов также нарушает страницу архива типа записи, поэтому мы будем использовать другой метод. В качестве примера, давайте предположим, что мы хотим, чтобы наш пользовательский тип записи «книга» имел структуру:

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 фильтр 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] (чего мы не делаем)

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

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

EP_Masks

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

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

add_rewrite_endpoint( ‘form’, EP_PAGES );

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

add_rewrite_endpoint( ‘json’, EP_PAGES | EP_PERMALINKS);

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

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

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

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

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

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

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

define(‘EP_BOOK’, 8388608);
 
$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. В будущем мы увидим гораздо более простой и бесконфликтный способ передачи масок конечных точек.

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

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

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

Taxonomies

Почтовые архивы

Permastructures

Функция `add_permastruct`

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

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

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

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

EP_Masks

Резюме

Категории

Последние статьи

Рефакторинг Hudson God Class

Альтернативы синтаксиса Java лямбда

Morphia и MongoDB: развивающиеся структуры документов

OpenShift Express: развертывание приложения Java EE (с поддержкой AS7)

Интеграция jqGrid, REST, AJAX и Spring MVC

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

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

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

Taxonomies

Почтовые архивы

Permastructures

Функция add_permastruct

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

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

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

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

EP_Masks

Резюме

Категории

Последние статьи

Рефакторинг Hudson God Class

Альтернативы синтаксиса Java лямбда

Morphia и MongoDB: развивающиеся структуры документов

OpenShift Express: развертывание приложения Java EE (с поддержкой AS7)

Интеграция jqGrid, REST, AJAX и Spring MVC

Функция `add_permastruct`