Михаил Р.

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

Разумеется, только в БД.

Маловероятно, конечно, но если вдруг проект разрастётся, то он будет разрабатываться не на коленке путем правки похапе файлов прямо на сервере, а через систему контроля версий и регулярный деплоймент командой разработчиков. И все эти "почти никогда не изменяемые данные" будут засорять историю правок и требовать ажно целого программиста ради добавления одного слова в статусы модерации.

Или, если сформулировать короче, то данные должны лежать в базе, а в РНР файлах - только код.

interfaces.pro - живые
froala.com/design-blocks - шаблоны

убрать enter между code и var тыц

Я давно знал что dreamveaver лучше вообще обходить стороной. Но так и не успел перейти на phpstorm.

Если Вы юзаете dreamveaver, то вероятно Вам нужен не phpStorm, а webStorm.

Или может проблема в коде?

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

Ох! Чтобы изучить laravel вам нужно изучить php (сюда же базы можно приплести) и, как я понял из контекста вопроса, js. Отвязывайтесь от изучения фрэймворков, а то к финалу изучения laravel+vuejs выяснится что они уже депрекейтед и будете опять наблюдать картину типа "Я просмотрел вакансии на разных сайтах, чтобы понимать, какой стэк технологий нужен работодателям, и в требованиях я вообще не нашёл, что им нужен jQuery"

1 – удобно
2 – наверное придется, но если вы хорошо знаете js то процесс миграции во vuejs будет безболезненным
3 – ни плохим и не хорошим. Вы должны прочувствовать все фичи которые дает laravel из коробки, а их набор настолько не большой (в базе), что будет достаточно сделать каки-то наброски абстрактного приложения

1) хз
2) А тут по подробнее:
- vue - это маст хев на ближайшие годы не зависимо от laravel.
- vue не исключает использования jquery, хотя я уверен, что любой плагин можно найти и на чистом js.
- судя по тому, что Вы пишите, Вы явно не видели варианты со сборкой vue из компонентов. Там в html лишнее не попадает, не больше, чем с jquery
3) Если от легкого к сложному, то явно не интернет магазин. Вначале блог или новостной сайт, потом каталог "чевачупчичей", а потом уже сами поймете куда двигаться.

ПС. Я не верен. Что изучение laravel и vue стоит совмещать. Наверное кашка может получиться. Лучше вначале освоить vue + сборщики, хотя бы азы, до состояния "дочитал до конца документацию, но хрен что запомнил", а потом вникать уже в laravel.

1) На сколько удобны Homstead + Vagrant, которые они рекомендуют использовать? Посмотрел информацию по его установке, использовании. Разве это удобнее всем привычного openServer?

Насколько удобен конкретно именно этот стек, и насколько он удобен будет лично для Вас - сказать затрудняюсь, но в общей сложности, использование "родной" среды при разработке приложения - практика весьма правильная. Думаю что в данный момент, большинство моих эпитетов на тему "почему оно так и зачем" Вам будут не очень интересны, но, есть простой пример из реальной жизни: в *nix, чаще всего, файловые системы чувствительны к регистру имён файлов, в Windows [NTFS] (и OpenServer в частности) - такой чувствительности нет, что влечёт за собой потенциальные ошибки в самый неподходящий момент (когда Вы будете выгружать сайт на хостинг) и исправить их "по быстрому" удаётся не всегда, по этому, я бы рекомендовал использовать "родной" Linux при разработке. Какой стек взять - сакрального значения не имеет, мы используем: Docker (Hyper-V), VirtualBox + настроенную самостоятельно вирт. машину и различные другие варианты (среди которых, OpenServer проскакивает крайне редко).

2) Прямо из коробки Laravel поддерживает Vuejs, но посмотрев их курсы на Laracasts и ещё пару примеров компонентов для него, мне показалось, что он не совсем подходит для того, чтобы делать на нём те же слайдеры, системы частиц и подобные вещи.

VueJS - это JS фреймворк, волей судьбы "встроенный" в Laravel. Как мы знаем, JS относится к области вёрстки, что в целом с фреймворком серверным связано крайне слабо. Какие элементы в вёрстке использовать лично Вам - дело - лично Ваше. Из собственного опыта могу сказать, что мы в своей работе не гнушаемся ни VueJS, ни jQuery, ни различными готовыми слайдерами и вообщем всем, что может быть уместно в рамках конкретных требований конкретного проекта. По сему - я думаю Вам не стоит забивать себе этим голову. Насколько и чем хорош VueJS - можно узнать из массы уроков по оному.

Вообще не понравилось, что в HTML-разметке вставляются ивент-слушатели, как в стандартном JS прям (@click, onclick). Мне это напомнило встраивание CSS прямо в тэги. Мне нравится в jQuery то, что все ивенты вешаются прямиком в скрипте, не заглядывая в HTML-разметку.

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

Я просмотрел вакансии на разных сайтах, чтобы понимать, какой стэк технологий нужен работодателям, и в требованиях я вообще не нашёл, что им нужен jQuery, только Vuejs. Отсюда и вопрос, то есть мне нужно переписать свои слайдеры, системы частиц под Vuejs? Часто встречал сообщения о том, что переплетать эти две технологии плохая затея. Либо то, либо то. Посмотрел предложенные готовые слайдеры, вообще не впечатляют.

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

3) Хорошим ли является планом, чтобы сделать воображаемый интернет-магазин для обучения и освоения Laravel? Или как лучше изучать эту технологию от легкого к сложному? Всегда была проблема с тем, чтобы структурировано изучать ту или иную область разработки. Чтобы не тупо копировать, а понимать, как всё устроено и как работает.

Что бы понимать что-то структурно - нужно понимать истоки. В области веб-разработки таковыми "истоками" могут являться например, протокол HTTP, фундаментом которого будет протокол TCP/IP, в основе которого лежат другие технологи... чем лучше Вы будете понимать как всё работает изначально, и в результате чего появилась, например, такая парадигма как MVC, как работает composer так далее, далее, далее... когда Вы будете всё это понимать - в голове будет складываться целостная картина происходящего, а не обрывки каких-то знаний. Разработка интернет-магазина в этом процессе, глобально, погоды не сделает, но какой-то опыт безусловно даст, главное, перед тем как будете разрабатывать собственный магазин - найдите какой-то уже готовый и постарайтесь в точности повторить его функционал, начиная от восстановления пароля заканчивая тем, как в корзине пересчитывается цена при изменении количества товара.

Процитирую сам себя:

У enterprise-приложений есть три основных качества:

1. Большая и сложная кодовая база;
   
2. Высокие требования по надёжности и производительности;
   
3. Длительный срок эксплуатации.
   

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

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

Без SVG, картинок и псевдоэлементов,
CSS only

то, что вы ищите - usleep

В остальном ваш код доводит до слез этого кота

words.replace(index, 1, word.charAt(0));

Метода replace у массивов нет. Есть splice.

как реализовали бы данную задачу вы?

// собираем новый массив
const newWords = words.map(n => n[0] || '');

// обновляем существующий
words.forEach(([ n = '' ], i, a) => a[i] = n);