Использование /% postname% для пользовательского типа сообщения

У меня есть настраиваемый тип сообщения, постоянная ссылка которого должна находиться в том же пространстве, что и страницы:

/an-example-thing <-- custom post type 'thing' /about-the-things <-- a normal page 

Я хорошо знаю, что это не рекомендуемый способ сделать это , но у меня нет выбора – именно это и указал клиент.

Я создал пользовательские типы с register_post_type и использовал плагин Custom Post Permalinks, чтобы установить их постоянную ссылку следующим образом:

 /%thing%/ 

Однако это создает конфликт между правилом, которое распознает мои пользовательские сообщения, а другое – для обычных страниц, что превращает все обычные страницы в 404. Эта проблема исчезает, когда постоянная ссылка изменяется на что-то вроде этого:

 /things/%thing%/ 

Использование анализатора переименования Monkeyman показывает, что правило для настраиваемого сообщения идет первым. Даже когда я пытаюсь заставить его использовать подробные правила:

 global $wp_rewrite; $wp_rewrite->use_verbose_page_rules = true; 

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

Я бы хотел, чтобы он сначала искал вещи , и когда никого не найдено с этим именем, найдите страницы. Другой способ был бы приемлемым. Нет ли способа убедить его искать и вещи, и страницы, прежде чем ударить 404?

Solutions Collecting From Web of "Использование /% postname% для пользовательского типа сообщения"

Вы начинаете с одной бонусной точки для использования моего анализатора перезаписи 🙂

Действительно, даже если вы используете подробные правила страницы, поскольку версия 3.1 (или что-то в этом роде), правила переписывания таксономии появляются еще до этого. Недавно я ответил на другой вопрос , чтобы переместить их на вершину. Это должно работать, если вы не против иметь подробные правила страницы (если у вас не более 25 страниц или около того).

Если вам не нужны подробные правила страницы, вам придется расширить основной класс WP чтобы он мог работать с «неоднозначными» ситуациями, когда URL-адрес может ссылаться на страницу или собственный тип сообщения. Майк однажды предоставил хороший способ сделать это . Его ответ написан для пользовательской таксономии, но он также должен быть адаптирован к настраиваемому типу сообщений.

Я нашел одно решение, но это действительно уродливо: подключитесь к маршрутизации 404, чтобы доставить страницу, которая должна быть доставлена. Код немного сложный, потому что у меня также есть многопользовательский префикс.

Тема / 404.php

 <?php global $current_blog; $prefix = $current_blog->path; $path = $_SERVER['REQUEST_URI']; $path = preg_replace("!^$prefix!i", "", $path); $path = preg_replace("!\?.*$!i", "", $path); $path = trim($path, '/'); $page = get_page_by_path($path); if (isset($page)) { $template = get_post_meta($page->ID, '_wp_page_template', true); if (empty($template)) $template = get_page_template(); query_posts("post_type=page&id={$page->ID}"); include($template); die; } ?> ...actually handle a 404... 

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

Для решения этой проблемы есть два плагина.

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

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

Я получил оба из них, чтобы работать, хотя первоначально мне приходилось отлаживать с помощью Monkeyman Rewrite Analyzer, потому что некоторые другие правила мешали.