FanatPHP

echo json_encode($mysqli->query($query)->fetch_all(MYSQLI_ASSOC));

Проверять ничего не надо.
Писать "Ошибка! Вы не зарегистрированы. нет ни малейшего смысла.
И вообще ничего не нужно выводить. Надо делать редирект.

В момент записи.

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

Неважно, одна это буква, или 10. Кодировка соединения с БД настроена неверно.
Нужно убедиться, что
- кодировка таблиц действительно utf8
- кодировка соединения(задается в mysql(i)_set_charset() или в DSN) - utf8
- кодировка страниц сайта - utf-8

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

Но в любом случае - проблема в неумении разделить процесс на этапы, и проконтролировать данные на каждом. Чтобы впоследстви хотя бы задать адекватный вопрос, типа "При передаче данных из браузера данные портятся". Или "при записи в БД данные портятся". Вместо этого мы получаем беспомощное "С данными что-то происходит, но что именно и в какой момент - ниняю".

Один из тех вопросов, от которых волосы встают дыбом. На всех частях тела.

Ну ладно - вопрос. От человека, который массив в первый раз в жизни увидел. Можно понять.

НО ОТВЕТЫ!!! "Тут какие-то заборы! Коровники! Мама, мы в аду! Мы в аду, мама!"

1. phpfaq.ru/debug#quick
2. phpfaq.ru/debug#debug

Проблема в пихании в код разных умных слов без понимания их смысла.
Если убрать из кода слово MYSQLI_USE_RESULT, то волшебным образом ошибка исчезнет.
Впрочем, я должен признать, что сермяжная правда в двух других ответах есть. Если последовать моему же совету, и использовать prepare/execute вместо query (поскольку эта парочка используе USE_RESULT без вариантов), то как раз и придется либо выбирать все данные, которые вернул запрос, либо освобождать ресурс через free(), либо перед выборкой дергать store_result().
Но - повторюсь - в текущем коде этот параметр не имеет смысла и в то же время является причиной всех бед.

Но проблемы этого кода на этом только начнутся.

Во-первых, НИКОГДА больше пиши так: die(mysqli_error($mysqli)); а то станешь козленочком и тебя заберут в армию.
Вместо die надо писать trigger_error()

Во-вторых, НИКОГДА не подставляй переменные напрямую в строку запроса. Передавать данные надо только через плейсхолдеры. Если родной механизм слешком сложный, то можешь воспользоваться библиотекой phpfaq.ru/safemysql и код получится таким.

$exists = $db->getOne("SELECT 1 FROM users WHERE social_id=?s",$social_id);
if($exists){
	//тут устанавливаются куки
}else{
	$db->query("INSERT INTO users (social_id) VALUES (?s)", $social_id); 
}

(выводить бессмысленные okay или oops не нужно)

Дубль. Афтар не осилил отредактировать старый вопрос, и задал новый, более актуальный.

Здесь нет никакого запроса mysql, даже близко.
А есть какой-то самопальный винегрет, который собирает запрос из кусочков неизвестным читателю способом.

В любом случае, первое, что надо усвоить про составление запросов: ни одна переменная не должна попадать в запрос напрямую!

То есть, первый вариант делает весь этот самопальный винегрет (который, тем не менее, делает работу с БД безопасной) - бесполезным.

Поэтому, стоит использовать второй вариант, который, хоть и не оптимальный, но зато безопасный. А чтобы переменная не "затиралась" (а что ей еще остаётся делать, если её постоянно перезаписывают?), надо сделать её массивом:

$listings = [];
foreach ($array as $key => $value)
{
  $listings[] = $iaAuto->get(
        array('model_id' => $value), 
        $pagination['start'], 
        $pagination['limit'], 
        $_SESSION[iaAuto::SESSION_SORTING_KEY]
    );
}

Полученный в результате массив скорее всего будет отличаться от ожидаемого, так что надо будет немного изменить логику его перебора

Если тег mysqli стоит не от балды, а это АПИ действительно используется, то в перед коннектом написать

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

Плюс включить вывод ошибок или смотреть ошибки в логе.

Если использвется старое апи mysql_query, и нет обработки ошибок - то включить вывод ошибок и по косвенным ошибкам смотреть, где проблема.

Как включить вывод ошибок и как отлаживать программы вообще, написано здесь: phpfaq.ru/debug (в качестве бонуса там объясняется, почему бессмысленно задавать вопросы вида "почему у меня не работает?").

1. Это увеличит нагрузку на БД.
2. Само по себе решение продиктовано только дикостью и чудовищным невежеством. Через годика два, если наберешься опыта, то сам с ужасом будешь смотреть на этот свой вопрос.

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

Если взять ларавель, то в модели постов надо будет добавить метод

public function recentComments()
{
    return $this->hasMany('Comment')
        ->orderBy('created_at', 'desc')
        ->limit(3);
}

и ВСЯ лента будет строиться одним оператором, что-то вроде

return Post::orderby('created_at', 'desc')
    ->with([
            'photos',
            'recentComments',
        ]);
    ->limit(5);

Дла начала надо понять, что никакой живой пользователь никогда не будет читать 20 000 записей на одной странице.

после этого можно продолжать оптимизацию