Алексей Уколов

В первую очередь надо смотреть на то, когда заканчивается поддержка у той или иной технологии. И у PHP 7.4 она закончилась ещё в 2022 году.

Это означает, что дыры в безопасности уже никто чинить не будет. А там их немало. И сайт будет всё проще и проще взломать с каждым новым днём.

Возможно, ваш хостер имеет возможность внедрять патчи расширенной поддержки от Zend, которые так же закончатся уже в 2026 году.

Поэтому, обновить стоит. Но перед этим надо убедиться в работоспособности сайта с этой версией.

1. Полный бэкап файлов и базы. Это даже не обсуждается. Если у хостера бэкап не купили, купите.

2. Обновите всё, что сможете до последних версий. Разработчики часто добавляют совместимость для новых версий PHP в эти последние версии. Это касается и ядра WordPress, и плагинов, и темы, если она была куплена, а не писалась с нуля. Если тему писали с нуля, то можно связаться с разработчиком, чтобы он дал вам точный ответ, будет ли тема работать, или сделал бы поддержку 8.3

3. После обновления плагинов и тем проверьте в их документации совместимость этих обновленных версий с PHP 8.3.

4. Используйте плагин проверки совместимости, чтобы узнать, будет ли ваш сайт работать на 8-х версиях PHP. Он старый, но именно с этой задачей поможет справиться. https://wordpress.org/plugins/php-compatibility-ch...

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

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

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

Никак

Как медиа станции эти коробочки хороши.
Но если вам действительно нужен сервер, то физический размер реально решает, а мини-ПК под это дело не подходит.
Вы будете ограничены во всем.
1. Процессор не сменить - он распаян.
2. Слотов под ОЗУ мало, а те что есть не дадут вам поставить планки с макс. емкостью - ограничение арх. процессора.
3. Процессор - всегда используется ноутбучный энергоэффективный вариант - как ресурс сервера так себе.
4. Нельзя нормально организовать RAID. Вам же нужна будет надежность хранения и наращивание скорости в x-раз от кол-ва накопителей?
5. Нельзя нормально подключить полноценные видеокарты. А БП на внешней видеокарте куда поставите - рядом с мини-ПК?
6. Нельзя нормально охладить систему в маленьком объеме, если вам нужно включить на пиковую производительность вычисления на 24/7.
И так далее, все преимущества мини-ПК - это недостатки для сервера.

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

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

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

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

Где хотите, удобнее или просто где вам требуется.

Первый же вопрос в FAQ:

How can the parent of a node be obtained?
-----
The AST does not store parent nodes by default. However, the `ParentConnectingVisitor` can be used to achieve this:
...

У вас файл создан под Уиндоуз, в которой в качестве разделителя строк используется последовательность \r\n
Разбивая по \n, вы в конце каждой строки оставляете висеть символ \r, и в итоге при сравнении совпадает только последний элемент файла, после которого нет перевода строки

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

$array = file(JPATH_SITE.'/list.txt', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);

И всё сразу начнёт находиться.

Подсказывала и проверяла мои работы

Как может оценивать работу то, что само не может в 80-90% случаев написать нормальный код?

Рассуждала о возможных приоритетах и помогала в направление

Есть такой сайт https://roadmap.sh/ - он поможет с направлением

Ответы чтобы были более человеческие, а не сухие

Это можно решить промтом, задай его так, чтобы она тебя называла папочкой и в конце строк писала ^-^

Нейросеть не способна заменить собой ментора и учителя. Она способна подобрать последовательность буковок, которая кажется правильной. Тебе поможет курс(возможно платный) или ментор, который даст тебе и план, и проверки, и направления.

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