FanatPHP

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

Если ты много прочел, но ничего не понял, то какой смысл тебе снова писать то же самое? Ты точно так же не поймёшь.
Иди читай снова.
Функция "печатает" функционально НИЧЕМ не отличается от отправки собственно текста сообщения.
Сделай сначала отправку, а печатает добавишь потом, когда разберёшься

НИКАК не делать.
Либо тебе вообще не нужна эта функция, и тогда ее не использовать, либо, если нужна, то оставить скобки в покое и найти себе проблему поумнее.

Надо понимать что полноценной замены не существует.
Данная программа - это два тупые молодца, одинаковые с лица, из мультика про Вовку в тридевятом царстве.
Которые честно пытаются делать то что хозяин им велит, но в силу врожденного слабоумия всё делают не так.
А всё от того что она хочет быть нянькой для программиста.
Но если программисту нужна нянька, то такого "специалиста" надо гнать из профессии поганой метлой.
А если хочет остаться - то да, надо учиться что-то делать самому. руками.
ЗАРАНЕЕ продумывать и создавать схему БД. И менять только в случае осознанной необходимости, а не потому что вдруг передал в БД не тот параметр, который хотел.
ЗАРАНЕЕ продумывать и писать SQL запросы. А не ждать что все их за тебя напишет тупая нянька.
Понимать то как работает пхп с базой данных.

Поэтому в качестве прививки от говнокода я порекомендую сначала
- учить устройство БД. Создавать все свои схемы руками
- учить SQL. Писать все свои запросы руками
- освоить работу с БД из РНР на базовом уровне, через нативный ПДО.

После того как это все будет от зубов отскакивать, и после пары выполненных проектов будет очевидно видна некоторая избыточность и повторяемость кода - ничинать писать свой первый Table Gateway. Ну, или если совсем нипалусяися - то осваивать что-нибудь хайповое, но хотя бы не такое маргинальное, например Елоквент.

Я так понимаю что главная задача - убрать перемножение таблиц.
По идее должно быть достаточно добавить индекс на product_id.
тогда во второй строке в rows должна появиться единичка

Если это реальные цифры количества строк в таблицах, то больше вообще никакие индексы не нужны.

Вопрос из серии "дурная голова ногам покою не даёт".

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

Ответы тоже, тостер-стайл: "я вообще не доктор, я сантехник, но вот моё икспертное мнение..."

В общем, если это сервис по генерации картинок в разных размерах, то тупо лимит на юзера, плюс кэшировать только стандартные размеры.
Если это обычная галерея, то забыть про дебильную генерацию на лету и делать все размеры сразу при загрузке.

Несмотря на то что в вопросе немного каша, а в ответах - ад, ответ на вопрос, в общем-то, очевидный.

В первую очередь с точки зрения простой житейской логики. Есть возможность? Надо воспользоваться. Вылезти из-под своей коряги посмотреть на неё со стороны всегда полезно, в любом деле.
Возможность узнать что-то новое - всегда полезна. Может быть ты и вправду, как тут вещают некоторые ораторы, проникнешься омерзением к пхп и пойдешь писать на яве.

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

Хайлоад же проекты - это из немного другой области. Тут идет откат скорее в обратном направлении. Это как с денормализацией - БД должна быть нормализована, но из соображений производительности иногда приходится денормализовывать. ПОСЛЕ того как нормализовал.
SOLID помогает делать большие проекты управляемыми. Но когда большой проект сталкивается с высокими нагрузками, иногда приходится жертвовать принципами ради производительности. Но тут главное, опять же, не путать направление: СНАЧАЛА делаем правильный дизайн, и только потом в критических точках снижаем накал абстракции, переходим на более низкий уровень. Самый наглядный пример - ORM, когда критические запросы переписываются на чистый SQL.

Ну и пройти "полный курс" не имеет ничего общего с "полным изучением". С полного курса изучение всегда только начинается.

Почему вместо кириллицы знаки вопросов?

Надо всегда обязательно читать, что написано в сообщении об ошибке.
Желательно - глазами.
Оно пишет человеческим языком - где мы сидим и какой файл пытаемся открыть

/home/ut/Downloads
/root/Downloads/

Не наводит ни на какие мысли?

А что у нас означает буквочка ~?

Ну и совсем уж риторический вопрос: раз уж мы перешли в папку с файлом, то зачем указывать путь к ней?

Ну и напоследок - не зря все мудрые руководства рекомендуют не сидеть под рутом

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

А вот класс писать не надо. Лишнее это все, баловство одно.

Вот ведь любители извращений

foreach (glob('/dir/*.webp') as $f) {
    $filename = pathinfo($f, PATHINFO_FILENAME);
    if (count(glob('/dir/$filename.*')) == 1) {
        только один, можно удалять
    }
}

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

можно проще.
explode и дальше проверяешь каждый элемент в отдельности.
но я тут подумал что так будет сложнее на самом деле, если надо проверять каждый элемент, число ли это.

А если не надо проверять сами элементы, то тогда просто размер массива.

Для того чтобы "пользователь создавал магазин с доменом "test" и сайт становился test.mydomain.ru" создавать никакие субдомены не нужно.
Надо 1 раз настроить днс. После этого все возможные субдомены уже будут созданы.

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

500.blade - это и есть пользовательская страница. Единственное, что нужно видеть пользователю, при ошибке InvalidArgumentException.
Никакой другой не нужно

Не класть файл в открытый доступ.
Отдавать скриптом, который принимает в параметре имя файла, проверяет авторизацию и отдает файл с соответствующими заголовками
"как отдать сгенерированный РНР скриптом ХМЛ файл" в гугле можно найти чуть более чем дофига примеров

Сразу учимся правильно работать с БД.
Сначала учимся правильно соединяться.
Весь этот детский лепет "не могу соединиться с БД" выкидываем и пишем нормальный код, который без всяких проверок сам сообщит об ошибках

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$link = mysqli_connect($host, $user, $pass, $db_name);
$link->set_charset("utf8mb4");

после этого переписываем свою функцию на добавление, предавая в неё линк в качестве параметра

function ins ($link, $image_name) {
    $stmt = $link->prepare("INSERT INTO cat (image) VALUES (?)");
    $stmt->bind_param("s", $image_name);
    $stmt->execute();
}

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

Из всей той ерунды, которую тут уже успели понаписать, и ещё понапишут самозваные "кураторы" и эксперты, единственно полезным является ответ Андрей Ежгуров
Но он отвечает на следующий твой вопрос.

А ответом на текущий является

Передавать его в класс параметром

Это единственно правильная практика, пусть она даже и кажется тебе не очень хорошим решением.
Только не целиком конфиг а лишь те опции, которые нужны данному классу.
Это то как на самом деле работает ООП. Для закрепления материала можешь почитать про dependency injection.