Intereting Posts

Групповая маршрутизация и администрирование

Клиент требует, чтобы веб-сайт, который он заказывал, использует групповую систему для навигации и администрирования. Группа Eeach эффективно представляет отдел в компании, и будет довольно небольшое количество групп. Сначала я просто хочу упомянуть, что плагин BuddyPress действительно не соответствует всем требованиям.

Требования:

  1. Каждой группе назначается менеджер группы, который может создавать контент (сообщения разных типов)
  2. example.com/group_name приведет к групповому хабу, где будет какая-то базовая информация о группе, несколько общих запросов, загружающих последние сообщения для этой группы и некоторые другие вещи, строго связанные с группой
  3. example.com/group_name/news приведет к странице запроса, отображающей последние сообщения новостей, созданные группой (другие типы сообщений также будут иметь свои страницы запросов)
  4. Менеджер группы может создавать сообщения только для своей группы, и они должны быть рассмотрены руководителем перед публикацией (разрешимой определенными ролями пользователя)
  5. Должности должны иметь структуру url example.com/group_name/news/post_name
  6. Они также хотят, чтобы каждая группа имела собственное меню и логотип и подстраницы, например example.com/group_name/about
  7. Я также не могу использовать вариант многостраничного WordPress, потому что домашняя страница похожа на глобальный хаб, то есть что-то из всех групп получает там. Это, например, последние новости по всем группам, и они должны быть разбиты на страницы и так далее. Там также должна быть страница, например example.com/news где вы можете отфильтровать, какую группу вы интересуете и т. Д.

Первый подход:

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

 register_taxonomy( 'groups', ['post', 'user'], [ 'public' => 'true', 'labels' => $labels, 'hierarchical' => true, 'capabilities' => [ 'manage_terms' => 'edit_users', 'edit_terms' => 'edit_users', 'delete_terms' => 'edit_users', 'assign_terms' => 'edit_users', ] ] ); 

Затем я создал некоторые основные правила перезаписи:

 $groups = get_terms([ 'taxonomy' => 'groups', 'hide_empty' => false ]); foreach ($groups as $group) { add_rewrite_rule($group->slug . '/?$', 'index.php?&pagename=group&groups=' . $group->slug, 'top'); } add_rewrite_rule('([^/]*)/news/?$', 'index.php?post_type=post&groups=$matches[1]' , 'top'); add_rewrite_rule('([^/]*)/news/([^/]*)/?$', 'index.php?groups=$matches[1]&name=$matches[2]&post_type=post' , 'top'); 

И настройте создание пользовательской ссылки:

 function __custom_post_link($link, $post, $leavename = true) { $terms = get_the_terms($post, 'groups'); if (!$terms) return $link; $term = $terms[0]->slug; if ($post->post_type == 'post') { $link = str_replace($post->post_name, $term .'/news/' . $post->post_name, $link); } return $link; } add_filter('post_type_link', '__custom_post_link', 10, 3); 

Но здесь я остановился, потому что понял, что лучше использовать пользовательский post_type . Поскольку мне нужно будет отобразить некоторую дополнительную информацию на страницах группового хаба, мне, вероятно, придется хранить некоторую мета-информацию из сообщения. Мне также кажется, что было бы проще использовать собственный тип сообщений, чтобы обойти проблему основной маршрутизации с помощью example.com/group_name . Также должно быть возможно установить страницу в качестве ребенка для пользовательской почты, правильно? Если это так, чтобы разрешить такие вещи, как example.com/group_name/news .

Вопрос. Создавая систему, сосредоточенную вокруг набора групп с указанными выше требованиями, считаете ли вы, что лучше использовать пользовательскую таксономию или настраиваемый тип сообщений? Или есть еще лучший способ?

Solutions Collecting From Web of "Групповая маршрутизация и администрирование"