FanatPHP

Отвечу на вопрос "почему".
Потому что приведение типов.
Строка "FALSE" - это не булево значение FALSE, а строка, 5 букв. Не имеющая никакого отношения к булевым значениям или числам. Присравнении с числом и РНР и mysql пытаются привести строку к числу. При этом из строки "FALSE" получается 0. И поэтому сравнение "работает". Но разумеется так сравнивать нельзя.

Строка "TRUE" - это, как уже должно быть понятно, не булево значение TRUE, а строка, 4 буквы. Не имеющая никакого отношения к булевым значениям или числам. Присравнении с числом и РНР и mysql пытаются привести строку к числу. При этом из строки "TRUE" получается 0. И поэтому сравнение "не работает". Если передать не строку а булево значение TRUE, то сработает.

Поскольку в mysql нет типа поля boolean, лучше всего не выпендриваться с TRUE и FALSE, а просто передавать 0 и 1.

Никак не делать.

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

И в запросе на получение статуса просто учитывать дату. Если проверен и прошло меньше месяца - то проверен.
Иначе - не проверен.

Это какой-то ужас, а не код. Здесь всё неправильно.

Не нужно никаких временных таблиц, не нужно multi_query (эта функция вообще никогда не нужна). Запросы надо исполнять с помощью подготовленных выражений.

Запрос нужен всего один.

$sql = "INSERT INTO texts SELECT null, page_id, ballon_no, text_lang, font_size, html_left, 
        html_top, html_width, html_height, ?, rotate, text_align, aspect_ratio,
        position_ratio, calc_width, calc_left, font_color, line_height, font_type 
        FROM texts WHERE id=?";
$stmt = $link->prepare($sql);
$stmt->bind_param("ss", $text, $id);
foreach ($array as $id => $text) {
    $stmt->execute();
}

Не лез бы ты в абстрактные классы пока.

А если по теме, то тебе же ведь уже раз 5 объясняли как пользоваться твоим собственным классом БД

$sql = 'UPDATE `' . static::getTableName() . '` SET `views` = `views` +1 WHERE id=?';
return $db->query($sql, [$article->id]);

Подставлять надо не урл, а найденный выше id

С третьей попытки осилим дописать этот черезвычайно сложный код

$sql = 'SELECT * FROM `tasks` WHERE `id`= :id' ; // запрос вроде бы правильный
$query = $pdo->prepare($sql);
$query->execute(['id' => $id]); // а выполнить забыли
echo json_encode($query->fetchAll(PDO::FETCH_OBJ)); // ой, а while оказывается не нужно!

Ни в коем случае.
Твоя база данных не зря названа реляционной, то есть связанной. Информация хранится в связанных между собой таблицах. Это позволяет получать нужную информацию одним запростом и обрабатывать миллионы срок без потери производительности. Что в миллион раз важнее лени "создавать дополнительную таблицу"

И не надо слушать советчиков из соседних ответов.
Увы, поколение милленниалов не умеет воспринимать письменный текст, и реагирует в лучшем случае на пару ключевых слов в вопросе, не воспринимая корнтекст. Который, чтобы было понятно, звучит так: Нашел у папы в сарае заряженнвую двустволку. Прикладом очень удобно орехи колоть. Это удобнее потому что из щипцов орехи вываливаются. Нормально ли колоть орехи заряженным ружьем?

Сериализованные данные стоит хранить в бд только в очень крайнем случае.
На данном этапе вообще забудь про такую возможность и учись работать с БД правильно.

Как выглядит и работает фильтрация PHP POST & GET?

Никак.
Я понимаю, что это утверждение не укладывается голове у человека, изучавшего пхп по видеокурсам, но это факт.
Сами по себе НТТР запросы POST & GET никакой угрозы не несут и как-то заранее фильтровать их не надо.

Фильтровать вообще надо не по принципу "откуда", а по принципу "куда".
Данные надо форматировать в зависимости от того, куда они пойдут, а не откуда они пришли. SQL запросу абсолтно фиолетово, откуда взялась кавычка в данных - из GET, файла на диске, или из другой базы данных. Данные для SQL надо правильно форматировать не потому что они пришли из GET, а потому что они идут в SQL.
(При этом надо также понимать, что SQL запрос и база данных - это не одно и тоже. Базе тоже по барабану, что в ней лежит. Любое форматирование мы делаем только для SQL запроса, а в базе данные снова должны быть как есть).

Я думал, что будут удаляться все кавычки и теги,а по факту они остаются.

Если бы все думали, как ты, то ты бы не смог задать свой вопрос на Тостере. Потому что без кавычек и тегов он превратился бы в бессмыслицу. Как и куча любых других вопросов.
Разумеется, "мусор" надо не удалять, а форматировать. Потому что это "мусор" только для SQL, а для человека это нужная информация, которая помогает читать текст.

Не использовать же для этого регулярки?

Нет, разумеется.
Использовать регулярки будет так же глупо, как и твою функцию.

Для того, чтобы поместить переменную в SQL запрос, надо использовать подстановки в подготовленных выражениях. Запомни это предложение. Оно важнее всего, что ты до сих пор успел узнать про пхп. Хорошоенько запомни, ты должен это знать лучше, чем зовут маму с папой. И никогда не отступать от этого правила. Не важно - нужна тебе защита от SQL инъекций или не нужна, из POST-а ли пришли данные, или Господь бог тебе их надиктовал на горе Синайской - все равно всегда и везде только через подстановки.

Поэтому.
1. Выкидываешь свою функцию на помойку. Единственное слово, которое там имеет там хоть какой-то смысл - это trim(). Ну так ты можешь вызывать её напрямую.
2. Судя по уровню кода и вопроса, для работы с бд ты используешь убогую mysqli. Поэтому забудь вообще про mysqli_query(), а все запросы, в которых используется хотя бы одна переменная, выполняешь только так

$stmt = $conn->prepare("INSERT INTO tablitsa (login_name,email) VALUES (?,?)");
$stmt->bind_param("ss", $login, $email);
$stmt->execute();

Подробнее можешь почитать в интернете.
3. При выводе пользовательских данных в HTML, используешь функцию htmlspecialchars(). Надеюсь, к этому моменту ты уже понял главную мысль - важно не откуда пришли данные, а куда. Идут в хтмл? Отлично, форматируем их для хтмл.

Ну, запрос, конечно, без индекса, но один раз запустить можно

SET SESSION group_concat_max_len = 10000000;
select replace(replace(email, '.',''),'+',''), group_concat(email), count(1) cnt
from table 
group by replace(replace(email, '.',''),'+','') 
having cnt > 1
order by cnt desc

JSON