Как работает маршрутизация на WordPress?

Как работает ядро wp маршрутизации? Мне трудно понять ... В MVC ваш URL выглядит как mycontroller / myaction, который отображается на MyController-> myaction ()

В drupal это index.php? Q = mycustomerpath / hello, который можно сопоставить с любой понравившейся вам функцией, которая возвращает контент, «тематический», в макет вашей темы.

Но в wp я понятия не имею, как все делается ... это? P = 1, то? Product = 1 ... Я искал документацию о потоке маршрутизации, но не могу найти какой-либо (Google просто возвращает статьи на заказ маршруты) .. я хочу понять основы основной маршрутизации в первую очередь ..

urls routing

— Да, чувак
источник

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

— Да,

Содержимое сохраняется как пост в WP. Итак, когда вам нужно показать содержимое, вам нужно запросить его

— Sisir

Позвольте мне предложить вам прочитать о «цикле» - концепции, которую вам необходимо понять, чтобы знать, как работает WordPress. Существенный «цикл» отображает массив сообщений, который является результатом query_posts. Для неадресных URL-запросов WP предназначен для показа только постов, и для показа чего-то, кроме поста, требуется специальное программирование. Запросы URL-адресов администратора отличаются, и они не используют «цикл» и не показывают сообщения.

хорошо, но этот подход немного странный и не очень гибкий tbh

— yeahman

скажем, я хочу, чтобы отобразить контактную форму .. мне нужно поместить мой HTML в тип контента страницы? Я все еще пытаюсь найти, где разместить логику для отправки формы ... (в теме page.php? Очень уродливый подход)

— yeahman

В WordPress URL не отображаются на маршруты. Они отображаются на запросы к базе данных.

При использовании WordPress в режиме постоянных ссылок «по умолчанию» в основном URL-запросе есть набор переменных, например? P = 1 или? Page = 234 и т. Д. Там же? S = search и многие другие.

Если вы используете «симпатичные» постоянные ссылки, то создается большой набор правил, называемый «правила перезаписи», который напрямую сопоставляет различные шаблоны URL с этим же набором параметров URL. Таким образом, URL-адрес, например / 2014/04/12 / example, будет сопоставлен с? Year = 2014 & month = 04 & day = 12 & postname = example или аналогичным. Так что следующее применимо и к ним, после того, как это сопоставление выполнено.

Эти переменные по сути управляют основным экземпляром класса WP_Query. Класс WP_Query содержит всю информацию, которая формирует запрос к базе данных, чтобы получить «сообщения» из базы данных. Различные параметры, передаваемые в него, определяют, какой запрос он создает и какие данные он получает.

Видите, все, что может отображать WordPress, по сути является "постом". Блог - это серия постов в обратном порядке. «Страница» - это статический пост с определенным именем. «Пользовательский тип записи» - это именно то, на что это похоже, «публикация» с пользовательским типом, который вы определяете. Все основные запросы для отображения чего-либо в WordPress получают некоторое подмножество сообщений из таблицы wp_posts.

WP_Query это то, что делает. И параметры из URL отправляются непосредственно в этот основной запрос и используются там.

Затем тема определяет, какой шаблон использовать, основываясь на том, с чем возвращается запрос. Если вы запросили / category / example, то это станет? Category_name = example, что означает, что основной массив $ wp_query-> query_vars получит эту информацию, а WP_Query извлечет последние X сообщений для категории «example», и это установит для своего флага is_category значение true.

После этого загрузится шаблонный загрузчик, увидит, что is_category () возвращает true, и решит выбрать шаблон категории, поэтому он будет искать category-example.php и вернуться к category.php и так далее, в соответствии с шаблоном Иерархия.

Итак, вопрос, хотите ли вы изменить работу URL-адресов, прост: хотите ли вы изменить URL-адреса или на что они отображаются? Поскольку URL-адреса не сопоставлены с функциями, они сопоставлены с параметрами, которые управляют запросом. Если вы хотите, чтобы URL корректировал этот основной запрос, то это немного другой процесс, чем если вы хотите, чтобы специальный URL запускал какой-то совершенно другой специальный код.

И чтобы ответить на ваш конкретный вопрос в комментариях: «разве нет случаев, когда вы на самом деле не хотите показывать сообщения?» Нет, нет Все это пост. Весь контент хранится в постах. Если вы хотите хранить контент в другом месте и отличаться от других, вы можете сделать это, но это сложнее, потому что, честно говоря, обычно это не нужно. Если у вас есть специальный контент, создайте пользовательский тип публикации, сохраните контент как публикацию с этим типом, сопоставьте шаблон URL с ним. Легко.

— эфирное масло
источник

Я понимаю, что все должно быть представлено в сообщении (через пользовательские типы сообщений и т. Д.), Очень похожее на пользовательские типы в drupal 6 ... но влияет ли это на производительность, когда в одной таблице сообщений хранится каждый отдельный контент сайта? drupal 7 решил эту проблему, введя тип сущности, так что вам не нужно создавать пользовательский тип и хранить все в таблице узлов, но в собственной таблице сущностей, которая все еще может использовать инфраструктуру drupal. Я надеюсь, что WordPress представит такой подход в будущем. Спасибо за подробное объяснение.

— Да,

Я думаю, если я хочу сопоставить URL с моей собственной функцией / темой, wp router поможет?

— Да,

Добавление полной системы маршрутизации обычно не требуется. Есть более простые способы. Основой WordPress является отображение пользовательского контента, который все хранится в таблице постов. Если вы хотите отображать контент, который не генерируется пользователем, вы обычно делаете это в теме или в плагине. Существуют сотни (тысячи) хуков и фильтров действий и других способов, позволяющих коду переопределять различные части процесса при создании страницы. А с такими вещами, как шорткоды, вставить собственный html в контент относительно легко.

— Отто

Как добавить пользовательский HTML / PHP в тип сообщения, которое я создал? без изменения темы single.php или создания single-mycustompost.php (не очень переносимый подход)

— yeahman

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

— да