Алексей Коновалов

use Illuminate\Database\Eloquent\Casts\Attribute;

class Order extends Model{

    protected $casts = ['date_time' => 'datetime:Y-m-d H:00'];

    function dateTime(): Attribute
    {
         return Attribute::make(
            get: fn () => $this->castAttribute(
                  'date_time',
                  ($this->date ?: '1970-01-01') . ' ' . ($this->time ?: '10:00:01')
               )
            )
        );
    }

}

# php artisan tinker
App\Models\Order::first()->date_time;
# = Illuminate\Support\Carbon @0 {#7053
#   date: 1970-01-01 00:00:00.0 UTC (+00:00),
#  }

https://laravel.com/docs/10.x/eloquent-mutators#de...

Фронт развился в какую-то неправильную сторону, это правда
Вкатиться на фронт очень сложно, это тоже правда. Причём, необоснованно сложно.

Я бы выделил два пути, как можно въехать во всё это:
1. Создать приложение на Vue или React по туториалам, затем разобраться, как и зачем оно всё
2. Разобраться как и зачем оно всё (aka Vanilla JS), потом заняться реактами

Имхо, вариант №2 предпочтителен и более прост, потому что на варианте №1 есть огромный шанс застрять, никогда не разобравшись, как оно работает а при любых нешаблонных ошибках поднимать лапки.

Что здесь нужно понимать:
1. Есть разные версии ES (ecmascript), они все обратносовместимые. Программист может писать на любой версии, какая ему нравится. Обычно берут последнюю стабильную

2. Для проекта обычно есть две версии ES: та, на которой пишут программисты и та, которая исполняется в браузере или в ноде (об этом позже). Например, программист пишет на ES8, а код транслируется на ES5. Это позволяет использовать последние предсмертные хрипы писки моды JS при этом запуская всё на древнейшем говне вроде IE11. Перегонкой кода из JS/TS одной версии в JS другой версии занимается транспилятор: babel / esbuild / swc

3. Новые версии JS содержат расширения стандартной библиотеки, которых нет в старых браузерах (например Array.from, Object.entries и т.п.). Эти дырки затыкают полифиллы, они же shims. Самая популярная дырозатыкательная машинка — corejs

4. Весь код очевидно не пишется в одном файле и может быть написан на TypeScript (он же TS), JSX/TSX (реактовый синтаксис). Всё это нужно собрать в один или несколько файлов, то есть скомпоновать. Этим занимается bundler: часть webpack / esbuild / spark / etc.

5. Этот же парень отвечает за то, чтобы та тысяча библиотек, что лежит в node_modules, попала в итоговый условный main.js, но не целиком, а только то, что используется. Последнее называется tree shaking (типа навозную кучу node_modules потрясли как дерево, что упало — то не нужно)

6. (то самое "позже) Код может исполняться не только в браузере пользователя, но и на сервере без браузера вообще. Это нужно для SSR aka Server Side Rendering. SSR — это такой глобальный вонючий костыль для SEO. Дело в том, что стандартные SPA приложения содержат один DOM элемент, куда цепляется всё остальное приложение вроде реакта или вью, которое уже содержит всю вёрстку прямо в JS. Но не все поисковики согласны с таким подходом и некоторые (не будем показывать пальцем на яндекс) не умеют выполнять JS и индексируют только тот самый единственный DOM элемент, который существует на этапе отдачи страницы в браузер. Это уже потом к нему JS движком дорисовывается весь остальной сайт. Соответственно, сайт индексируется от слова "никак", а некоторым это важно. Например, когда SPA — это не админка. Для этого есть два выхода: страницы, важные для SEO, рендерить чем-то не-реактовым или сделать SSR — делать за яндекс работу на сервере (на ноде), представляя в уме, что у нас есть DOM и браузер (на самом деле нет), на выходе получать начальное состояние HTML, отдавать его клиенту (браузеру или поисковому роботу), а JS'ом её т.н. "гидрировать", иными словами — оживлять.

7. webpack отвечает за всё вот это сверху в том или ином виде. Это такой кухонный комбайн, в который вкидываешь кучу хлама в одном виде, а получаешь другую кучу хлама в другом виде.

Начать советую с parceljs, который сильно проще в освоении, чем webpack. И на написании кода максимально без библиотек.

Чтобы 100% надежно - это брать данные у первоисточника, т.е. из Youtube API, информация тут https://developers.google.com/youtube/v3/docs/vide... , вам нужна будет часть snippet (параметр part=snippet в запросе к API):

https://www.googleapis.com/youtube/v3/videos?id=%VIDEO_ID%&part=snippet

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

Если $dynamic_url найден в массиве $ignore_pages то true иначе false

Но это бредовая идея, т.к. in_array и так вернет true или false

$ignore =in_array($dynamic_url,$ignore_pages);

А в чём собственно проблема в преобразовании на лету?
Преобразование делать в любом случае, так что рано или поздно доведёте свои регулярки до правильного состояния. Что там "пойдёт насмарку", если вы в механизм, понимающий только bb-коды, не передадите атрибуты data, в упор непонятно.
Пробегитесь заранее по своей табличке новостей своим преобразатором, и проконтролируйте результат хотя бы выборочно хотя бы визуально (если заморочиться, поищите или напишите какой-нибудь bb-линтер).

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

Для просмотра документации нужно нажать Ctrl+Q на функции.