Ипатьев

command-not-found

Не нужно ничего экранировать. Нужно использовать параметризованные запросы с плейсхолдерами.

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

Модели:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class User extends Authenticatable
{
    use HasFactory, Notifiable;

    /**
     * @var array<int, string>
     */
    protected $fillable = [
        'name',
        'email',
        'password',
    ];

    /**
     * Получить данные пользователя, связанные с этим пользователем.
     */
    public function userData()
    {
        return $this->hasOne(UserData::class);
    }
}

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class UserData extends Model
{
    use HasFactory;

    /**
     * @var array<int, string>
     */
    protected $fillable = [
        'phone_number',
    ];

    /**
     * Получить пользователя, которому принадлежат эти данные.
     */
    public function user()
    {
        return $this->belongsTo(User::class);
    }
}

Создание записей

use App\Models\User;
use App\Models\UserData;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Hash;

DB::transaction(function () {
    // 1. Создаем пользователя (User)
    $user = User::create([
        'name' => 'Вася Пупкин',
        'email' => 'uasya@fsb.ru',
        'password' => Hash::make('12345'),
    ]);

    // 2. Создаем данные пользователя (UserData) и связываем их с пользователем
    $user->userData()->create([
        'phone_number' => '112',
    ]);
});

P.S. ИМХО: ненавижу Eloquent и весь паттерн Active Record. Как по мне, вместо него лучше уж просто чистым SQL пользоваться. А вот если нужна мощная ORM, то уж лучше воспользоваться Doctrine. Там вообще такой проблемы нет, и всё делается автоматически.

вот простой вариант
создаём две bash функции cp1 и cp2
первая сохраняет полный путь к файлу
вторая копирует файл по сохранённому пути в текущую(.) директорию

cp1(){ echo "$PWD/$1" > /tmp/cp1;}
cp2(){ cp "$(cat /tmp/cp1)" .;}

чтобы каждый раз в новой сессии не прописывать можно закинуть их в конец файла .bashrc(если используете bash)
использование банальное

cp1 ФАЙЛ
cd куда-то/там
...
cp2

для mv всё будет аналогично

private string $requestUri = '/';
...
if ($this->requestUri !== '/') {

То есть, при инициализации экземпляра вы записываете в requestUri слэш, а перезаписываете значение только если там не слэш. Соответственно, условие всегда ложно и тело условия не выполняется.

Если задача всплывает часто, освой Midnight Commander или иной двухпанельный файловый менеджер. Он запускается в терминальном режиме и прекрасно подходит для таких ситуаций.

Скорее всего дело в сессии. Попробуйте вставить вызов session_write_close() непосредственно перед выводом файла:

header('Pragma: private');
header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');
header('Content-Length: ' .filesize($file));
session_write_close(); // <--- вот здесь         
readfile($file);
exit();

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

Как общаются микро-сервисы в реальных проектах?

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

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

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

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