WordPress использует посты и страницы для предоставления динамического контента для приложений. Введение пользовательских типов постов увеличило возможности разработки сложных приложений с WordPress.
Как правило, обычные сообщения проходят четко определенный рабочий процесс, прежде чем они будут опубликованы на веб-сайте или в приложении. Во время этого рабочего процесса различные статусы присваиваются постам и обрабатываются внутри WordPress.
Почтовые статусы могут использоваться как мощный метод управления статусом в пользовательском веб-приложении. В этой статье мы собираемся обсудить, как использовать пользовательские статусы и переходы WordPress для создания приложений, которые выходят за рамки обычных веб-сайтов или блогов.
У вас есть опыт работы с пользовательскими изменениями статуса поста? Все вы можете обсудить свой опыт.
Понимание статуса сообщения WordPress
WordPress использует таблицу wp_posts для хранения как постов, так и страниц. Статус сообщения определяет временное состояние, пока оно не будет опубликовано на сайте. Как правило, статус сообщения начинается как черновик и переключается между существующими статусами, пока не дойдет до опубликованного статуса. Давайте посмотрим на существующий список статусов постов WordPress и их роли.
- опубликовать — сообщение считается опубликованным и будет общедоступным на веб-сайте.
- в ожидании — сообщение ожидает рассмотрения от более высокой роли пользователя. Этот статус будет в основном доступен на сайте, где у вас есть несколько авторов или пользователей, которые могут создавать записи в таблице
wp_post. - черновик — сообщение временно сохраняется, и автор сообщения может внести дальнейшие изменения перед публикацией.
- черновик — публикация временно сохраняется без содержания, и автор может внести дополнительные изменения перед публикацией.
- будущее — публикация запланирована на будущее. Это общепринятая техника, чтобы поддерживать последовательность публикации.
- приватный — пост виден только зарегистрированным пользователям.
- наследовать — это считается ревизия сообщения. WordPress позволяет несколько ревизий одного и того же поста.
- мусор — пост считается удаленным.
Обычно каждый пост начинается с чернового или автоматического черновика и продолжается до тех пор, пока не достигнет желаемого конечного состояния. В следующем разделе мы рассмотрим изменения статуса сообщений WordPress и их использование.
Работа с пост-статусными переходами
Переход между состояниями — это процесс переключения между состояниями. Обычно существующие почтовые переходы и соответствующие им функции обрабатываются внутри WordPress. Но есть много эффективных способов добавления функций с пост-переходами. В результате WordPress теперь предоставляет хуки для работы со всеми переходами статуса поста; поэтому мы можем динамически добавлять новые функции при переходе сообщения.
Давайте посмотрим, как это на самом деле работает.
Предположим, что мы хотим что-то сделать, когда статус сообщения меняется с черновика на будущее . В следующем коде показано, как реализовать переход статуса публикации для предыдущего требования.
|
1
2
3
4
|
function callback_function_name( $new_status, $old_status, $post ) {
// Code here
}
add_action( ‘draft_to_future’, ‘callback_function_name’, 10, 3 );
|
WordPress предоставляет хук действия в формате {old-status} _to_ {new-status} для каждого пост-перехода. Мы можем использовать функцию обратного вызова для предоставления пользовательских функций. Эта пользовательская функция принимает в качестве параметров старое состояние, новое состояние и измененный объект публикации.
В предыдущем разделе мы обсудили около восьми предопределенных статусов сообщений. Здесь у нас есть девять статусов сообщений для переходов, включая статус, называемый новым . Прежде чем сообщение будет сохранено, оно будет считаться новым. Как только запись будет сохранена в базе данных, произойдет переход из new_to_ {пользовательский статус} .
Теперь давайте посмотрим переходы публикации для публикации сообщения в нормальных условиях.
На предыдущем экране показаны пост-переходы сайта с одним автором. По сути, мы можем работать с переходами статуса поста между состояниями, соединенными стрелками. На веб-сайте одного автора пост-переходы проще по сравнению с веб-сайтами с несколькими авторами.
Итак, давайте посмотрим на процесс создания сайта с несколькими авторами.
На веб-сайте с несколькими авторами процесс немного изменился, поскольку все публикации должны быть проверены и утверждены уполномоченным лицом перед публикацией; поэтому веб-сайты с несколькими авторами имеют дополнительный шаг в процессе постперехода.
До сих пор мы рассматривали переходы статуса сообщений по умолчанию на веб-сайте WordPress. Теперь вопрос в том, как эти переходы будут полезны?
Существует множество способов использования переходов между постами в приложениях. Давайте посмотрим на некоторые из наиболее часто используемых функций в переходах статуса поста.
- Draft to Pending — уведомить редактора о необходимости просмотреть сообщение.
- В ожидании будущего — оповестить автора сообщения.
- В ожидании будущего — добавьте сообщение к календарю на сайте.
- Будущее для публикации — уведомить подписчиков по электронной почте.
Это некоторые из самых основных и распространенных функций, выполняемых во время постпереходов. До сих пор мы рассматривали процесс перехода статуса поста для предварительно определенных статуй.
Реальная ценность переходов статуса поста заключается в использовании пользовательских статусов постов. В следующем разделе рассматриваются детали работы с пользовательскими статусами сообщений для пользовательских веб-приложений.
Введение в пользовательский статус сообщения
WordPress постепенно становится основой для разработки веб-приложений, выходя за рамки общей системы управления контентом. Пользовательский статус поста становится жизненно важным для разработки сложных приложений. WordPress позволяет нам создавать собственные почтовые статусы и поддерживает переходы между этими статусами. Давайте посмотрим на следующий код для создания пользовательского статуса сообщения.
|
1
2
3
4
|
function add_custom_post_status() {
register_post_status( ‘custom_status’, $args );
}
add_action( ‘init’, ‘add_custom_post_status’ );
|
Пользовательские статусы сообщений могут быть определены с помощью функции register_post_status , которая принимает имя статуса сообщения в качестве обязательного параметра. Этот синтаксис похож на код, используемый для создания пользовательских типов записей. Также мы можем передавать дополнительные аргументы в зависимости от наших предпочтений. Вы можете найти полный список аргументов в Кодексе WordPress . После использования вышеуказанного кода новый пользовательский статус записи будет добавлен в существующий список.
К сожалению, панель администратора WordPress не имеет встроенной поддержки пользовательских статусов сообщений; поэтому мы должны найти альтернативные способы добавления пользовательских статусов сообщений в панель администратора.
Объяснение процесса интеграции пользовательского статуса сообщения в панель администратора выходит за рамки этой статьи, поэтому я собираюсь использовать существующий плагин, чтобы показать вам, как работать с пользовательскими статусами.
Интеграция пользовательского статуса сообщения в панель администратора
По сути, нам нужно настроить существующее метабокс публикации сообщений администратора, чтобы в настраиваемом поле « Статус» отображались пользовательские статусы сообщений. На данном этапе поддержка этой функции в WordPress очень ограничена, и поэтому сложно найти качественные плагины для работы с пользовательскими статусами постов.
Мы можем использовать плагин Edit Flow для управления пользовательскими статусами сообщений. Вы можете получить копию этого плагина с http://wordpress.org/plugins/edit-flow/ . После активации перейдите в раздел « Пользовательские статусы » в меню « Редактировать поток», и вы увидите экран, подобный следующему.
Мы можем использовать эту форму для создания новых пользовательских статусов сообщений. Этот плагин внутренне использует функцию register_post_status для определения пользовательского статуса и сохраняет его в таблице wp_terms . Все управление статусами осуществляется внутри плагина.
В идеале мы хотели бы, чтобы эти функции были доступны в ядре WordPress. После создания вы найдете список новых статусов, как показано на следующем экране.
Теперь статусы готовы, и вы можете перейти к экрану создания сообщения и выбрать необходимый статус перед сохранением сообщения. Затем вы можете реализовать переходы статуса в сообщении, чтобы добавить дополнительные функции или управлять существующими функциями.
Использование изменений состояния в пользовательских веб-приложениях
Нам нужно использовать пользовательские типы записей в пользовательских веб-приложениях. Пользовательские статусы сообщений играют жизненно важную роль в управлении пользовательскими типами сообщений.
Обычно существующие типы записей имеют очень ограниченное значение при работе с пользовательскими типами записей; поэтому нам нужно использовать пользовательские переходы статуса для управления состоянием пользовательских сообщений. Давайте рассмотрим практические сценарии для понимания необходимости пользовательских статусов сообщений.
Система онлайн-продажи товаров
В эти дни большинство продуктов продаются в Интернете с помощью корзин. Существует множество существующих сайтов WordPress для продажи товаров. В такой системе нам нужен специальный тип записи под названием «Продукты» для хранения всей информации о продуктах.
Теперь подумайте, как мы можем сопоставить существующие почтовые статусы с продуктами. Статусы, такие как черновик , будущее и ожидающие , не имеют значения в контексте продуктов. Поэтому нам нужны пользовательские статусы, чтобы удовлетворить такие сценарии. Давайте подумаем о возможных статусах для продуктов.
Обычно мы можем использовать статусы « В наличии» , « Заказано» , « Отгружено» , « Доставлено» и « Возвращено» для продуктов. Давайте посмотрим на следующий экран для возможных изменений статуса.
Продукт начинается со статуса В наличии и заканчивается статусом Доставлено или Возвращено . Каждый переход состояния может использоваться для выполнения различных задач. Например, когда статус Продукта изменяется с В наличии на заказ , мы можем обновить значения запасов. Таким образом, действие, которое будет использоваться для этого сценария: {В наличии} _to_ {заказано} . Мы можем выполнять аналогичные действия для других переходов статуса, чтобы улучшить процесс.
Система управления библиотекой
Это еще один сценарий, когда пользовательские статусы становятся очень важными. В библиотечной системе статус книги изменяется в соответствии с действиями, выполняемыми членами библиотеки. В такой системе книга может иметь статусы Заимствовано , Продлено , Доступно и Просрочено . Давайте рассмотрим следующий экран для возможных изменений статуса.
В этом сценарии переходы статуса стали намного более сложными по сравнению с предыдущим сценарием. Книга начинает свой процесс из Доступного состояния и переключается между другими состояниями, пока не вернется обратно в Доступное состояние. Давайте рассмотрим сценарий использования переходов между постами в этой системе.
Как правило, существует максимальное количество продлений одной книги. Поэтому, когда статус книги изменится с « Продлен» на « Доступен» , мы можем проверить учетную запись участника, чтобы убедиться, что участник уже достиг максимального предела, и заблокировать дальнейшее продление участника.
Здесь мы обсудили два сценария необходимости пользовательских переходов статуса. Реальные приложения намного сложнее, и, следовательно, вы найдете много случаев необходимости пользовательских переходов между состояниями.
Заворачивать
Переходы после состояния — это очень мощный способ добавления новых функций или управления рабочим процессом в приложениях, но у этого метода есть некоторые недостатки. Рассмотрим ситуацию, когда вам нужно отправить большое количество уведомлений за один переход статуса сообщения.
В таких случаях вы не сможете завершить переход статуса, пока не будут отправлены все уведомления, поэтому публикация сообщений станет сложной задачей. Как правило, переходы после статуса не должны использоваться для обширных процессов, которые занимают значительное количество времени. Это зависит от вас, чтобы сделать правильный выбор в зависимости от требований.
Теперь у меня есть несколько вопросов к вам, и я надеюсь, что вы все можете поделиться своими знаниями, ответив на эти вопросы:
- Вы хотите, чтобы WordPress поддерживал пользовательские статусы по умолчанию? и почему?
- Каковы другие практические сценарии реального использования переходов между постами?
- Какие типы функций вы хотели бы предоставить при смене статуса поста?
- Как вы планируете реализовать обширный процесс с переходами статуса поста?
С нетерпением жду Вашего ответа.