Опросить страницу в цикле для проверки типа шаблона или настраиваемых метаданных (Страницы против сообщений)

Я провел несколько дней, исследуя работу с статическими страницами WP – как отдельно от сообщений.

Хотя я нашел полезное руководство, я не могу найти каких-либо хороших обучающих программ или рабочих примеров, которые показывают мне, как работать со страницами, используя модифицированный Loop WordPress, который позволит мне фильтровать по определенным критериям страницы и извлекать соответствующий контент.

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

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

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

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

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

Мой главный вопрос: могу ли я допросить страницу, чтобы узнать о типе шаблона или пользовательских метаданных в цикле?

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

Предложения?

[Отредактировано 14 мая 2013 года для упрощения / уточнения]

Я бы создал пользовательский тип сообщений «События», а затем создал пользовательскую таксономию «Призыв к действию» и связал эту таксономию с пользовательским типом сообщения.

Таким образом, вы можете иметь неограниченное количество событий, которые могут быть связаны с терминами таксономии (ваш призыв к действию). Это имеет гораздо больший смысл, так как вы проецируете, что у вас будет несколько типов Call to Action (или терминов).

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

Сфокусируйте свое внимание на этой странице Codex здесь:

http://codex.wordpress.org/Class_Reference/WP_Query

… узнать больше о том, как запрашивать сообщения, по типу, таксономии и мета; не говоря уже о многом другом.

Ниже приведен пример настройки базового запроса для запроса по указанному типу и таксономии.

$args = array( 'post_type' => 'events', //this is a custom post type 'tax_query' => array( array( 'taxonomy' => 'calltoaction', //this is a custom taxonomy 'field' => 'slug', 'terms' => 'somecalltoactionterm' //a term within your taxonomy ) ) ); $query = new WP_Query( $args ); 

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

Соответствующее чтение:

Ввод @ userabuser дает полезное обсуждение использования пользовательских типов сообщений для решения проблемы настройки. Однако это все еще оставило без ответа мой главный вопрос:

Можно ли допросить тип шаблона страниц или настраиваемые метаданные в цикле?

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

Я в конечном итоге ответил на эту часть моего вопроса, и это оказалось довольно просто:

Я создал новый файл call-to-action.php для обработки страниц и файл шаблона pages_call-to-action.php:

 <?php $callstoaction = get_pages(array( 'meta_key' => '_wp_page_template', 'meta_value' => 'page_call-to-action.php', 'post_status' => 'publish,private', 'hierarchical' => 0, 'sort_column' => 'menu_order', 'sort_order' => 'ASC' ); ?> 

а затем цикл следующим образом:

 <?php foreach($callstoaction as $i => $calltoaction) : ?> // Do some stuff <?php endforeach; ?> 

Обратите внимание на пары meta_key и meta_value, которые идентифицируют атрибут шаблона страницы.

Это позволяет создавать стандартные страницы WordPress, устанавливать их шаблон через стандартный пользовательский интерфейс WordPress, чтобы быть «Call To Action» (page_call-to-action.php), а затем иметь возможность обрабатывать их конкретно в цикле обработки страниц, как я описал выше, избегая необходимости в настраиваемом типе сообщений.

Для справки, вот файл шаблона:

 <?php /** * Template Name: Call To Action * Description: Provides a basic template for call-to-action pages. */ get_header(); the_post(); ?> <div id="staticpage-single" <?php post_class() ?>> // template layout goes here </div> <?php get_footer(); ?> 

Единственный реальный недостаток, который я видел до сих пор в рассмотрении шаблонных статических страниц и пользовательских типов сообщений, заключается в том, что статические страницы WordPress «не включены в фид вашего сайта» (как указано в ссылке Codex ниже), однако Hesham Zebida отмечает (см. Ссылку ниже), что для решения этой проблемы доступен плагин «rss-includes-pages» 🙂

Смотрите также: