Ипатьев

Хорошие вопросы.
Разумеется, увеличивать количество запросов к БД ради красивой типизации - это абсолютно не вариант.

Как можно увидеть, в приведенной цитате написано не однозначно, а "скорее всего".
И поэтому надо конечно стараться, чтобы функция возвращала какое-то одно значение, но не делать этого любой ценой. Поэтому getUserDataFromDatabase вполне может возвращать array|false, а getUserIdFromDatabase - int|false, хотя я бы с ней не заморочивался, первой вполне достаточно. А userIsPresentInDb вообще не нужна, вместо неё можно использовать одну их предыдущих.

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

return $result ?: []; // дёшево и сердито

Но это будет всё равно не очень красиво. В одной стороны - да, для проверки, вернула ли функция непустое значение, такой вариант вполне сгодится. Но с другой стороны все равно как-то неаккуратненько. Ведь мы на самом деле ждём не абы какой массив, а вполне определённый, с конкретным набором полей. То есть, если эта функция вернет массив вида [0, 42, 100500], то это будет явно не то, что нам нужно, но при этом типизация и слова поперёк не скажет.

Если думать от типизации, то функция getUserDataFromDatabase, возвращающая какой-то абстрактный массив - это нонсенс, бессмыслица. Эта функция должна возвращать юзера. Поэтому в идеале надо придумать способ указать, что функция возвращает не абстрактный, а конкретный массив определенного формата. Тем более, что такой способ как раз есть, ведь типизованный массив - это же объект! И для данного случая даже специальный паттерн есть - ValueObject (хотя в случае с пользователем лучше будет все-таки делать полноценный класс, содержащий не только данные, но и методы, например auth(), который сравнивает хэш пароля с введенным).

Соответственно, в идеале функция должна возвращать объект, представляющий пользователя.

И уже в этом объекте поле id может либо либо быть нулём, либо иметь какое-то положительное значение. Или даже объект может содержать отдельное свойство, заполнен/не заполнен.

И вот в этом случае типизация заиграет совсем новыми красками, и будет использоваться на 100%

function getUserFromDb( int $userId ) : UserObject {
        return $result ? UserObject::fillFromArray($result) : new UserObject();
};
$user = getUserFromDb();
if (!$user->id) {
    // нинашли :'(
}

Но опять же, как пишет ниже Сергей delphinpro, зависит от задачи.
И решив проблему правильной типизации значения, которое функция вернет, если нашла пользователя, можно вернуться к вопросу о том, что возвращать, если функция ничего не нашла. И в этом случае вполне подходящим вариантом будет вернуть null

function getUserFromDb( int $userId ) : ?UserObject {
    return $result ? UserObject::fillFromArray($result) : null;
};

if ($user = getUserFromDb()) {
    // нашли :)
}

stripos и strpos работают правильно

А если вам вдруг кажется, что они работают неправильно, то надо привести пример.
И тогда вам сразу объяснят, что вы делаете неправильно

Я с очень большим трудом могу представить себе код, который может вывести эту ошибку.
Сам по себе метод query() не возвращает null. При ошибке, с отключенными исключениями, он вернет false, и ошибка будет другая.
Если режим исключений включен, то я не представляю, как здесь можно поймать исключение, при вызове по цепочке.

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

$result = null;
try {
    $result = $mysqli->query("SELECT ...");
} catch(Throwable $ex) {}
$result->fetch_all(MYSQLI_ASSOC);

Путь истинный:
1. Зайти в панельку своего хостинга, найти там, где лежат лог ошибок
2. В нем всё написано.
3. Во всех непонятных ситуациях повторить пп. 1-2

Добавлять строчку ini_set('display_errors', 1); не следует. На хостинге вывод ошибок должен быть выключен. И даже в качестве временной меры это добавлять бессмысленно - ошибки всегда будут, надо учиться работать с логами.

Это называется "доступ по API".
Вместо прямого соединения с БД, "скрипт" отправляет запросы на удаленный веб-сервер, причем не SQL запрос, а какой-нибудь JSON. А уже приложение на веб-сервере соединяется с БД и отправляет запрошенные данные назад.
Это приложение будет и ключ проверять, и права доступа - какому пользователю какие данные можно отдавать.
Именно по такой схеме например работают мобильные приложения в вашем телефоне.

Соглашусь с предыдущими комментаторами, пример СЛИШКОМ высосан из пальца, чтобы по нему давать какие-то рекомендации.
Но в целом, бак должен быть отдельным объектом в составе машины, а никаким не "аругментом".
И у него может быть метод consumeFuel(miles)
Который может принимать длину дороги в качестве аргумента, и уменьшать количество топлива в соответствии с заложенной формулой.

Car.Tank.fillMax()
print Car.Tank.getLevel()
Car.Тank. consumeFuel(Road.length)
print Car.Tank.getLevel()

По поводу последнего варианта - всегда исходите из здравого смысла. Может ли быть дорога частью автомобиля? Нет, это очевидная бессмыслица. Дорога может быть частью поездки. Как и автомобиль. Вот в рамках объекта Trip они вполне могут взаимодействовать друг с другом.

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

Но вот построение осмысленной иерархии классов - это на порядок сложнее. И очень хорошо, что вы об этом задумываетесь. Просто не надо думать, что это все вы освоите по щелчку пальцев, как перебор словаря, например.

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

В одном соглашусь с ними: никогда не нужно делать два дела одновременно: и решать конкретную задачу, и учить новые концепции.
Поэтому лучшим вариантом написания кода будет такой: сначала наговнякать процедурный, но рабочий вариант.
А потом заняться его рефакторингом: посмотреть, какие можно использовать классы, как они могут взаимодействовать.

То что вам нужно, называется "профайлинг".
Его можно делать с помощью разных инструментов, таких как Xdebug, но можно и коряво, вручную расставляя код типа такого
$microtime = microtime(1);
// что-то делаем
$timer['sql'] = microtime(1) - $microtime;
Потом куда-то выводим этот таймер, чтобы никто не видел.

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

Для базы это ерунда
А вот для разработки будет проблема, потому что автор, наплодивший этот зоопарк, явно не прочитал даже начальных сведений про базу данных, и не понимает, зачем в ней нужны таблицы.
А программистская привычка с подозрением относиться к повторениям ещё не выработалась.

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

Я настоятельно рекомендую книгу Святослава Куликова "Реляционные базы данных в примерах", она свободно доступна для скачивания. В ней как раз и даются основы проектирования баз данных.

Вам же человеческим языком пишут, что нельзя подставлять липу в $mail->setFrom($email);
Или просто уберите эту строчку, или пишите в нее СВОЮ ПОЧТУ.

Как вариант, можете перед setFrom добавить addReplyTo()

База данных нинужна
Достаточно будет

<?php
file_put_contents('databaza.txt', json_encode($_POST, JSON_UNESCAPED_UNICODE)."\n", FILE_APPEND);

ну и чтобы вывести

foreach(file('databaza.txt') as $loh) {
     echo json_decode($loh, true)['email'], "<br>\n";
}

Ну а форму на HTML я думаю Frontend developer (senior+) уж как-нибудь осилит.

1. Никогда не используйте регулярки для парсинга HTML
   
2. Никогда не задавайте вопрос про свой вариант решения проблемы. Всегда задавайте вопрос про саму проблему.
   
3. Htmlpurifier, HtmlSanitizer
   

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

function save_data($pdo, $data, $type) {
    $stmt = $db->prepare('INSERT INTO ads (snippet, amp, date, anchor, link,type) 
                          VALUES (:snippet,:amp,:date,:anchor, :link, :type)');
    $pdo->beginTransaction();
    foreach ($data as $values) {
        $values['type'] = $type;
        $stmt->execute($values);
    }
    $pdo->commit();
}

Как я уже писал ранее, для скорости и консистентности множественные вставки желательно заключить в транзакцию.

И вызывать примерно так

$db = new PDO('mysql:host=localhost;dbname=test', 'root', '');
// ТОЛЬКО EXCEPTION! c warning-ами в детский сад ходите детей пугать
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$file = file_get_contents("ads.json");
$data = json_decode($file, true);
save_data($db, $data['p1']['ads'], 'ads');

$file = file_get_contents("May-12_17-57-28.json");
$data = json_decode($file, true);
save_data($db, $data['p1']['serp'], 'serp');

На этом этапе, посмотрев на повторяющийся код, можно сделать еще одну итерацию

function import_data($filename, $type, $pdo) {
    $file = file_get_contents($filename);
    $data = json_decode($file, true);
    save_data($pdo, $data['p1'][$type], $type);    
}

Но можно уже и не частить