cha-cha

Я не до конца понимаю кто этот ondrej и можно ли вообще доверять этому репозиторию? - этому репу все доверяют

Вам это не нужно. Достаточно добавить accessor в модель.

/**
 * Полный адрес поста.
 *
 * @return string
 */
public function getFullAddressAttribute()
{
    return url("/{$this->user_id}/post/{$this->id}");
}

// Использование
$post->full_address;

Кодят обычно ловя баланс между быстро или правильно (правильно по мнению матерых). Symfony ближе к правильному, Лара к быстрому (RAD-разработка). В Ларе на некоторые вещи закрыли глаза в пользу скорости разработки, такое естественно ведет к появлению ошибок у пользователей фреймворка. Но это конечно все не говорит, что Лара не позволяет поднять и поддерживать отличный Enterprise-проект или Symfony 100% обезопасит от косяков даже простой проект...

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

Я перепробывал много вариантов, и всё не могли проверить на наличии двух лайка с одного аккаунта на одном и том же посте

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

Это просто идеальная иллюстрация к известному высказыванию Дональда Кнута "Преждевременная оптимизация - корень всех зол".

Сначала высасываем из пальца проблему: "тратится время на обращение к бд". Сколько там его тратится, тратится ли вообще, замедляет ли это систему, является ли вообще это проблемой - все эти вопросы нам неинтересны. Мы хотим грудью на амбразуру, стать героем и получить медальку.

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

Стоит ли так делать и почему;
не стоит потому что не надо высасывать проблемы из пальца.
Какой будет прирост производительности
Отрицательный
Как Вы решаете подобные вопросы.
МЫ ИХ НЕ РЕШАЕМ.
Мы решаем реальные проблемы, объективно существующие.
А воображаемые проблемы высосанные из пальца решать не следует.

Зочем?

У вас на фронте секретные разработки? Тогда их надо было не на фронте реализовывать.

Всё что есть на фронте доступно в консоли браузера так или иначе.

Как выглядит и работает фильтрация 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(). Надеюсь, к этому моменту ты уже понял главную мысль - важно не откуда пришли данные, а куда. Идут в хтмл? Отлично, форматируем их для хтмл.

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

public function toArray($request)
{
    return [
        'id' => $this->id,
        'name' => $this->name,
        'specialities' => SpecialityResource::collection($this->whenLoaded('activeSpecialities')),
    ];
}

public function toArray($request)
{
    return [
        'user' => UserResource::make($this->whenLoaded('user')),
        'special_price' => $this->special_price,
    ];
}