Adamos

Из определенной папки - на сервере? С локальными папками вас вполне может ждать облом элементарно по политике безопасности, которую браузер обязан соблюсти. Открывать что попало с локальной машины он не может.

Если файл формируется вашим кодом, можно загнать в дата-ссылку сам файл в base64. Такое браузер откроет.

Имхо:
1. Для работы с текстом противопоказаны мониторы больше 24 дюймов. Если, конечно, речь о мониторе в 20 см перед носом, а не висящем на стене в паре метров от стола. Физиология и геометрия никаким пиаром не отменяются.
2. Для работы с текстом на диагонали до 24 дюймов на хрен не нужны ни 2к, ни, тем более, 4к. Особенно если зрение уже садится, и всю эту мелкоскопию все равно не разглядишь.
3. Для работы с текстом не стоит рассматривать VA. Слишком заметно размытие при прокрутке и проч. Тем более, что разница в цене между ними и IPS уже давно практически исчезла.

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

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

<?php FixMoney($data[$user['cash']]) ?>
Смотрим в хрустальный шар... внимательно смотрим... ВИЖУ!!!
<?php FixMoney($data[$user]['cash']) ?>

Проверить /etc/apt/sources.list на наличие строчки

deb http://ru.archive.ubuntu.com/ubuntu/ focal-proposed restricted main universe multiverse

Ну, или аналогичной для того сервера, откуда вы берете обновления.
В этом репозитории пакет mysql-server для ubuntu 20.04 есть.

Раз все равно "все, которые остались", значит, это вопрос условия сортировки.
Условие пока не сформулировано - если статус 1 у пяти статей, которые три из них надо брать?
Ну, и вымучивая один запрос, неплохо бы проверить, не получится ли он медленнее четырех простых: взять три последних айдишника (индекс, мгновенно), один первый (аналогично), три первых (видимо) по статусу, исключая полученное на предыдущих запросах (а вот с этим в одном запросе подзатрахаешься конкретно) - и окончательный селект, у которого в сортировке указаны эти айдишники как повышающие приоритет.

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

P.S. Подозреваю, третье условие просто сформулировано через жопу, и отдельного запроса здесь не надо - просто сначала вывести со статусом 1, а потом без.

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

У графического meld есть именно такой режим сравнения, весьма наглядный.

Виртуалке хорошо бы иметь аппаратную виртуализацию на процессоре. Это если настраивать снаружи.
А если предположить проблему изнутри - стоит сменить экспериментальную версию с вечно-экспериментальным DE на рабочие: вместо Ubuntu 23.04 взять Xubuntu 22.04, например. Если она будет работать с той же скоростью захода солнца - тогда уверенно искать проблему снаружи. А то ведь может оказаться, что она летает, просто у Каноникал очередной эксперимент не удался - вайланд недоделан, например...

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

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

Ну, если разобраться...
Что такое обычные отношения? Вот у поста есть id, а у фотки есть post_id. Так она приколочена к этому посту.
Что такое полиморфные отношения? Вот у поста есть id и у коммента есть id, а у фотки есть morph_id - в котором хранится, внезапно, все то же значение id поста или коммента, которому она принадлежит. Только, чтобы разобраться, к кому именно, хранится еще и morph_type, в котором прописано, например, имя модели, которая по этой связи будет обращаться: "App\Models\Post" или "App\Models\PostComment".

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

windows 11, которая установлена рядом всё работает

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

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

это такая муть, если бы я знала, возможно и не начинала бы

Да, пожалуй, не стоило.

при каждой итерации идёт обращение к ORM таблице городов, сравнивается описание города и если оно отличается происходит апдейт записи.

Вообще-то для этого достаточно одного INSERT ... ON DUPLICATE KEY UPDATE.
Ну, а массовая вставка по одной строчке - это верный способ убить БД на любых ресурсах независимо от движка сайта.

Если у вас пыховое приложение на древней версии, в нем стопудово куча дублирования кода и велосипедов там, где фреймворк предлагает готовое, отлаженное и стандартное.
Нет смысла переписывать велосипеды на ООП только для того, чтобы потом понять, что из них нужно только вычленить (и все равно во многом переписать) бизнес-логику, а все остальное надо просто выкинуть.
Кроме того, CRM - это куча однообразного контента и на фронте. Сразу перенести его на современный фрейм, в котором данные на бэке и фронте аккуратно синхронизируются, может опять-таки оказаться быстрее, чем мучить те велосипеды.
Ну, а если все сделано в худшем стиле и комком - вовсе оставить копролит и переписать с нуля шаг за шагом. Именно для последующего развития и поддержки.