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

Прочитав комментарии, заметил что вы слишком жестко указали версию php.
Лично я советую сатвить как можно меньшую (со знаком больше либо ровно), на которой конкретно ваш пакет будет работать.
Например, если конкретно ваш код, способен работать на 5.4, ставьте ее, возможно ваш пакет буду использовать на более старых системах. Естественно если есть прям зависимости ,которым нужно больше априори, то смысла в этом не будет. Но это считается хорошей практикой.
Те в вашем конкретном случае
"php": ">=7.2"
Но если есть, возможно ставьте "php": ">=5.4"

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

С айфремом ничего путного не выйдет, можно обходить и придумывать разной степени каличности и костыльности методы (не обхода ограничения, а методы примерно узнать что пользователь хотел сделать).
Короче гиблая история.
Лучше тогда быстро собрать через api свое решение, там простые методы(но только чтение/получиение данных) и после реализации получится свой виджет, который можно анализировать уже как угодно с высокой точностью.

Я не лез прям разбираться в ваш код на сайте, это неудобно.
Но проблема не в плагине. Плагин делает только две штуки: ставит превьюшку видео как обычную картинку, по клику динамически загружается iframe всего плеера youtube. Всё.
Ваша задача, реализовать новые функции по зыкрытию модельного окна.
Алгоритм:
1. Отслеживаете событие закрытие окна.
2. Когда событие сработало вы либо, через youtube js api ставите плеер на паузу (не знаю насколько это возможно в вашем варианте) либо полностью сами удаляете весь плеер, и восстанавливаете вид поумолчению, те то как должен выглядит код html с самого начала тег div с параметрами, но тут вопрос насколько динамически отслеживает библиотека, поэтому наверное легче будет снести вообще всё оттуда. А инициализировтаь div и библиотеку lazyYT динамически каждый раз когда модалка открывается.
Вообще конечно всё корявенько по совремнным меркам.

А вообще советую использовать тогда лучше уж plyr вмеcто устаревшего lazyYT , у него хотя бы api есть для удобного управления плеером.

Сразу отмечу что Юрий Бура отличный профессионал своего дела, курс его не изучал, но беглый взгляд показал что поход у него хороший, системный и он старается все же доносить суть. Главная целье его курса научиться пользоваться реактом, понять суть современного подхода к фроентенду в целом.
Далее уже по существу. Нужно погрузится в саму историю и причны появления Реакта. Инженеры в facebook в одно время сильно замучались строить интерфейсы, генерировать всё эту ерунду было сложно, еще проблемы уязвимостей (куча форм, для комментарией, постов, картинко и тп), недобный и громозкий PHP код заставил их задуматься об упрощении. Хотелось писать интерфейс как обычну функцию с параметрами, поэтому они придумали xhp, которые позволил буквально писать формы сразу в php (hack), легко, наглядно. Быстро видно что происходит, меньше ошибок, и легко использовать код формы (вместе с всей ее логикой построения, это и генерация формы на основе данных, и тп) заного много раз. Этот же подход был очень удобен и для других частей интерфейса, меня, списка постов и тп.
И это, с развитием новых концепций, браузеров, технологий и требований к быстроте интерфейса вдохновила их перенести этот концепт на JS, так родился React. Его революционность была в том, что на выходе резко упростились любые манипуляция с интерфейсом на фронтенде, сильно упал порог входа, получили легко читаемый и понятный код для решения практических задач (понятно, что при желании можно и тут засрать, но до этого в принципе большенство интерфейсов на js писалось через большие муки, с кучей неудобного кода, компромисами и тд и тп, а теперь все это взял на себя реакт).
Что мы имеем:
есть какая-либо часть интерфейса, логически независимая от других, с определенной структурой внутри - делаем компонент. Компонент это не только то, что мы обязательно будем использовать повторно (например), но понятная логически обособленная часть интерфейса, у которой может быть своя логика внутри, и своя функция на сайте снаружи.
Ничего страшного если сразу всё не продумал или на определенном этапе что-то идёт не идеально и тп.
Конечно хорошо иметь план на проект и проектировать многие вещи сразу, но рефакторинг, пивоты, изменения - вот реальность жизни.
Так что не волнуйся, первое что сделай измени восприятие самого интерфейса и приложения в целом. Теперь ты делаешь не сайт на html, а приложение с интерфейсом. Вот когда в таком ключе смотреть, то намного легче.

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

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

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

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

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

https://jsfiddle.net/bvuco1hj/
Дичь со

.stars div {
float: left;
}

Убираем.
Далее, stars_inner делаем realtive, а красный фон абсолютом

.stars__inner {
  position: relative;
}
.stars__progress {
  background: red;
  position: absolute;
  left: 0;
  top: 0;
  z-index: -1;
}

Лично я советую два источника:
https://www.codetriage.com/ - специальный сервис который позволяет удобно структурировать опенсурс проекты по issue и языкам, и выбрать для начала работы.
https://cultofmartians.com/ - интересный проект, приглашение к участию от одной из самых крутых команд в рунете. Ставят задачи, потом есть шанс и подружится с ними ближе.

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

Но повторюсь:

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

А так, Vue с JSX дружит, поддерживается.

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