Тип запису повинен створюватися в момент хука-події init. Він не буде створено, якщо прикріпити функцію до init і може працювати неправильно, якщо використовувати після.
Як назва для нового типу записи потрібно вказувати унікальне ім'я, відмінне від уже наявних таксономій, типів записів і зарезервованих WordPress публічних і приватних змінних.
З версії 4.6 був створений новий клас WP_Post_Type і весь код функції тепер обробляється цим класом, а ця функція стала обгорткою для нього.
таксономії
Таксономії потрібно реєструвати окремо. Тобто незважаючи на те, що ви вказали таксономії при реєстрації нового типу записи, ви повинні окремо зареєструвати ці таксономії використовуючи register_taxonomy ().
Зарезервовані типи постів
Не можна використовувати такі назви для нових типів постів, так як вони використовуються WordPress:
- post. page. attachment. revision. nav_menu_item - типи постів WordPress;
- action. order. theme - назви, які використовуються у функціях WordPress.
Для уникнення конфліктів з уже використовуваними типами посад рекомендується використовувати префікс в назві нового типу поста або вказувати унікальну рядок.
Хукі з функції:
повертає
WP_Post_Type об'єкт (з версії 4.6).
Використання
Важливо: після створення нового типу записи. Обов'язково потрібно зайти в «Налаштування»> «Постійні посилання» і просто натиснути там кнопку «Зберегти зміни». Потрібно це для того, щоб правила ЧПУ були перестворювати і туди були додані правила нового типу записи.
Шаблон для створення нового типу записи
$ Post_type (рядок) (обов'язковий) Назва типу записи (максимум 20 символів). Може містити тільки рядкові символи, числа, _ або -. a-z0-9_-.
За замовчуванням: немає $ args (масив) Масив аргументів.
За замовчуванням: немає
Аргументи параметра $ args
label (рядок) Ім'я типу записи позначене для перекладу на іншу мову.
За замовчуванням: $ post_type
Масив містить в собі назви ярликів для типу запису.
Для нового типу записи, якщо для невстановлених рядків, будуть використані назви (ярлики) "постів" у не деревовидних типів і ярлики "постійних сторінок" деревовидних типів. Див. Get_post_type_labels ()
У масиві можна вказати наступні аргументи:
За замовчуванням: якщо не встановлено, name і singular_name ухвалять значення аргументу label
description (рядок) Короткий опис цього типу записи.
За замовчуванням: ''
Визначає чи є тип запису публічним чи ні. На основі цього параметра будуються багато інших, тобто це свого роду перед-установка для наступних параметрів:
- show_ui = false - Більше не показувати призначений для користувача інтерфейс (UI) для цього типу записів
- publicly_queryable = false - запити відносяться до цього типу записів не працюватимуть в шаблоні
- exclude_from_search = true - цей тип записів не враховуватиметься при пошуку по сайту
- show_in_nav_menus = false - цей тип записів буде захований з вибору меню навігації
- show_ui = true
- publicly_queryable = true
- exclude_from_search = false
- show_in_nav_menus = true
За замовчуванням: false
publicly_queryable (логічний) Запити відносяться до цього типу записів працюватимуть у фронтендів (в шаблоні сайту).
За замовчуванням: значення глобального аргументу (public)
Виключити цей тип записів з пошуку по сайту. 1 (true) - так, 0 (false) - немає.
За замовчуванням: зворотне значення аргументу public
Визначає чи потрібно створювати логіку управління типом записи з адмін-панелі. Чи потрібно створювати UI типу записи, щоб їм можна було управляти.
Так, наприклад, якщо вказати true. а в show_in_menu = false. То у нас буде можливість зайти на сторінку управління типом записи, тобто движок буде розуміти і обробляти такі запити, але посилання на цю сторінку в меню не буде.
За замовчуванням: значення аргументу public
Чи показувати тип запису в адміністраторському меню і де саме показувати управління типом записи. Аргумент show_ui потрібно включити!
- false - Більше не показувати в адміністраторському меню.
- true - показувати як меню першого рівня.
- рядок - показувати як підміню меню першого рівня, наприклад, підміню для 'tools.php' або 'edit.php? post_type = page' для довільних типів меню потрібно вказувати $ menu_slug см. add_menu_page ().
ЗАМІТКА: Якщо використовується рядок для того, щоб показати як підміню, якогось головного меню, створюваного плагіном, цей пункт стане першим в списку і відповідно змінить розташування пунктів меню. Для того, щоб цього не сталося, в плагін, який створює своє меню потрібно встановити пріоритет для дії admin_menu 9 або нижче.
За замовчуванням: null
show_in_admin_bar (логічний) Зробити цей тип доступним з адмін бару.
За замовчуванням: null (значення $ show_in_menu)
show_in_nav_menus (логічний) Включити можливість вибирати цей тип запису в меню навігації.
За замовчуванням: значення глобального аргументу
show_in_rest (логічний) Чи потрібно включати тип запису в REST API. З WP 4.7.
rest_base (рядок) Ярлик в REST API. За замовчуванням, назва типу записи. З WP 4.7.
За замовчуванням: $ post_type
rest_controller_class (рядок) Назва класу контролера в REST API. З WP 4.7.
За замовчуванням: 'WP_REST_Terms_Controller'
Позиція де має розташується меню нового типу записи:
За замовчуванням: null
Рядок яка буде маркером для установки прав для цього типу записи.
Вбудовані маркери це: post і page.
Можна передавати масив, де перше значення буде використовуватися для однини, а друге для множинного, наприклад: array ( 'story', 'stories'). Якщо передається рядок, то для множини просто додається 's' на кінці.
capability_type використовується для побудови списку прав, які будуть записані в параметр 'capabilities'.
При установці нестандартного маркера (НЕ post або page), параметр map_meta_cap можна встановити в true або в false:
- Якщо поставити true - то WordPress автоматично згенерує групу прав для параметра 'capabilities' на основі введених тут даних. При цьому зазначені в секції "Тайм capabilities 'права доповнять існуючий список прав.
- Якщо встановити false - то WordPress нічого генерувати не буде і вам доведеться самому повністю прописати всі можливі права для цього типу записи в секції "Тайм capabilities '.
За замовчуванням: "post"
Приклад: припустимо ми вказали тут рядок bill що рівносильно array ( 'bill', 'bills'). тоді WordPress автоматично згенерує наступні права для параметра 'capabilities':
Щоб подивитися які права були створені, загляньте в глобальну змінну: $ GLOBALS [ 'wp_post_types'] [ 'bill'].
Масив прав для цього типу записи.
За замовчуванням, доступні 8 елементів масиву, які визначають права для цього типу записів (навіть якщо map_meta_cap = false), це:
Існують ще 8 примітивних прав, що не мають прямого відношення до ядру. Але відносяться до функції map_meta_cap () і перевіряються там. Вони встановлюються автоматично, якщо вказано параметр map_meta_cap = true:
Цей capabilities параметр зазвичай встановлюється автоматично, спираючись на 'capability_type'. Наприклад якщо встановити 'capability_type' і 'map_meta_cap' і подивитися в змінну $ GLOBALS [ 'wp_post_types'] [ 'post_type']. то ми побачимо такий об'єкт:
де, s - це множина.
За замовчуванням: використовується аргумент capability_type для побудови списку дозволів
Замітка: якщо встановити в false, то стандартна роль "Адміністратор" не зможе редагувати цей тип запису. Для зняття такого обмеження доведеться додати право 'edit_s' до ролі адміністратор.За замовчуванням: false
Чи будуть записи цього типу мати деревоподібну структуру (як постійні сторінки).
За замовчуванням: false
Допоміжні поля на сторінці створення / редагування цього типу записи. Мітки для виклику функції add_post_type_support ().
За замовчуванням: array ( 'title', 'editor')
register_meta_box_cb (рядок) callback функція, яка буде спрацьовувати при установки мета блоків для сторінки створення / редагування цього типу записи. Використовуйте remove_meta_box () і add_meta_box () в callback функції.
За замовчуванням: немає
Масив зареєстрованих таксономій, які будуть пов'язані з цим типом записів, наприклад: category або post_tag.
Зв'язати таксономії із записом можна пізніше через функцію register_taxonomy_for_object_type ().
Таксономії потрібно реєструвати за допомогою функції register_taxonomy ().
За замовчуванням: немає
Індекс кінцевої точки, з якої буде асоційований створюваний тип запису. Як правило цей параметр не використовується. Тут можна вказати слід. константи або їх комбінацію з'єднану через :
Кінцева точка - це те що додається в кінець URL, наприклад / trackback /. Кінцеві точки прикріплюються до типу записи (додаються в правила перезапису) за допомогою функції add_rewrite_endpoint ().
Цей параметр дозволяє вказати, яку групу кінцевих точок ми хочемо підключити до створюваного типу записи (до URL записи). Наприклад, якщо вказати 'permalink_epmask' = EP_PAGES EP_TAGS. то наш тип запису буде мати всі кінцеві точки, які передбачені для постійних сторінок і міток.
За замовчуванням permalink_epmask = EP_PERMALINK - це означає, що в URL створюваного типу записи (в правила ЧПУ) будуть додані кінцеві точки, які додаються до звичайних записів WordPress.
Якщо не потрібно додавати ніяких кінцевих точок до нового типу записи, то потрібно вказати EP_NONE. Або вказуємо EP_ALL. коли потрібно додати всі кінцеві точки.
За замовчуванням: EP_PERMALINK
Включити підтримку сторінок архівів для цього типу записів (пр. УРЛ записи виглядає так: site.ru/type/post_name. Тоді УРЛ архіву буде такою: site.ru/type.
Якщо вказати рядок, то вона буде використана в ЧПУ. Наприклад, вкажемо тут typepage і отримаємо посилання на архів типу записи такого виду: site.ru/typepage
Файл цього архіву в темі буде мати вигляд archive-type.php). Для архівів буде додано нове правило ЧПУ, якщо аргумент rewrite включений.
За замовчуванням: false
Чи використовувати ЧПУ для цього типу записи. Щоб не використовувати ЧПУ вкажіть false. За замовчуванням: true - назва типу записи використовується як префікс в засланні. Можна в масиві вказати додаткові параметри для побудови ЧПУ:
slug (рядок)
Префікс в ЧПУ (/ префікс / ярлик_запісі). Використовуйте array ( 'slug' => $ slug). щоб створити інший префікс.
У цьому параметрі можна вказувати плейсхолдери типу% category%. Але їх потрібно створити за допомогою add_rewrite_tag () і навчити WP їх розуміти.
За замовчуванням: назва типу записи
with_front (логічний)
Чи потрібно в початок вставляти загальний префікс з налаштувань. Префікс береться з $ wp_rewite-> front. Наприклад, якщо структура постійних посилань записів в настройках має вигляд blog /% postname%. то при false отримаємо: / news / названіе_поста. а при true отримаємо: / blog / news / названіе_поста.
За замовчуванням: true
feeds (логічний)
Додати чи правило ЧПУ для RSS стрічки цього типу записи.
За замовчуванням: значення аргументу has_archive
Додати чи правило ЧПУ для пагінацію архіву записів цього типу. Пр: / post_type / page / 2.
За замовчуванням: true
За замовчуванням: true (тип запису використовується як префікс)
query_var (рядок / логічний) Ставимо false, щоб прибрати можливість запитів або встановлюємо назву запиту для цього типу записів.
За замовчуванням: true - встановлюється аргумент $ post_type
can_export (логічний) Можливість експорту цього типу записів.
За замовчуванням: true
true - видаляти записи цього типу належать користувачеві при видаленні користувача. Якщо включена кошик, записи не віддалятися, а помістяться в кошик.
false - при видаленні користувача його записи цього типу Ніяк не будуть оброблятися.
null - записи віддалятися або будуть переміщені в кошик, якщо post_type_supports ( 'author') встановлена. І не оброблені, якщо підтримки 'author' у типу запису немає.
За замовчуванням: null
_builtin (логічний) Для внутрішнього використання! True, якщо це вбудований / внутрішній типу записи.
За замовчуванням: false
_edit_link (рядок) Для внутрішнього використання! Частина URL в посиланні на редагування цього типу записи.
За замовчуванням: 'post.php? Post =.'
# 1 Реєстрація нового типу записи
Приклад реєстрації довільного типу записів "book". Також в прикладі показано як включити повідомлення при оновленні і підтримку розділу допомогу.
Розділ "допомогу" типу запису book:
# 2 Додавання елемента таксономії в ЧПУ
Для нового типу запису можна вказати різні ЧПУ за допомогою параметра rewrite. Цей приклад показує, як додати в ЧПУ нового типу записи таксономию.
Для цього потрібно вказати аргумент slug в параметрі rewrite при реєстрації типу записи:
Тепер потрібно додати хук, щоб замінювати% products% при отриманні посилання на запис через функцію get_permalink () і похідні від неї функції:
# 3 Додавання таксономії в ЧПУ
Цей приклад показує як створити запис типу Питання і розділи для неї. При цьому ЧПУ будуть:
Плагін для реги типу записи
Є зручний плагін, який дозволяє реєструвати нові типи записів (постів) і нові таксономії: Custom Post Type UI
Перейменування заголовків типу записи
Якщо тип запису вже зареєстрований, але нам потрібно назвати його якось інакше, використовуйте наступний код.
Цей код показує, як перейменувати стандартний тип запису "Записи" в "Статті":
Код register post type. wp-includes / post.php WP 4.8.3
cвязана функції
З мітки: Розширення движка addons
Зробив новий тип записів, створив рубрики, створюю пост, вибираю рубрику - все ок. Отримую url по типу site / custposttupe / namecat / namepost а ось якщо змінити рубрику, пост буде доступний як за посиланням site / custposttupe / namecat / namepost так і за новою посиланням site / custposttupe / namecat-2 / namepost. Як би це вилікувати? Дублі не їсти гуд. Дякуємо.