WP, много переменных - выбрать правильное решение

Т.е. дублируются в обоих кастомных типах? В стандартном случае - их надо заполнять и там и там?

Я правильно понял? Если так - вот тут как мне кацца и ошибка в проектировании.

А что представляют собой эти 3-4 метаполя (ака Custom Post Fields)? Какой содержимое?

Вот я и не хотел бы дублировать, а иметь эти поля только в "составных частях товаров", но выводить их (использовать) и на страницах с "товарами".

Загвоздка в том, что надо их выводить не только на самих страницах товаров (single page), но и на страницах с большим списком "товаров" (archive page и подобное). Здесь я упираюсь в слишком большую нагрузку на сервер (куча query из БД).

Данные с цифрами. Некие Integers, которые надо будет не раз менять. Хотелось бы не менять их ручками по всему сайту, а только в Custom Post Types "составная часть товара", где они уникальны для каждого CPT.

Вот такая засада.

Погоди, "составная часть" - это уникальные данные для каждого "товара"? Т.е. в ед. экземпляре? Тогда зачем его в кастомные типы определять? ИМХО правильней в кастомную таксономию. Это же (если я правильно понимаю) иерархическая структура.

Или я не правильно понимаю?

---------- Добавлено 04.09.2013 в 16:49 ----------

Так.. перечитал.. переподумал. Вышесказанное отменяется ;)

А что если в п3 использовать просто метки? Ну или кастомную таксономию линейной иерархии (ну т.е. без иерархии.)

SeVlad, нет-нет.

"Составная часть товара" - именно его часть, но она может быть одинаковой в некоторых "товарах". Логическая часть. Карточка "товара" должна взять 3-4 переменных из карточки более подробного описания важной части этого "товара" - "составной части товара".

Поэтому "составных частей" всего 300 штук и в них куча своих Custom Fields (для описания более подробно этой важной части каждого "товара"), а самих "товаров" в 10 раз больше - 3000 штук.

Всё было бы легко, если не надобность выводить большой список "товаров", где пользователь должен видеть 3-4 переменных (Custom Post Fields) из "составных частей товара".

п.с.: если у меня уже крыша едет от этих "товаров", я не представляю, как вы сможете разобраться... :D Но очень приятно, что кто-то пытается вникнуть в суть моей проблемы, спасибо. ;)

Да, я это уже понял - след. постом написал, но он склеился с предыдущим :)

Мне кацца - метки (линейная таксономия) должно быть то, что надо. В см эти 3-4 общих для обеих типов делать не метаполями, а присваивать метки.

Костыль. Я не смогу спать нормально. :)

Более того, сей подход ограничит серьёзно масштабируемость и гибкость в будущем...

Хотя, вариант интересный - я о таком даже не подумал.;)

В идеале, я вижу использование некой отдельной таблицы в БД.

Но по какому принципу реализовать - не знаю.

Особенно мне не понятно, как заставить писать в эту таблицу данные каждый раз, когда я создаю/редактирую Custom Post type "составная часть товара".

Можно использовать отдельный php файл с переменными, но их там будет 1200 штук! 😮 Тоже костыль...

Метки - костыль? А мне кацца это именно верное решение. Для чего ж они ещё надо? :) Их суть - линейная иерархия. Ну т.е. "связать параллельные сущности одним термином\значением".

Хотя мб я до конца и не понимаю что и зачем, но на первый взгляд всё понятно.

А вот отдельные файлы - это точно костыли. :)

В чём же?

Когда мне надо сообразить какую-то структуру, которая в мозгах не складывается - я пытаюсь это на бумаге изобразить. Связи, зависимости и тд. Да не сразу, но в основном после некоторого времени мучений настаёт просветление. Хотя признаю несколько раз мне так и не удалось разрулить систему (не ВП)

Так что попробуй порисовать - мб что и прояснится.

Jovian, чего-то накрутил..

Кэш лучше обновлять после редактирования (как вариант - после группового редактирования, если требуется обновлять много товаров). На событие повесить, в котором тип записи проверять.

А "штатные" плагины кэширования разве не затрагивают Custom Post Fields? В смысле, на генерацию разово уйдёт с десятка два лишних запросов.. а потом всё из кэша будет дёргать. Не айс, но может не так страшно?

В любом случае всегда остаётся вариант написать свою функцию, которая будет одним запросом все нужные (4штуки) custom fields для нужных id-шников получать и раскидывать по шаблону.

---------- Добавлено 04.09.2013 в 19:25 ----------

Штатными средствами http://codex.wordpress.org/Plugin_API/Action_Reference/save_post

Проверять на тип поста (вместо product_options название составной части товара)

// свой тип для "составной части товара

    if ( 'product_options' != $_POST['post_type'] ) { 

        return;

    }

Как мне кацца проблема с логикой структуры.

Как я понимаю. Есть кастомный тип, скажем "велосипеды", есть кастомный тип "комплектующие".

"Велосипеды" содержит модели (основной контент) и их хар-ки (метаполя)

"Комплектующие" содержит комплектухи (основной контент) и их хар-ки (метаполя).

Одна и та же комплектующая "педаль" может быть у нескольких моделей велосипедов.

Ессно, одна модель велосипеда может иметь несколько комплектующих.

Т.е. тут имеем связь "многие ко многим" с параллельной и независимой иерархией.

Задача: добавить связующие хар-ки. (аля "красный", "железный", "надёжный").

Jovian, всё так?

Я вижу это как метки (или аналогичная линейная таксономия).

ЗЫ. И не надо изобретать велосипедов :)

Через часок обрисую проблему более подробно и в картинках (а то у нас недопонимание), так что не уходите - подумаем вместе ещё разок. ;)