Дмитрий

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

use \Framework\Main\UI\Extension;
Extension::load([ 'vendor.module.components.cabinet.personal' ]);
Extension::unload([ 'vendor.module.components.cabinet.personal' ]);
vs
\Framework\Main\UI\Extension\Extension::load([ 'vendor.module.components.cabinet.personal' ]);
\Framework\Main\UI\Extension\Extension::unload([ 'vendor.module.components.cabinet.personal' ]);

и будешь постоянно спотыкаться в коде об эти палочки.

А часть решается не просто, а очень просто: вместо того, чтобы писать код в Блокноте Виндоус, надо в кои-то веки освоить работу с нормальной IDE. Которая
- автоматом скрывает блок use
- по ctrl+наведение курсора показывает полный путь, а по ctrl-click сразу переходит в определение метода
- подсвечивает неиспользуемые неймспейсы, и не проблема их удалить

Надо прочитать в документации, что делает функция getCell, а потом подумать.
Кроме просмотра обучающих видео на юбтубе, программирование также требует и собственной мыслительной активности программиста.

Если думать совсем не получается, то надо пройти по ссылке из ответа на свой предыдущий вопрос, и прочитать там.

Минусы как бы очевидны:

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

1 Код становится трудно читаем. По месту использования не всегда понятно что имеется ввиду под Order::load() - \Framework\Sale\Order::load или \Vendor\Project\Sale\Order::load - приходится проматывать к верху файла.

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

2 Код становиться длиннее - там где было бы просто:
\Framework\Main\UI\Extension::load([ 'vendor.module.components.cabinet.personal' ]);
приходится писать:
use \Framework\Main\UI\Extension;
Extension::load([ 'vendor.module.components.cabinet.personal' ]);

Код становится длиннее в проектах где 2 контроллера и в них по 1 экшену. Там где Extension::load будет вызываться больше одного раза, очевидно экономия на эксплуатации клавиатуры заметно увеличивается. А в больших проектах создание объекта может (и будет) повторяться многократно.

4 Код становиться замусоренным, так как верхушки файлов запросто превращаются во что-то вроде:

Если не обращать внимание на отсутствие пункта 3, то... нет, не могу не обращать внимание, вот же торопыга....
Во первых - данная портянка очень аккуратно прячется любой адекватной ИДЕ,
Во вторых - это правильно и логично, хранить все импорты в одном месте
В третьих - если ты пишешь неимпортированный класс в коде - ИДЕ обычно предлагает варианты внесения его в блок импорта, и все выглядит аккуратно.

И хрен его знает используются импортированные классы ниже ещё или уже нет, ведь никто не убирает этот мусор.

Хрен не знает, а ИДЕ замечательно знает и даже подсвечивает серым цветом неиспользуемые.

Простых рекомендаций нет.

Использование фреймворков заранее определит список устройств и браузеров (про устройства - важное замечание, так как банальный размер и наличие скалинга многое определяет), но сделает работу проще, а если делать все самому то будет эффективнее,больше гибкости и главное понимание что как работает и почему нет!

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

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

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

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

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

Для начинающего я бы рекомендовал первый подход, с оглядкой на постепенный переход к SPA.

ddrescue

Раз у тебя уже есть готовый список, то вот что можно ответить:

Самое важное, без чего ты вообще никак не сможешь работать:
ASP NET Core, Postgresql
Им нужно уделить больше внимания.
Курсы есть и по тому и по другому, есть и вполне хорошие бесплатные.
Например у Postgrespro есть бесплатный курс (тебя должен интересовать PostgreSQL для разработчика) и книги.

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

git - ты его не упомянул, но он очень важен. Есть бесплатная книга Pro Git где подробно описаны все его команды + есть немало видео на youtube где в действии показано, как им пользоваться.

SOLID - можно почитать статьи и книгу "Чистая Архитектура". В любом случае от тебя не ждут знаний на уровне архитектора тут.

Unit tests - просто попробуй сам писать тесты на каком-нибудь фреймворке. Например на xUnit.
Ещё можешь почитать книжку Кента Бэка про разработку через тестирование.

Code review - просто почитай пару статей о том, зачем это нужно, и как не быть мудаком-ревьюером, и как принимать обратную связь на ревью.

Методологии разработки - просто ознакомься с теми, какие вообще есть.
Большинство сейчас работают по Scrum или Kanban (либо на чём-то производном от них).
Можешь ещё agile manifesto почитать
Опять же - от тебя тут не ждут знаний уровня менеджера проектов, и тебе не придётся с нуля процесс разработки в команде выстраивать.

$text = 'Просто текст 12345';
$matches = [];
$text = preg_replace_callback('~[0-9]~', function($match) use(&$matches) {
$matches[] = $match[0];
return '';
}, $text);

var_dump($text, $matches);

или покороче,

'name' => $result['short_name'] ?: $result['name'],

'name' => ($result['short_name'] ? $result['short_name'] : $result['name']),

Снести его нафиг и забыть, меньше мусора в системе будет.

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

Для решения задачи необходимо использовать внешние средства передачи данных. Поскольку весь каскад триггеров работает в одном соединении, проще всего использовать определённые пользователем переменные с предопределёнными именами, которые инициализируются на старте триггера и сбрасываются на его финише:

CREATE TRIGGER trigger_name
EVENT ACTION ON table_name
FOR EACH ROW
BEGIN
    SET @trigger_name_table_name = CONCAT('executed, ', 'column_value=', NEW.column);
-- trigger action
    SET @trigger_name_table_name = NULL;
END;

Если в теле триггера определены EXIT хэндлеры - они тоже должны выполнять соответствующие сбросы.

WakeOnLan +нечто мониорящее ваш сайт на предмет нажатости кнопки

Никак.
Лицензия получается XOR'ом ключа с вычисляемой (на самом деле, фиксированной) гаммой.
Зная только часть лицензии можно получить только соответствующую часть ключа.
Если знать все части лицензии, то достаточно записать их через '|', проXORить с вычисленной гамой и закодировать в BASE64.

То есть весь вопрос сводится к "при записи я кодирую данные c помощью json_encode, а при выводе не раскодирую, но виноваты создатели этого сайта".

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

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

Но в данном случае вообще непонятно, зачем сохранять ссылки в БД.
При заливке берётся id созданного пользователя, создаётся папка с таким именем, и в неё заливаются файлы.
При выводе файлы читаются из этой папки и выводятся.

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

В целом, даже если 450вт фактически хватает - он будет на предельных значениях работь, а тут и КПД ниже, и нагрев больше.
+ со временем (с годами) общая мощность БП может падать.

Так что лучше в ближайшее время купить более мощный БП.