Евгений Вольф

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

P.S. По моему, сам вопрос и браузерные редакторы кода, никак не связаны ни с PHP, ни с Laravel. При использовании PHP/Laravel они встраиваются точно так же как и при использовании HTML и JS.

2. Передавать какой-то секретный ключ с сервера АПИ и проверять его на сервере статистики. Этот вариант мне кажется наиболее удобным, но в каком виде его хранить и как передавать?

Видится мне, что это самый разумный вариант. Список адресов - не слишком надёжен и не особо логичен.

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

"Лучше" - сокеты, "проще" - AJAX.

Но это повысит нагрузку на сервер

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

Подскажите, как лучше верстать проекты. Может быть вы посоветуете другие подходы в разработке

Как лучше - зависит от конкретного случая, но, когда я занимался вёрсткой это выглядело примерно так:
0. Используем препроцессор, какой-нибудь, например SASS (SCSS)
1. Благодаря препроцессору, среди прочего - Вы можете дробить файлы стилей на сколь угодное число оных (хотя, я бы так делать не стал)
2. CSS (при нашем подходе) мог делиться на следующие части:

• Файл с основными (базовыми) стилями (в отдельных случаях он может быть включён в inline-виде прямо в заголовок страницы)
  
• Файл с дополнительными стилями
  
• Файл с общими медиа-запросами (по необходимости)
  
• Файлы с медиа-запросами на каждое разрешение (каждый файл грузится в зависимости от разрешения устройства)
  
• Файл с темой (если таковые есть)
  

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

*Выше озвучен исключительно наш подход к работе, выработанный нами и для наших проектов, далеко не факт, что подобный подход подойдёт Вам.

Так же, рекомендую ознакомиться со списком методологий (от себя к этому списку хочу добавить то, что подход "гадить в HTML-код, создавая при этом элементы без которых легко можно обойтись" - нарушает основополагающие рекомендации CSS-основоположников, по этому, в большинстве случаев, методологии пропагандирующие подобный подход нами даже не рассматриваются).

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 так далее, далее, далее... когда Вы будете всё это понимать - в голове будет складываться целостная картина происходящего, а не обрывки каких-то знаний. Разработка интернет-магазина в этом процессе, глобально, погоды не сделает, но какой-то опыт безусловно даст, главное, перед тем как будете разрабатывать собственный магазин - найдите какой-то уже готовый и постарайтесь в точности повторить его функционал, начиная от восстановления пароля заканчивая тем, как в корзине пересчитывается цена при изменении количества товара.

Поддерживаю автора предыдущего ответа, г-на Sanes. От себя добавлю, что если Вы хотите избежать избыточности - можете использовать, как Вы же сами и указали: lumen, silex и т.д., хотя лично я в этом особого смысла (в контексте вопроса) - пока не вижу.

Что посоветуете по фронтенду? Vue? Есть ли там какие-то наборы компонент по аналогии с ExtJs.

Я конечно могу ошибаться (на счёт ExtJS), но по моему, ExtJS - это набор копонентов, а Vue - это JS-фреймворк, что само по себе несколько разные вещи... Компоненты для VueJS есть, их много, в т.ч. готовых, они бывают самые разные и скорее всего, какие-то таблицы, календари, кнопки и прочую белиберду для Vue уже либо адаптировали, либо написали, либо [что-то ещё], но от этого аналогом ExtJS он не стал.

Особенно удобные гриды интересуют.

Удобные гриды есть сами по себе, их масса и к Vue или ExtJS'у они обычно отношения не имеют (хотя, вполне могут быть представлены как компонент VueJS или адаптированы специально под него), например: DataTables.

Такое vue может или всё с 0 ручками там пилить надо будет?

Как я уже говорил ранее, в режиме "из коробки" в Vue нет вообще никаких "компонентов" (я имею в виду компонентов аки jQuery UI и ему подобных), он для другого предназначен. А может или нет... - скорее может, чем нет. Но можно и "ручками".

Если всё с 0, то где можно посмотреть бесплатные макеты-вёрстки аля админка? Я не дизайнер просто.

Как бы это странно не прозвучало, но в поисковике. Там этого добра - тонна, "по рублю за пучёк", например: раз, два, три и т.д.

P.S.

Но тут наверное мне нужен микрофреймворк. С lumen/slim/symfony4 - что было бы проще или лучше?

По моему, Symfony-4 это всё же не микрофреймворк... Это всё тот же старый добрый симфони, после "серьёзной липосакции" по умолчанию. Микрофреймворк от авторов Symfony -- это Silex.

Насколько надежен этот хеш? Реально ли получить исходный пароль зная хеш? Возможно это в принципе?

Надёжность хэша зависит от алгоритма хэширования.

Я думаю это довольно надежная защита. Но как это реализовать?

Я тоже думаю, что это довольно надёжная защита от брутфорса паролей, что в целом никак не говорит о защите во всём остальном. Как реализовать - самые простые варианты:
а) Записывает с какого IP была неудачная попытка входа с датой и временем события в БД (или любое другое хранилище, которые Вы используете), при попытке ввода пароля - проверяете, сколько неудачных попыток ввода с этого IP была за прошедшие N времени, если больше чем X - попытка ввода пароля блокируется
б) Аналогично пункту А, но проверяете не IP адрес, а логин, по которому пытаются залогинится
в) Сочетание пунктов А и Б
г) Масса других вариантов, коих просто прорва, включая применение гугл-капчи, систем распознавания ботов а так же различные сочетания методов защиты и всяческих извращений, в т.ч. выше описанные.

Реально ли получить исходный пароль зная хеш? Возможно это в принципе?

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

Я подумал начать изучать криптографию, чтобы улучшить защиту и хранить не хеш пароля, а хеш шифра пароля.

Осталось дело за малым:
1. Изучить (Вам) криптографию на уровне достаточно для реализации поставленных задач, в т.ч. для написания собственных криптографических алгоритмов (методов шифрования), о которых говорилось тут:

Безусловно, нужно еще этот метод шифровки придумать, но это уже другой вопрос.

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

P.S. Судя по контексту Вашего вопроса, Вы пытаетесь создать какую-то "мега-защиту" в одном месте, упуская из внимания то, что защита формы для ввода пароля и этого механизма в целом (у нас же про это идёт речь?) - это ~1% от общей безопасности среднестатистической системы, и примеров тому - масса. Например, есть просто масса примеров того, когда у крупных почтовых провайдеров внезапно "утекала" база данных пользователей, в т.ч. с их паролями (хэшированными, разумеется) и связано это было не с брутфорсом (и ему подобными деяниями) явно, есть всякие там Heartbleed, от которой "официально" пострадали очень крупные компании, за сетевой безопасностью в которых следили люди разбирающиеся в данном вопросе куда лучше, чем Вы, я и все остальные участники данного вопроса - вместе взятые... и т.д. [очень много разных примеров]. Вы же всерьёз не думаете, что цель любого хакера заключается в том, что бы подобрать или получить какой-то отдельно взятый пароль и (даже если его цель заключается именно в этом, внезапно), что этот самый хакер будет до потери пульса "биться лбом о стену" в попытках получить этот самый злополучный пароль путём брутфорса по форме авторизации или чем-то подобным и в результате неудачной попытки вся его "хакерская деятельность" на этом и остановится?

а как на самом деле дела обстоят — есть достоверная информация по браузерам?

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

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

Как првильно написать панель навигации и футер один раз, и вставлять их код в мою страницу ? Плохо ли это для индексации ? Желательно 2 варианта: на php и js

На PHP это выглядит максимально просто. Например так:
1. Сохраняете код футера и хедера, например, в корешке сайта, и называете их footer.php и header.php соответственно.
2. Подключаете на каждую страницу их примерно так:

<?php include("{$_SERVER['DOCUMENT_ROOT']}/header.php"); ?>

*аналогично с футером.

Соответственно, страницы, в которых вы будете делать вставку php-тега, должны либо иметь расширение PHP, либо обработка других расширений должна быть настроена на сервере так же, как буд-то это PHP-скрипты.

На индексации, конкретно данный метод не скажется никак, так как поисковые боты не могут знать, как именно у Вас сгенерировалась страница (да им и всё равно, по большому счёту).

P.S. Вариант на JS приводить не буду, т.к. то способ, которым Вы хотите реализовать это через JS, во первых будет ощутимо сложнее, во вторых - будет создавать дополнительные запросы на сервер, в третьих - не все поисковики корректно индексируют подобное.