fredericl
  • 0
Новичок

Как обрабатывать иерархию с пользовательскими типами записей

  • 0

Я перешел на WordPress на несколько дней и был очень впечатлен всеми доступными функциями, плагинами и отточенными темами. Я потратил довольно много времени на чтение документации о темах и пользовательских типах. Пока все хорошо… Теперь, когда я пытаюсь делать реальные вещи, кажется (хотя я, возможно, что-то упускаю), что WP имеет некоторые серьезные ограничения.

Я хочу придумать классический сайт ISV. Типичная иерархия будет следующей:

  • Продукты
  • — Продукт А
  • —- Обзор
  • —- История выпусков
  • ——- Версия 1.5
  • ——- Версия 1.4
  • ——- Версия 1.3
  • ——- так далее.
  • —- Функции
  • —- так далее.
  • — Продукт Б
  • —- Обзор
  • Пункт списка
  • так далее…

Сосредоточившись на истории релизов, я придумал:

  • настраиваемый тип контента: «релизы».
  • пользовательская таксономия для указания продукта, связанного с конкретным «выпуском».
  • Я создал шаблон для отображения списка «релизов».
  • Создан файл single-release.php для отображения сведений о выпуске.
  • Создал страницу на основе моего шаблона.

URL-адрес страницы, на которой отображается список «выпусков», в основном соответствует иерархии (/products/product-a/release-history/). Однако URL-адрес пользовательского типа сообщения будет примерно таким: /%post_type%/%post_slug%/ (т. е.: /releases/version 1.2/

Я изо всех сил пытаюсь найти решение для согласованной схемы URL-адресов в течение 2 дней.

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

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

Тем не менее, я могу полностью упустить суть. Есть ли у кого-нибудь идеи, опыт настройки сайта с такой иерархией? Любая помощь приветствуется…

[Обновлять]

Не совсем уверен, каковы соглашения при обновлении здесь, но я оставлю исходный текст для ясности. Целью этого обновления является уточнение и добавление дополнительных деталей.

Продукты

Создана WP-страница «Продукты» — без родителя — URL: http:///products/

Продукт A (конкретный продукт)

Создана WP-страница «Продукт A» — родитель: «Продукты» — URL: http:///products/product-a/

Обзор

Создана страница WP «Обзор» — родительский: «Продукт А» — URL: http:///products/product-a/overview/

Выпуски (список выпусков для определенного продукта)

Создана страница WP «Что нового» — применен шаблон, отображающий список всех доступных выпусков (каждый выпуск имеет ссылку для отображения сведений об этом конкретном выпуске) — родительский элемент: «Продукт А’ — URL-адрес: http:///products/product-a/product-releases/.

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

Релиз (подробности о релизе)

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

Создан файл single-product-release.php для отображения определенного выпуска. Проблема с этим подходом заключается в том, что конкретный выпуск будет отображаться со следующим URL-адресом:http://<root>/product-releases/release-xx

  • Это не совсем описательно, по крайней мере, мы можем сказать (я должен по крайней мере получить какой-то идентификатор продукта в URL-адресе)
  • это несколько нарушает иерархию (хотя можно, конечно, поспорить, неправильно это или нет)

Мои параметры (насколько я вижу как новичок в WordPress)

Избавьтесь от постоянных ссылок

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

Очевидно, это не тот подход, которому я бы следовал… по многим причинам я не буду здесь подробно останавливаться (это уже длинный пост/вопрос).

Найдите способ добавить (или, скорее, префикс) мое значение ‘product-id’ к постоянной ссылке пользовательского типа сообщения

. У нас может быть что-то вроде http:///product-a/product-releases/release-x. Мне пришлось бы признать, что релизы живут несколько за пределами «естественной» иерархии, которая была бы http:///products/product-a/product-releases/release-x.

Я мог бы пойти еще дальше, добавив префикс «продукты» — что-то вроде /products/%product-id%/%product-release%/. Однако мне интересно, не будет ли это правило перезаписи конфликтовать со «страницами», созданными на странице «продукты»…

Любой вклад приветствуется.

[Обновлять]

Я реализовал подход, предложенный bobdiaes. Это отлично работает для моего типа контента, однако это будет конфликтовать со страницами WP, которые смешаны в иерархии. Используя фрагмент кода bobdiaes, я придумал следующий Permaling для моего пользовательского типа сообщения о выпуске продукта:

/products/%product-id%/product-releases/%product-release%

поэтому у меня будет правильный URL-адрес продукта для отображения сведений о выпуске для определенного продукта. то есть:/products/my-great-product/product-releases/release-1-5/

Тем не менее, я хочу иметь несколько страниц WP в миксе:

  • /products/my-great-product/ должен предоставить обзор продукта.
  • /products/my-great-product/product-releases/ должен отображать список выпусков + сведения о последнем выпуске.

Поначалу кажется вполне естественным создавать страницы WP, чтобы делать то, что мне нужно. Я организую свою иерархию страниц так, чтобы страницы соответствовали точной схеме URL. Однако этот подход будет конфликтовать с переписыванием URL-адресов, используемым для пользовательского типа контента «product-release», и я не смогу просматривать страницы (404).

Так так так…

Итак, каковы мои варианты сейчас

Откажитесь от идеи использовать WP

Что ж, думаю, я буду настаивать еще немного. Помимо этой проблемы, в WP есть много вещей, которые могут понравиться.

Используйте Pod CMS

, хотя я еще не тестировал его. Звучит как хороший фреймворк/инструмент. Однако я потерял бы возможность легко переводить свой контент с помощью WPML.

Тот факт, что в версии 2.0 они смогут использовать настраиваемые типы сообщений, а не свои собственные таблицы, безусловно, позволит им полагаться на текущие плагины для целей перевода. То, что они готовят для версии 2.0, звучит интересно. Они смогут использовать пользовательский тип записи вместо своих собственных таблиц.

Pod CMS 2.0 может стать РЕШЕНИЕМ.

Использование страниц WP вместо пользовательского типа сообщений «выпуск продукта»

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

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

  • Текущий интерфейс страницы администратора может быть не очень практичным для обработки сотен страниц…
  • Поскольку страница уже является специализированным настраиваемым типом записи (насколько я понимаю), мне придется помнить о конкретных настраиваемых полях, которые мне нужны каждый раз, когда я использую страницу как тип псевдоконтента, если только я не хочу создавать все поля, которые могут быть необходимым на всем веб-сайте. Довольно ужасное решение, если вы спросите меня.

Замените страницы WP на какой-нибудь пользовательский тип записи.

Не уверен, что правила перезаписи могут конфликтовать, но вот идея. Вместо обзорной страницы я мог бы придумать пользовательский тип сообщения «обзор продукта» и использовать правило перезаписи постоянной ссылки так же, как я сделал для пользовательского типа сообщения «выпуск продукта». Буду обновлять с моими выводами.

Я уверен, что я не единственный, кто сталкивается с этим адом URL-адресов WordPress. Хотя я должен признать, что обобщение «сообщения» в пользовательский тип сообщения довольно умно, у постоянных ссылок есть свои ограничения.

Предостережение: будучи новичком в WP, я мог упустить что-то совершенно очевидное.

[Обновлять]

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

В принципе, на данном этапе я считаю, что нужно привязываться к довольно простой схеме URL. Попробую форум wordpress, но особо не надеюсь.

Share
  1. @Frederic L : пытаясь ответить на ваш вопрос, мне приходит в голову, что у вас недостаточно данных, определенных для желаемой структуры URL; вам также нужен 'product' пользовательский тип сообщения. И я бы определенно не назвал пользовательский тип записи множественным числом пользовательской таксономии. Я собираюсь предложить вам назвать пользовательский тип записи 'release' (единственное число) и вашу пользовательскую таксономию как 'version' (также единственное число). И чтобы свести к минимуму конфликты с будущими дополнениями WordPress, я рекомендую вам ставить перед ними префикс 'product', т.е. 'product-release' и 'product-version' . Будет ли это работать для вас?

    • 0
    • Ваши рекомендации по именованию имеют смысл — это был бы мой первый подход (например, сущность). Тем не менее, я только что следовал рекомендациям пользовательского интерфейса Custom Post Type (пример в скобках) и подумал, что обязательно должен следовать этим рекомендациям, чтобы потом не усложнять задачу. Я действительно не понимаю, как наличие пользовательского типа сообщения «продукт» поможет иметь согласованную схему именования. Есть ли способ иерархически связать 2 пользовательских типа сообщений? Не уверен в вашем предложении таксономии «версия». Означает ли это, чтобы дифференцировать мои различные продукты? Возможно, я обновлю свой первоначальный пост.

      • 0
    • Не уверен, что происходит не так, но при попытке использовать ваш код я просто получаю пустую страницу независимо от URL-адреса моего сайта. Может быть, моя пользовательская таксономия была создана с помощью плагина?

      • 0
    • Похоже, что в коде, который отображается на вашей странице, есть опечатка: add_filter(‘post_type_link’, ‘rating_permalink’ ), 10, 3); После удаления круглых скобок я заставил его работать. Я собираюсь глубже изучить этот подход и посмотреть, может ли он заставить что-то работать.

      • 0
    • Ваш подход отлично работает с пользовательскими типами сообщений. Однако, если я захочу добавить несколько страниц в микс, это будет противоречить правилам перезаписи. Я обновлю вопрос, чтобы описать это более подробно…

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

      • 0
    • Однако проблема все еще существует, потому что, если я что-то не упустил, мне все еще нужна страница WP (с соответствующим шаблоном) для целевой страницы, на которой будут перечислены пользовательские сообщения. Поэтому, насколько я понимаю, моя проблема останется. Возможно, мне следует заглянуть в раздел витрины и посмотреть, смогу ли я найти сайт с аналогичными требованиями и посмотреть URL-адреса.

      • 0
  2. При планировании более сложных сайтов WordPress я стараюсь думать об иерархии страниц/URL-адресов в терминах схемы базы данных WordPress по умолчанию. Затем определите наилучшую схему перезаписи URL и структуру данных. В общем, я считаю, что объекты данных, наиболее важные для пользователя, должны существовать как настраиваемый тип записи или объект записи, отношения между пользовательскими сообщениями должны использовать настраиваемые таксономии, а уникальные значения должны храниться в метаданных сообщений.

    В частности, если бы я предлагал продукты с обновлениями версий, я мог бы создать собственный тип сообщений для каждого продукта (при условии, что общее количество продуктов с обновлениями версий ограничено) и создать новое сообщение для каждого нового выпуска (по умолчанию WP хранит сообщения в хронологическом порядке)., поэтому несколько выпусков должны работать хорошо). Другими словами, каждый новый выпуск будет существовать как отдельная запись в пользовательском типе записи, и каждая новая публикация будет содержать сведения об этом выпуске. Затем вы можете отобразить сведения о самом последнем сообщении на странице для пользовательского типа сообщения. Принудительно разбивая каждое сообщение на страницы, вы также должны иметь возможность иметь отдельные URL-адреса для функций и т. д., и вы должны иметь возможность сделать их красивыми, переписав URL-адрес.

    Визуально :

    /products/%custom-post-type%/
    /products/product-a/
    
    /products/%custom-post-type%/archive/
    /products/product-a/releases/
    
    /products/%custom-post-type%/%post-name%/
    /products/product-a/release-xx/
    
    /products/%custom-post-type%/%post-name%/page/2/
    /products/product-a/release-xx/features/
    
    • 0
  3. Я думаю, вам нужно подключить функцию get_permalink(). Эта статья, которую я сохранил в своих заметках о пользовательских типах сообщений, может быть полезной: http://shibashake.com/wordpress-theme/add-custom-taxonomy-tags-to-your-wordpress-permalinks.

    • 0

Оставить ответ

You must login to add an answer.