Создание пользовательских типов записей и пользовательских таксономий в WordPress по коду
Это руководство о том, как создать пользовательский тип записи и пользовательскую таксономию в WordPress с помощью кода. Мы рассмотрим распространенные ловушки и какие аргументы использовать для минимального, но достаточного создания. Полный пример в конце.
Куда добавить код
Создание пользовательских типов записей (CPT) и пользовательских таксономий в WordPress может быть выполнено внутри functions.phpфайла темы или внутри плагина. Имейте в виду, что пользовательский тип записи и пользовательская таксономия исчезнут, если вы переключите тему или деактивируете плагин. Так что безопасно временно удалить регистрацию CPT из темы и переместить ее в плагин — до тех пор, пока вы сохраняете тот же пользовательский тип сообщения или слаг / идентификатор идентификатора таксономии.
Для создания (и изменения) CPT или таксономии всегда используйте хук init. Размещение его в корне functions.php(вне хука) или в любом другом хуке вызовет проблемы.
Создание пользовательского типа записи
Для создания пользовательского типа записи вы используете register_post_typeфункцию. Он принимает два параметра; сначала идентификатор типа записи, а затем массив со всеми аргументами.
Идентификатор типа поста — это название версии вашего типа поста. Например, встроенные в WordPress типы сообщений и страницы обозначаются как ‘ post‘ и ‘ page‘. Идентификатор должен быть уникальным, он должен соответствовать набору правил (строчные буквы, без пробелов и т. д.) и не должен быть одним из зарезервированных слагов WordPress.
Это то, чему я научился, чтобы быть минимальными, но вполне достаточными аргументами для регистрации типа сообщения; учитывая, что это обычный общедоступный CPT, и вы хотите переопределить любые ярлыки, которые говорят «публикация» или «страница», с фактическим названием вашего CPT:
Обзор аргументов
Имейте в виду, что некоторые аргументы наследуют значения от других аргументов. Если они не установлены явно, они могут по умолчанию иметь то же значение или противоположное другому. Несколько аргументов наследуют одно и то же или противоположное значение аргумента public. Прочтите документацию, чтобы узнать, какое значение по умолчанию для каждого аргумента и нужно ли его переопределить.
Если вас устраивает наличие текстов в админке, которые ссылаются на ваш тип записи как на «публикацию» или «страницу», вы можете пропустить определение аргументов метки. Вам, вероятно, подойдет только label(имя во множественном числе) и только внутри labelsмассива singular_name(имя в единственном числе).
Если вы явно не установите show_in_restзначение true, ваш пользовательский тип pos будет использовать старый классический редактор. Если вы хотите использовать редактор Gutenberg для своего пользовательского типа сообщений, вам нужно установить show_in_restзначение true.
Аргумент supportsсообщает, какие элементы доступны при редактировании сообщения в вашем типе сообщения. Как минимум, вам, вероятно, понадобятся заголовок, редактор и избранное изображение поста.
Аргумент rewriteс минимальным элементом массива slugговорит WordPress переписать все единичные записи вашего типа, чтобы использовать этот префиксный слаг. В приведенном выше примере отдельная запись в книге получит такой URL-адрес; «http://example.com/book/i-robot/ ». Если вам интересно, как добавить настройку правила постоянной ссылки в админку, чтобы пользователи темы могли сами выбирать этот слаг, взгляните на этот пост.
Аргументом для значка меню (menu_icon) может быть любой из следующих Dashicons, или вы можете оставить его пустым, чтобы сохранить значение по умолчанию. По умолчанию используется тот же значок, что и для сообщений. Однако хорошей идеей будет четкое разделение ваших пользовательских типов сообщений.
Положение меню (menu_position) позволяет вам определить положение вашего пользовательского типа сообщения в меню администратора. В документации перечислены все позиции меню администратора, так что вы можете настроить; позиция 5 находится сразу после «Сообщений».
Есть еще один аргумент (taxonomies) для присоединения таксономии к типу записи. Позже в этом посте мы рассмотрим, как добавить пользовательскую таксономию. Чтобы добавить таксономии к вашему типу записи, добавьте этот аргумент в указанный выше массив;
Примечание о постоянных ссылках и ошибках 404 not found
После того, как вы добавите свой код для регистрации пользовательского типа сообщения, вы заметите, что просмотр одного сообщения вернет ошибку «404 не найден». Это потому, что вам нужно «обновить постоянные ссылки».
Перейдите в «Настройки» > «Постоянные ссылки» и просто нажмите кнопку «Сохранить изменения» (ничего менять не нужно).
Имейте в виду, что всякий раз, когда вы меняете rewriteатрибут, вам нужно будет снова обновлять постоянные ссылки.
Создание пользовательской таксономии
Пользовательская таксономия может быть прикреплена к одному из типов записей WordPress (сообщениям, страницам) или к пользовательскому типу сообщений. Вы также можете прикрепить несколько таксономий к типу записи. Когда вы регистрируете таксономию, вам необходимо указать тип(ы) записей, к которым вы хотите ее прикрепить.
Таксономия может быть либо иерархической (например, категории сообщений, где вы можете создать древовидную структуру), либо основанной на тегах (например, теги сообщений). Это действительно единственное соображение, которое вам нужно знать заранее, за исключением его идентификатора. Как и в случае с CPT, идентифицирующий ярлык таксономии должен быть уникальным и соответствовать набору правил.
Для регистрации пользовательской таксономии вы используете register_taxonomyфункцию. В register_taxonomyкачестве первого аргумента принимает слаг уникального идентификатора таксономии, в качестве второго — массив типов записей, к которым его нужно прикрепить, и, наконец, массив со всеми остальными аргументами. Есть много аргументов, но это то, что я считаю минимальным, но достаточным для регистрации пользовательской таксономии (это добавляет тип тега/неиерархическую таксономию):
Рекомендуется добавить вызов функции сразу после register_taxonomy, чтобы убедиться, что он правильно «привязан» к CPT: register_taxonomy_for_object_type. Определите свою таксономию в качестве первого аргумента и CPT в качестве второго:
register_taxonomy_for_object_type('book_author', 'book');Аналогично типу записи выше, register_taxonomyон принимает гораздо больше аргументов, и многие из них наследуют или зависят от значения других аргументов. Прочтите документацию, чтобы узнать, какое значение по умолчанию для каждого аргумента и нужно ли его переопределить.
Обзор аргументов
Если вы согласны с текстами, которые относятся к вашей таксономии как к «тегу» (если иерархический — ложно) или к «категории» (если иерархический — истинен), вы, вероятно, можете пропустить весь labelsмассив, за исключением, возможно, singular_name.
Это show_admin_columnудобно для добавления столбца, показывающего связанные термины в вашей таксономии на экране администратора CPT. Как и в сообщениях, вы видите столбец, показывающий связанные категории. По умолчанию для этого аргумента установлено значение false(не показывать столбец), поэтому мне нравится переопределять его.
Значение show_in_resttrue необходимо для того, чтобы ваша таксономия была видна при редактировании сообщений в редакторе Гутенберга, поскольку Гутенберг использует REST API.
Как и в случае с пользовательскими типами сообщений, вы, вероятно, получите ошибку «404 not found» в своей пользовательской таксономии. Перейдите в «Настройки» > «Постоянные ссылки» и просто нажмите кнопку «Сохранить изменения».
Полный пример кода
Вот полный пример создания CPT для книг и добавления двух пользовательских таксономий; жанр (иерархический) и автор книги (тег).