Берете ID продукта, получаете термины таксономии 'pa_brand' (атрибута). На выходе массив терминов, каждый элемент массива - это объект WP_Term. Соответственно, $terms[0]->term_id - это и будет ID вашего термина.
Макс Жуков, А это отдельно решается. Get_the_terms внутри вызывает wp_get_object_terms в которой есть фильтр wp_get_object_terms_args. Данный фильтр позволяет модифицировать аргументы для конструктора WP_Term_Query, одним из которых является orderby. Дефолтное значение - name, но можно установить parent. Полистайте залинкованные доки.
Вы бы лучше описали изначальную задачу, что вы и зачем пытаетесь сделать, с какой целью. Потому что то, что вы сейчас пытаетесь исполнить идет вразрез с любой логикой. Ну и понятно, что отключая плагин ничего работать не будет - оно и не должно работать.
в каждой субдиректории /en /ru по одному ВП сайту будет
Если вы про режим Multisite, то не совсем так. WP будет один (один экземпляр движка), а виртуальные сайты - вот их сколько угодно. Но там никаких "папок" нету, это всего лишь часть урл, которая реализуется с помощью Rewrite API движка.
Макс Жуков, ваш искомый элемент всегда будет в массиве последним ("нижний уровень" как вы его называете). Развернув массив в обратном порядке получится что он всегда будет первым, с индексом 0. Что и требуется.
EvgenyMorozov, профилирование само по себе скорее относится к "продвинутым практикам для просветленных", поэтому придется научиться варить. Каким из предложенных способов - другой вопрос и зависит от среды. Если все на локалке - ставьте Xdebug и настраивайте его вместе с профайлером. Но тут без мануалов не обойтись вообще - как в процессе настройки, так и в процессе изучения готового профайла. Имхо, наиболее простой и удобный способ - установить Blackfire. Но бесплатная версия предоставляет только базовую инфу, возможно ее будет мало. Платная версия дорогая, оплата только на год (помесячно не берут), и имеет смысл только для сварщиков высших разрядов. Tideways - как альтернатива Blackfire.
Совершенно не обязательно эти хуки, это уже хардкор для прожженных. В базовом хуке pre_get_posts можно установить все что нужно через $query->set() – и post_type, и по каким полям искать. Гуглится на раз-два на всех языках.
Александр Ожиняк, Никита, не надо два отдельных ноутбука, надо 2 отдельных реальных человека, лучше даже из разных городов или даже стран. При адекватном оформлении проекта бан схватить нереально.
sim3x, Если говорить о CSS/SASS-либах (а в вопросе именно о них), тем более весьма mature (5+ лет все-таки) то спорно. Во-первых, что-то принципиально (и объемно) обновлять там нужно только если переходить на более новые технологии (например, отказываться от сеток на float'ах и внедрять CSS Grids). В остальном - по мелочи, можно делать в рамках конкретного проекта под конкретные потребности. Во-вторых, если либа все-таки низкоуровневая, то там в принципе мало что надо обновлять и поддерживать (хороший пример - тот же Normalize.css который по сути годами не меняется), в худшем случае - компонентно (тот же grid vs flex vs float/inline-block/table-cell). В третьих, опять же, разумнее не говорить о большом фреймворке или либе, а о наборе этих самых либ, более узкоспециализированных. Отдельно сетка/layout, отдельно reset/normalize, отдельно медиа и тд. В целом, ИМХО конечно же, я считаю что должны быть базовые низкоуровневые унифицированные вещи которые максимально reusable, остальное готовится и под конкретный проект на базе каких-то наработок и заготовок. Ибо CSS должен быть небольшой и максимально оптимизирован, а не тащить на каждой странице кучу говна на все случаи жизни и вагон переопределений дефолтных значений большого фреймворка. При таком подходе проекты получается легче и чище. Но да, разработка занимает чуть больше времени. Поддержка - нет, ибо в большинстве реальных случаев обновлять вряд ли что-то кардинально надо, к тому же чистый и минимальный кастомный код поддерживать легче, чем макароны из переопределений фреймворка. И не дай бог сам фреймворк случайно обновить. Но это мое личное мнение, основанное на личном опыте (как в компаниях, так и на фрилансе на проектах которые потом долго приходилось и приходится поддерживать).
И да, еще раз - звезды далеко не всегда являются показателем.
sim3x, ну, если разраб не первый год в деле, то требование 5+ лет выполнимо. По поводу звезд - сомнительно. Вполне нормально держать либу в приватной репе только для себя, не все идет (и не все должно идти) в опенсорс. И даже если идет - количество звезд совершенно ни о чем не говорит. Можно вполне спорный проект раскрутить до 100+ звезд если этим заниматься, а можно не раскручивать и не продвигать хороший код и не иметь звезд вообще.
$terms = get_the_terms( $product_id, 'pa_brand' );Берете ID продукта, получаете термины таксономии 'pa_brand' (атрибута). На выходе массив терминов, каждый элемент массива - это объект WP_Term. Соответственно, $terms[0]->term_id - это и будет ID вашего термина.