Ответы в темах

Просмотр 15 ответов — с 1 по 15 (всего 56)
  • Вот сейчас проверил запрос

    $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. 🙂

    Еще круче.

    Да я ж не знаю как составить запрос, чтобы получить все ID из object_id при определенном значении в term_taxonomy_id

    Вот например при значении 75 в term_taxonomy_id получить массив значений из ‘object_id’ — 1619, 1665, 1731.

    https://i.imgur.com/sgXeHh5.jpg

    Это выборка из таблицы wp_term_relationships

    Помогите если не трудно.

    • Ответ изменён 2 месяца назад пользователем Derat.

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

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

    Если это не будет сильно нагло с моей стороны — я правильно составил запрос?

    $ids = $wpdb->get_col("select object_id from $wpdb->term_relationships where term_taxonomy_id=$termsid");

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

    • Ответ изменён 2 месяца назад пользователем Derat.

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

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

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

    • Ответ изменён 2 месяца назад пользователем Derat.

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

    Спасибо.
    Использовать wpdb я как-то сторонюсь, хотя возможно что в данном случае оно будет и лучше.

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

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

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

    если вам надо получить все записи всех терминов

    Нет, записи не нужны. Мне надо получить только ID всех постов из одной кастомной таксономии. Причем всех статусов, а не только опубликованных.
    Сейчас пытаюсь сделать это через WP_Query, но пока тоже не получается.

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

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

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

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

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

    Неа. Он проверяет не родителя, а обязательные плагины — $this->required_pluginsforeach.

    Можете попробовать связаться с автором плагина и уточнить у него, мне это, увы, не известно.

    Вот видите, и Вы не понимаете.

    Я Вам просто бесплатно подкинул идею как это можно реализовать

    Я ценю всё что тут рассказано всеми. Правда.
    Но пока мне ничего не помогло.

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

    Почти всё. Понятны только 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 проверяет файл родителя — ничем не хуже. С проверкой проблем нет. Мне не понятно как не дать включиться своему.

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

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

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

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

Просмотр 15 ответов — с 1 по 15 (всего 56)