Александр Талалаев

У вас что-то с версией php, нужно чтобы была >= 7.2.5.
Проверьте и в консоле php -v и в вашей сборке XAMPP с помощью phpinfo()
Версия в консоли важна, так как от неё зависит исполнение команд, артизана и установки в целом.
Ну а на а сервере, что очевидно, чтобы вообще приложение работало.

Всё хотят и работа активно ведётся, делают новую версию(без обратной совместимости).
Поэтому ждать релиза и пока продакшн проекты не обновлять.
А так, есть dev ветка, можно поучаствовать в тестах и экспериментах. Laravel 7 уже поддерживается.
Вот можно и следить за реализацией фич.

Есть простой вариант, легче вам будет сделать так:
в моделе User

/**
 *  Получаем читаемую дату.
 *
 * @return string
 */
public function getHumanDateAttribute()
{
  //Таймзону лучше брать из настроек приложение, а не хардкод
  $timezone = config('app.timezone');
   return  Carbon::parse($this->created_at, $timezone)->isoFormat('Do MMMM YYYY');
}

Ну и потом в коде или в шаблонах вызываешь
$user->human_date;
Если делаешь сериализацию в json и нужно чтобы этот атрибут был и там, то в моделе добавляешь:

/**
     * The accessors to append to the model's array form.
     *
     * @var array
     */
    protected $appends = ['human_date'];

Blade в любом случае это рендринг на стороне сервера.
Любые динамические действия это JavaScript(за редким исключением).
Значит далее вы уже решаете каким путём идёте.
Можно идти популярным ныне путём создания компонентов и постройки интерфейса на реактивных фронтэнед фреймворках. При это не значит что нужно переписывать весь код, весь сайт делать SPA и тд. И react и vue, да и angular (и тд) вполне можно использовать и в более меньших масштабах, для небольших интерактивных компонентов. Laravel умеет со многими дружить практически из коробоки, в сети полно инструкций на этот счёт. И этот путь я вам советую.
Второй вариант, более классический. Это решение на jquery (хотя можно и чистым js). Здесь вы можете делать например Ajax запросы к серверу, и там генерировать, в том же blade, часть select, а потом динамически подгружать.
Кстати в Blade сейчас тоже появились компоненты (Laravel 7) советую почитать, возможно будет полезно.
PS кстати на счёт первого подхода, вместе с Laravel 7, недавно вышел Livewire , специально разработанный под Laravel фулстек фреймворк для создание динамических сайтов, советую глянуть. Позволит быстро строить разные штуки, и порог входа ниже и проще React и Vue. В нём больше ориентация на AlpineJS. И в любом случае, после изучения, будет легче потом и Vue и React и изучать если что.

Я возможно чего-то не понял, но вопрос странный, особенно для того кто просто, хотя бы заглянул в документацию.
В Laravel есть события, их можно создавать, слушать и тп.
Более того, там даже пример кода для событий по статусам заказа (доставка, и отправка уведомления о доставке) :-)

Чтение документации и изучение хорошей пратики всё таки немного облегчает жизнь.
Итак.
Хранить в БД url, как делаете вы, обычно не выгодно и неинтересно. Это нужно в исключительных случаях одно разового мини проекта, когда вы точно знаете настроки меняться не будут и файлы редактироваться не будут. Либо, в специализированных БД для кеширования результата генерации url.
В иных случаях хранить в БД нужно имя файла. Имя файла в идеале разбить конечно, но в подавляющем числе случаев достаточно будет два поля: имя с путём + имя диска. Это закроет большинство кейсов для будущего масштабирования. Но если уж совсем лень, то имя диска тоже можно опустить, хотя я советую добавить это поле.
Далее, ваш код:

$path = Storage::putFile('public/img', $request->file('img'));
$url = Storage::url($path);
$post->img = $url;

Меняем на более простой (хотя аналог можно и из вашего конечно сделать, убрав строчку с $url и сохраняя в модель $path)

// file('img') - это имя файла(инпута формы например) из запроса
// store('img') - это имя подпапки для
// 'public' - Диск из настроек (см filesystems.php)
$path = $request->file('img')->store('img', 'public');
$post->img = $path;

Теперь и удалать легко. не забываем что с файлами мы работаем(по умолчанию), относительно папки /storage/app/(слеш в начале я поставил чтобы показать что путь от корня папки с проектом)
Поэтому, когда вы передаёте в метод удаления сгенерированный заранее url. он ничего не найдёт и не удалит.
Но теперь мы храним как раз относительный путь файла.
Storage::delete($post->img);
Теперь сработает, не забываем очистить поле, после удаления, если вы при этом не удаляете сам пост.

Далее, сам url получаем так
$url = asset($post->img);
Ну, или если вы делаете сразу в blade шаблонах
<img src="{{asset($post->img)}}">
Ну и конечно я всякие проверки и тп опустил для простоты

Главный спорный вопрос который вам стоит решить: где хранить статичный первод (надписи, что не меняются или меняются редко, например название кнопки - Отправить/Submit, те все то, что мы обычно не храним в БД и редко меняем).
Варианта два:
1. Использовать только реакт для этого, тогда берете пакет react-localization, там достаточно простые и понятные принципы, сложностей нет.
Преимущества: фронт полностью отдельно живёт и не зависит от бэкенда, нет дополнительных прослоек, нет привязки к определенному бэекенду и тп

2. Использовать возможности локализации Laravel. Но тут все таки все методы той или иной степени костыльности, либо как минимум добавляющий жесткую привязку фронтенд приложения к текущему стеку бэкенда
Преимущества: можно использовать разные пакеты для интеграции средств редактивования статической локализации в бэкенде.

Лично я всё же склоняюсь к первому варианту, так как люблю писать максимально (желательно полностью) назависимые фронтенд приложения.

Теперь вторая часть вопроса. Уже касаемо динамических переводов (это контент, комментарии, и тп, условно говоря всё что мы храним в бд, или храними информацию о них в бд).
Здесь я советую положится на Laravel, берёте пакет от spatie laravel-translatable, он позволяет быстро строить удобные интерфейсы редактирования/чтения переводов в БД, пишете простое API и ри инициализации react приложения получаете данные нужные вам локализации, либо даже отправляете все сразу (они хранятся в json поле mysql/ваше БД, даже доп преобразований особо не потребуется).
Но вариант с отправкой только нужной мне нравится больше, смена локали событие редкое, а вот экономия на размере переданных данных будет существенная.

Ну, а далее уже вешаешь всякие кеширования тп, чтобы всё летало и готово.

Скорее всего настройки просто скешировались.
Выполните в консоле следующую команду
php artisan config:clear

Самый простой способ это:

public function page($slug) {
$page = Page::where('slug', $slug)->firstOrFail();

return view('template.pages', [
  'pages' => $page
 ]);
}

1. Проверить .env файл APP_URL= установи с https:// , хотя обычно это не влияет, но потенциально может использоваться где-либо и в зависимости от настроек http сервера выдавать ошибку.
2. Очищаем кеш настроек:
php artisan config:clear
php artisan config:cache
3. Очищаем общий кеш
php artisan cache:clear

$user = User::withCount('lists')
                    ->find(Auth::id());

Все просто, ресурсный контроллеры создают роуты с переда автоматически на основе базового имени роута, таким образом у вас теперь:
Route::resource('/blog', 'NewsController'); и таким образом ваш ресурсный контроллер ожидает переменную одну, а получает другую. Вообще у тебя должны быть написано Route::resource('blogs', 'NewsController'); и таким образом в параметры уйдет переменная blog с объектом. Но так как метод у тебя уже написан $news (да не удачно, как же единственное число, хех. Впрочем сам я такое попадался).
Так, короче говоря в web :

Route::resource('blog', 'NewsController')->parameters([
    'blog' => 'news'
]);

Ну и в параметрах методов контроллера замени везде "$id" на "News $news", хотя в целом у тебя уже не ресурсный контроллер, например метод store. Так что возможно тебе лучше расписать все в ручную. В целом изначально ресурсные контроллеры подходя либо под api логику работы, когда ты имеешь дело с Моделью/Сущностью как с ресурсом и тебе нужны стандартные методы, либо многие используют в своих CRUD логиках, но опят таки только если логика без дополнительных усложнений и переплетений как у тебя. Де факто у тебя не ресурсный контроллер и я настоятельно рекомендую расписать его в ручную.
PS еще для отладки роутов отлично подходит команда php artisan route:list будет видны все роуты которые ларавел генерирует, с соответствующими параметрами переменными.