antimind

$roles = User::where('id', '1')->first()->roles();

Так ты только получаешь запрос.
Чтобы получить окончательный результат либо добавляй в конце ...->get(), либо сразу вызывай ->roles:

$roles = User::where('id', '1')->first()->roles()->get();
$roles = User::where('id', '1')->first()->roles;

В обоих случаях $roles будет хранить коллекцию ролей, а не просто запрос.

Валидация полей форм
Создаешь форму.
Создаешь Реквест файл.
Прописываешь там правила и сообщения.
Подключаешь в контроллере, в метод куда идет пост-запрос и данный файл будет валидировать поля.
Middleware не валидирует поля. Используют, чтобы фильтровать запросы. Например, разрешить доступ к определенным роутам только пользователям, которые отвечают условиям. Плюс провести действия в процессе проверки. Например, заблокированных разлогинить и редирекнуть на главную.

Сделаю за тебя

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

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

Лично я бы не был посредником у начинающего. Зачем мне головняк, даже за какой-то процент.

Ctrl+Shift+R

так же как и в 2018, 2017, 2016...

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

Выберите какой-то из парсеров. DiDom, dom-crawler или zend-dom, например.

пользуйте twig.

Blade это обертка, которая несет в себе незначительные отличия от нативного php

В вашем случае вам лучше посмотреть в сторону Twig или Smarty, у последнего точно есть возможность отключения нативных методов языка и опционально ими управлять. В моем опыте он как раз использовался для тех целей что преследуете вы

Вы из 2007 чтоли? SPA React Angular Тысячи их! Зайдите хоть на тот же ютуб без кеша и с обрезанной скоростью...

Ох, опять эта тема :)

Для начала могу сказать какой точно никогда, ни при каких обстоятельствах не использовать - W3 Total Cache. Это адище с большой буквы. Туда же все остальные плагины, которые пытаются быть "все-в-одном" и предоставлять 120 страниц конфигурации. В топку.

Далее, давайте мухи отдельно и котлеты отдельно. Есть object cache - у него свои задачи. Есть fragment cache - у него свои. Есть full page cache - это отдельная кухня. Есть кеширование на уровне сервера (nginx fastcgi_cache), все тот же full page cache но "навыворот". А еще Nginx умеет разговаривать с Memcached напрямую. И даже если сравнивать решения, которые делают одно и то же (например, тот же full page cache), разница в "эффекте" на разных серверах и даже на разных сайтах на одном сервере будет. Часто - существенная. Плюс, есть кеширование на многих уровнях на самом сервере - файловая система, кеши БД и тд. И все эти настройки будут влиять на поведение плагинов кеширования. Часто - существенно. Кеширование на стороне клиента - отдельная кухня, начиная с server push, prefetch и тд, выдача поддерживаемых форматов (brotli/gzip, woff/woff2/ttf, webp/jpg/png и тому подобное).

В общем, performance - это целый комплекс мер, решений и инструментов. Подходить к этому надо с умом и четким планом, полным пониманием всего процесса от инициации запроса клиентом и до... а нету точки Б, потому что там свои моменты.

А еще надо понимать, что ваш медленный DNS может убить всю экономию на PHP runtime. Или криво установленный SSL-сертификат. Или кеширование SSL-сессий, некорректно настроенное под специфику трафика конкретного проекта. Или канал на выходе перегруженный. Или далеко не оптимальный конфиг пула PHP. Или вообще Apache. Или I/O wait зашкаливает.

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

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