$wpdb->get_results(...) возвращает пустой массив, несмотря на правильный запрос

Используйте $wpdb->show_errors( true ) перед запросом и посмотрите, какая ошибка вернется.

Моя проблема (потому что я сталкивался с тем же) заключалась в том, что мне нужно было использовать $wpdb->posts вместо wp_posts внутри запроса. Префикс таблиц может меняться от установки к установке WordPress или даже в одной установке в зависимости от времени (например, администратор может изменить префикс, когда захочет). Поэтому запрос следует писать так:

$query = "select <stuff here> from $wpdb->posts where <stuff here>";

Я разбирался со своим скриптом, который выдавал пустой массив в WordPress, несмотря на, казалось бы, корректную MySQL строку. Оказалось, что, в отличие от автора вопроса, я использовал $wpdb->prepare(), но решение, которое я нашёл, может быть полезным для тех, кто столкнётся с этим Q&A (как это случилось со мной).

В этой строке, AND aki.type LIKE '%thing%'", содержатся подстановочные знаки процента (%), которые указывают, что мы ищем ячейку aki.type, содержащую thing как часть своего значения.

$wpdb->prepare преобразует их в хэши, и MySQL сервер получает что-то вроде этого: AND aki.type LIKE '{399038939300d2c307c53b29a166ee90101da7b2aba7978a898694010bf1bfe6}thing{399038939300d2c307c53b29a166ee90101da7b2aba7978a898694010bf1bfe6}'. Естественно, результаты будут отсутствовать!

На странице wpdb::prepare сказано: 'Буквальные знаки процента (%) в строке запроса должны быть записаны как %%. Подстановочные знаки процента (например, для использования в синтаксисе LIKE) должны передаваться через аргумент подстановки, содержащий полную строку LIKE, они не могут быть вставлены напрямую в строку запроса. Также см. wpdb::esc_like().'

Таким образом, часть LIKE должна быть подготовлена следующим образом (пример из страницы wpdb::esc_like()):

$wild = '%';
$find = 'only 43% of planets';
$like = $wild . $wpdb->esc_like( $find ) . $wild;
$sql  = $wpdb->prepare( "SELECT * FROM $wpdb->posts WHERE post_content LIKE %s", $like );

Где $wpdb->esc_like() должен вызываться перед $wpdb->prepare().

А если нужно вручную заменить подстановочные знаки процента, следует использовать $wpdb->remove_placeholder_escape() после $wpdb->prepare().

Возможно, это немного запоздало, но вам не хватает вызова "prepare", необходимого в WordPress:

$Table_Name    = $wpdb->prefix.'Your Table Name';
$sql_query     = $wpdb->prepare("SELECT * FROM $Table_Name WHERE aki.keyID=%d AND akb.someID=%d AND aki.type like %s", akb.keyID, ac.someID, ''%thing%');
$result        = $wpdb->query( $sql_query ); 

Множественные результаты могут быть найдены в массиве.

У меня была такая же проблема - правильный SQL-запрос, никаких ошибок, но отсутствие результатов при использовании wpdb.

Решение для меня заключалось в правильной кодировке/сопоставлении (например, COLLATE 'utf8_general_ci') для моей таблицы.

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

Я создавал таблицы обоими способами (несколько раз, потому что не мог поверить), запускал один и тот же скрипт вставки данных и не менял свой PHP/wpdb код.

Когда таблица была создана таким образом, мой запрос НЕ работал:

CREATE TABLE IF NOT EXISTS `vf_user` (
  `id` mediumint(9) NOT NULL AUTO_INCREMENT,
  `email` varchar(50) NOT NULL,
  `full_name` varchar(25) NOT NULL,
  `password` varchar(25) NOT NULL,
  `role` enum('user','tester','admin') NOT NULL DEFAULT 'user',
  `phone` varchar(25) NOT NULL,
  `last_modified` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
  `user_activation_key` varchar(100) DEFAULT NULL,
  PRIMARY KEY (`id`) USING BTREE,
  UNIQUE KEY `email` (`email`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=325 DEFAULT CHARSET=utf8 COMMENT='users table';

А когда таблица была создана таким образом, мой запрос возвращал результаты:

CREATE TABLE `vf_user` (
    `id` MEDIUMINT(9) NOT NULL AUTO_INCREMENT,
    `email` VARCHAR(50) NOT NULL COLLATE 'utf8_general_ci',
    `full_name` VARCHAR(25) NOT NULL COLLATE 'utf8_general_ci',
    `password` VARCHAR(25) NOT NULL COLLATE 'utf8_general_ci',
    `role` ENUM('user','tester','admin') NOT NULL DEFAULT 'user' COLLATE 'utf8_general_ci',
    `phone` VARCHAR(25) NOT NULL COLLATE 'utf8_general_ci',
    `last_modified` TIMESTAMP NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
    `user_activation_key` VARCHAR(100) NULL DEFAULT NULL COLLATE 'utf8_general_ci',
    PRIMARY KEY (`id`) USING BTREE,
    UNIQUE INDEX `email` (`email`) USING BTREE
)
COMMENT='users with access to the virtual festival'
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=325
;

Функция Wpdb->get_results в WordPress возвращает результат, если запрос выполнен успешно, в противном случае она вернет null. Существует множество причин, по которым запрос может завершиться неудачно. Подробнее о диагностике можно прочитать в статье get_results() возвращает пустые результаты здесь.

Хотя вы можете использовать такие функции, как wpdb->show_error(), чтобы проверить последнюю ошибку после выполнения SQL-запроса. Иногда эта ошибка возвращает пустое значение, тогда попробуйте использовать wpdb->last_query, чтобы проверить окончательный сформированный запрос.