Поддержка Проблемы и решения Создать каталог — register_post_type() или метаданные

  • Доброго дня
    Прошу Вашей помощи в области понимания структуры хранения данных при создании каталога продукции. Суть такова: необходимо реализовать каталог продукции, в котором содержится информация о товарах со всеми продавцами и поставщиками данных товаров, т.е. результирующая таблица товаров, которая должна выводиться пользователю после выбора им всех параметров фильтрации товаров, имеющихся в БД, такова:
    Наименование_товара Производитель Поставщик Данные_поставщика/производителя Цена.
    Для реализации я создаю свой тип записи при помощи register_post_type(), создаю свои таксономии для классификации товаров при помощи register_taxonomy(), но не пойму как хранить в структуре БД сущность самого товара и связанного с ним поставщика и производителя. Т.е. если товар — это мой тип записи, то производитель и поставщик это должны быть произвольные поля в таблице wp_postmeta, или же для производителя/поставщика нужно создавать ещё один тип записи? но тогда как их связать между собой тип записи товар и поставщик/производитель?
    Т.е. к примеру, имеется кирпич и его могут продавать/производить условно 10 разных компаний по разным ценам, тогда соответственно в таблице wp_posts будет 10 записей, связанных с произвольными полями в wp_postmeta (я склоняюсь к данному варианту) или в таблице wp_posts будет 10 записей товаров каким-то образом связанных с типом записи производитель/поставщик?
    Или имеет место какой-то третий вариант? (пытаюсь всё реализовать без плагинов и создания своих собственных таблиц)
    Извините, если написал замудрено, но пытался спросить максимально доступно. Буду благодарен за любую консультацию — не могу понять как верно хранить данные в данном случае. Помогите, пожалуйста

Просмотр 15 ответов — с 16 по 30 (всего 49)
  • Понял, спасибо!! @yube , Вы писали:

    Среди штатных виджетов есть виджет «навигационное меню», в котором можно вывести любое из имеющихся (созданных) меню.

    А как в данном случае задать свою верстку для меню в виджете, как применить wp_nav_menu() ? для виджетов наверное есть отдельный механизм (виджету «Поиск» также нужно задать свою верстку). Не подскажете как действовать в данном случае ?

    Модератор Юрий

    (@yube)

    А как в данном случае задать свою верстку для меню в виджете

    Как везде — через css.

    как применить wp_nav_menu() ?

    Зачем? Там уже встроен вывод (собственно, только он), нужно только указать выводимое меню.

    Не подскажете как действовать в данном случае ?

    Могу посоветовать не изобретать велосипед. Люди, писавшие ранее сайты с нуля или пользовавшиеся другими CMS/фреймворками, часто пытаются перекроить wordpress под привычное им, вместо того, чтобы пользоваться тем, что дает WP. Как по мне, то это лишние трудозатраты, часто связанные не столько с необходимостью, сколько с непримиримостью 🙂

    @yube , еще раз прошу прощения за беспокойство, по поводу верстки для меню в виджете Вы писали:

    Как везде — через css.

    Я видимо не могу уловить самого главного — я создаю меню в админке, привязываю его к виджету, но как мне узнать css-классы генерируемого меню ? как узнать css-класс виджета поиска? через консоль браузера http://prntscr.com/uawnrl?
    т.е. получается wp_nav_menu() позволяет добавить к меню свои классы и идентификаторы, чтобы сверстать как тебе нужно, а правильнее и проще будет переопределять стили для классов и идентификаторов, которые WP генерирует сам. Я правильно Вас понял ?

    Модератор Юрий

    (@yube)

    как узнать css-класс виджета поиска? через консоль браузера

    Да, так быстрее. Но можно и в html страницы посмотреть (Ctrl+U), если динамически (жабаскриптом) не меняются idы/классы.

    т.е. получается wp_nav_menu() позволяет добавить к меню свои классы и идентификаторы, чтобы сверстать как тебе нужно

    Некоторые общие, заданные в параметрах вызова функции — да. Классы отдельным пунктам, если нужно, добавляются в адмнке при создании/редактировании.
    И точнее было бы говорить не о «сверстать», а о «стилизовать», потому что верстка подразумевает и html тоже, а он у менюхи совершенно стандартный.

    а правильнее и проще будет переопределять стили для классов и идентификаторов, которые WP генерирует сам.

    Почему «пере»? Просто «определить». Вордпресс не цепляет свой css к менюшкам, всё на совести верстальщика темы.

    @yube , подскажите, пожалуйста, нигде не могу найти ответ — первоначально нужно регистрировать свой тип записи при помощи register_post_type(), а только затем таксономии при помощи register_taxonomy(), которые будут привязаны к данному типу записи или же наоборот — первоначально нужно регистрировать таксономии, а только затем тип записи, к которому данные таксономии будут прикреплены ?

    Модератор Юрий

    (@yube)

    По-моему, движку без разницы.

    Я обычно сначала пишу объявление типа записи, а потом таксономий к нему. Так вроде человечней получается 🙂

    @yube , подскажите ещё, пожалуйста, если я регистрирую свои записи и таксономии во время события init в functions.php темы, нужно ли отменять регистрацию этих записей и таксономий — unregister_post_type() и unregister_taxonomy() — при деактивации темы ?

    Модератор Юрий

    (@yube)

    Регистрация типов и такс на хуке init существует только от момента активации хука до окончания выполнения php-процесса, то есть окончания формирования html-страницы. Вне этого интервала времени для движка не существует кастомных типов. Не будет регистрации (скажем, они не прописаны в functions.php другой темы, выбранной в качестве активной) — не будет и типов/такс для движка.

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

    понял, @yube , спасибо, значит при деактивации темы с кастомными записями и таксономиями ничего делать не нужно. А вот по поводу терминов, Вы писали:

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

    Я пытаюсь добавить новые термины кастомной таксономии при помощи wp_insert_term() после активации темы (after_switch_theme()), а при деактивации темы удалять эти термины во время switch_theme(). Но ничего не выходит, и ошибки не появляются при активации/деактивации темы. Подскажите, пожалуйста, где я ошибся, во время какого события правильно будет вставлять/удалять термины ?

    @yube , прошу прощения, с вопросом выше разобрался ранее — сам виноват, указывал неверные параметры в wp_insert_term().
    @yube , прошу Вашей помощи, не могу понять как в WordPress можно узнать id последней записи из wp_posts и id последнего термина из wp_terms. Не могу найти, может быть есть специальные функции в WordPress для этих целей ? Ведь наверное неправильно узнавать это через стандартные SQL-запросы:
    $max_post = $wpdb -> get_var("SELECT MAX(ID) FROM wp_posts")
    и
    $max_term = $wpdb -> get_var("SELECT MAX(term_id) FROM wp_terms") ?
    Подскажите, пожалуйста

    • Ответ изменён 1 год, 8 месяцев назад пользователем Dmitry Kohan. Причина: уточнил
    Модератор Юрий

    (@yube)

    может быть есть специальные функции в WordPress для этих целей ?

    Не встречал. И вряд ли они есть, потому что это эти цифры имеют смысл только внутри mysql для правильной работы автоинкремента суррогатного ключа. Сами по себе они практически никакой смысловой нагрузки не несут.

    Для процесса, создающего запись, id созданной записи действительно имеет смысл, и он возвращается функцией wp_insert_post(). Вне этого процесса последнюю внесенную запись определенного типа легко получить функцией get_posts(), указав нужные атрибуты.

    С термами сложнее, потому что они в принципе не имеют привязки к дате, а потому среди них нет (логически) ни первого, ни последнего. Если все-таки зачем-то нужен id последнего созданного _скриптом_ терма, можно в этом скрипте сохранять этот id в options либо в term_meta писать дату-время создания терма _скриптом_, а потом из нее получать term_id для самого свежего.

    понял, @yube , спасибо
    Позвольте спросить, почему могут возникать Notice вида:

    Notice: Undefined index: groupasset in C:\xampp\htdocs\budexportcost\wp-includes\post.php on line 4053
    
    Notice: Undefined index: employer in C:\xampp\htdocs\budexportcost\wp-includes\post.php on line 4053

    при добавлении записей кастомного типа с помощью wp_insert_post() и затем установкой терминов кастомных таксономий (в частности: country, groupasset, employer) для этих записей при помощи wp_set_post_terms() ? Все записи добавляются нормально, термины привязываются, но на таксу country WP почему-то не ругается. Не подскажете, в чем может быть причина?
    Не может же быть такое из-за того, что я привязываю записи только к дочернему термину, а к родительскому — нет ? Когда термин является дочерним и к нему привязана некая запись, то не нужно ведь эту запись привязывать и к его родительскому термину ?

    Модератор Юрий

    (@yube)

    почему могут возникать Notice вида:

    Потому что php — зануда. И чем дальше, тем больше.
    В данном случае она нудит, что элемент массива $postarr['tax_input']['groupasset'] не существует, а его проверяют на is_array.

    на таксу country WP почему-то не ругается. Не подскажете, в чем может быть причина?

    Не подскажу.

    не нужно ведь эту запись привязывать и к его родительскому термину ?

    Не нужно.

    Понял, @yube , ещё раз спасибо, буду разбираться дальше.
    Т.е. в принципе на данные Notice можно не обращать внимания, верно?

    Модератор Юрий

    (@yube)

    на данные Notice можно не обращать внимания, верно?

    Если в чужом коде, можно не обращать внимания, если в своем, то лучше, конечно, поправить. Хотя бы чтобы не мозолили глаза и не отвлекали от более серьезных сообщений в логе.

Просмотр 15 ответов — с 16 по 30 (всего 49)
  • Тема «Создать каталог — register_post_type() или метаданные» закрыта для новых ответов.