Derat

Вот сейчас проверил запрос

$post_ids = $wpdb->get_col("select object_id from $wpdb->term_relationships where term_taxonomy_id=75");
	foreach ( $post_ids as $post_id ) {
	echo 'post ID = '.$post_id."<br>";
	}
 

Всё выводит.

Теперь осталось разобраться с сортировкой.

Всё, достаточно, я самоизолюруюсь. Извините.

И всё равно спасибо за вариант с wpdb. 🙂

Я впопыхах выше не правильно написал.

$termsid— это ID таксономии, который я предварительно получу.
ID терминов — это как раз то, что нужно получить.

А зная тип, можно легко получить массив всех IDов записей нужного типа

А вообще это не то — мне надо получить ID не по типу поста, а по одному терму таксономии. Прощу прощения если не внятно объяснил задачу.

Посмотрел в базе и понял алгоритм: надо вначале получить ID терма таксономии, а потом уже выбрать object_id из таблицы wp_term_relationships.

• Ответ изменён 4 года назад пользователем Derat.

WP_Query с выборкой по терминам таксономии.

Вот это я вчера пытался сделать и затык был именно на
//тут засовываем в массив ID записей через get_the_ID()

Названия и ссылки я получал, а вот как получить ID так вчера и не сообразил. Попробую ещё сегодня повоевать.

get_template_part банально удобнее для последующего изменения, так как в отдельном файле

Да нет большой разницы в каком именно файле править код. Тем более это не регулярная работа. Если вообще до неё дойдёт после выпуска сайта.

а нагрузки — вы серьезно?

Почем нет? Возможно в каком-то случае происходит какое-то кеширование или сокращение количества запросов или ещё что-то. Я этого не знаю вот и спрашиваю.

И что именно непонятно?

Почти всё. Понятны только add_action.
Там замудрено.
Вначале проверяется requirements_met(), в которой $this->required_plugins.
Зачем такие путешествия в моём простом случае? Нет, я не в претензиях, просто не понимаю.

Но и дальше — если этот плагин а не родительский активен — деактивируем его же???

if ( is_plugin_active( plugin_basename( WOOF_BY_CATEGORY_FILE ) ) ) {
  deactivate_plugins( plugin_basename( WOOF_BY_CATEGORY_FILE ) );

А это

if ( isset( $_GET['activate'] ) ) {
      unset( $_GET['activate'] );
}

? вообще не понятно ни как так можно ни зачем и для чего.

1. Проверить, что нужный плагин активирован

С этим проблем нет.

2. Если нет, то деактивировать свой.

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

Или вы все в основном файле плагина делаете? Зачем?

В 2х. В главном регистрация кастомных типов и таксономий, в дополнительном — метакбоксы к ним. Хотя можно было и всё в одном. Зачем усложнять.

Вы смотрели как допы к вуке делают свои проверки?

Я смотрел в куче плагинов и для вуу и для cf7 ещё до создания топика. Но там всё намудрено. Если бы нашел понятный способ не спрашивал бы.

Вот же:

Я даже не представляю как из слов «не дать активироваться своему плагину» можно было сложить «тихая подстава с отсутствием кнопки «активировать».».

ни слова про сообщение.

А это тогда что?:

только вывод сообщений типа

и 2й раз

Но только для проверки и вывода сообщения

Проверяешь — есть ли функция/класс из основного плагина

Да не важно что поверять. is_plugin_active проверяет файл родителя — ничем не хуже. С проверкой проблем нет. Мне не понятно как не дать включиться своему.

— есть: инклюдишь файл лоадер всего плагина;

Какой лоадер?

Это более верный путь для пользователей, нежели просто тихая подстава с отсутствием кнопки «активировать».

Где про такой бред я писал?