alexalexes

Добавить какой-нибудь специфичности в селекторы, которые определяют фоновую картинку.
Например, по порядку следования тегов post_thumbnail (это точно тег, вы с классом не перепутали?):

.alignleft post_thumbnail:nth-child(1) > a:before {
	background-image: url('icon_1.png');
}
.alignleft post_thumbnail:nth-child(2) > a:before {
	background-image: url('icon_2.png');
}
.alignleft post_thumbnail:nth-child(3) > a:before {
	background-image: url('icon_3.png');
}

Или добавить индивидуальные классы тегам, добавляющие специфичность тега post_thumbnail:

.alignleft post_thumbnail.icon_1 > a:before {
	background-image: url('icon_1.png');
}
.alignleft post_thumbnail.icon_2 > a:before {
	background-image: url('icon_2.png');
}
.alignleft post_thumbnail.icon_3 > a:before {
	background-image: url('icon_3.png');
}

Вам нужно сделать анализ предметной области. Понять с какими данными вы будете работать, какие функции подготовки и обработки данных будет выполнять ваш проект. Какое решение он будет синтезировать - целевая функция.
После того, как сделаете такое описание, можно будет обращаться к преподам, чтобы они подсказали на каких этапах обработки данных какие методы и какую математику применить.
Тут нужно не читать 100 книжек по математике, а одну методичку по дисциплине "Проектирование информационных систем". Жизненно необходимый навык - навык проектировщика ИС (он не обязан быть математиком).

Смотрите в сторону функции ListAgg - она объединит все значения через разделитель.
Потом останется только обрамить результат в скобки:

select '[' || ListAgg(item, ',') over (order by rownum) || ']'  as item_arr
  from table

PS: ListAgg работает с данными, которые можно привести к varchar/varchar2. То есть, у вас есть физическое ограничение в 4000 символов в результирующей строке. Или у вас данные изначально в BLOB/CLOB.
В этих случаях вам нужно использовать хранимую функцию, поскольку в чистом SQL вы не сможете работать с безразмерными атрибутами.
PPS: А вообще, нужно избавиться от JSON и нормализовать таблицу.
PPPS: Если вы делаете API, то формировать JSON для ответа API - это не функция СУБД, этим должна заниматься прослойка перед СУБД.

Вопрос лежит в плоскости оптимизации.
Если вам приемлемо по количеству обращений и времени делать несколько отдельных запросов, чтобы сформировать объект поста на бэкенде перед СУБД, то делайте. Если нужно уменьшить количество запросов, но пожертвовать объемом пересылаемых данных между бэком и СУБД, то какие-то атрибуты поста, которые идут списком/массивом можно получать одним запросом.
Обычно, дилемма состоит в том, как получать необъемные скалярные свойства поста - id, дата публикации, автор и т.д. и не сильно глубоких списков, скажем, изображения галереи поста, которые редко превышает пару десятков штук. Вот это можно спокойно джойнить, и не бояться дублирования свойств поста в выборке.
Если вы работаете с длинным текстом поста, и безразмерными списками, то тут нужны отдельные запросы. Скорее всего в комментариях у вас будет порционная подгрузка по страницам, или по кустам дерева комментариев, если оно многоуровневое.

1) Включить вывод ошибок php на любую непонятную ситуацию:

// в начале php файла указывается
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

2) Смотрите, что возвращает curl, и по ошибкам тоже:

$result = curl_exec($ch);
if($result === false)
{
    echo 'Ошибка curl: ' . curl_error($ch);
}
else
{
    var_dump($result);
}

3) Не светите данными авторизации в своих вопросах, особенно, всякими токенами доступа.
ПС: curl_error.

Нужно, чтобы СУБД поддерживала оконные функции (если у вас MySQL 5 версии, то мужайтесь).

select user_id,
          order_id,
          time,
          lag(time) over (partition by user_id order by order_id) as before_time, -- предыдущее значение time в пределах user_id по сортировке order_id
         time - lag(time) over (partition by user_id order by order_id) as period, -- математика вычитания времени зависит от СУБД.
         max(time) over (partition by user_id) - min(time) over (partition by user_id)  as user_period -- период между самой ранней записью по пользователю и самой поздней записью по пользователю
from t

У вас:

while($row=mysqli_fetch_array($res))
{  
    // #########################
    // ####  начало тела цикла  #####
    // ##########################
    $iduser=$id;
    $idkat=$row['idkat'];
     // #########################
    // ####  конец тела цикла  #####
    // ########################## 
}  
    $res=mysqli_prepare($bd, "INSERT INTO zakaz (iduser,idkat) 
 VALUES(?,?)");
 mysqli_stmt_bind_param($res, 'ii', $iduser,$idkat); // подставляем переменные, которые присвоились на ПОСЛЕДНЕМ прогоне цикла
 $result2=mysqli_stmt_execute($res);

Как вы ожидаете:

while($row=mysqli_fetch_array($res))
{  
    // #########################
    // ####  начало тела цикла  #####
    // ##########################
    $iduser=$id;
    $idkat=$row['idkat'];
    $res2=mysqli_prepare($bd, "INSERT INTO zakaz (iduser,idkat) 
 VALUES(?,?)");
 mysqli_stmt_bind_param($res2, 'ii', $iduser,$idkat); // подставляем переменные, которые присвоились на ТЕКУЩЕМ прогоне цикла
 $result2=mysqli_stmt_execute($res2);
     // #########################
    // ####  конец тела цикла  #####
    // ########################## 
}

PS: Есть нюанс. Обработку второго запроса нужно вести по отдельному дескриптору $res2, чтобы не поломать дескриптор $res, по которому работает while.

С помощью phpMyAdmin на OpenServer корректно создать пользователя БД, привязать правильную базу, и не забыть взять дамп базы с хостинга и развернуть на опенсервере.
Протестировать вход пользователя WP в phpMyAdmin.
Убедиться, что после залогинивания wp-шная база данных доступна этому пользователю.