Author Archives: Pashaster

About Pashaster

Создатель и основной автор данного проекта. Профессиональный разработчик с 4-летним стажем.

Laravel update: обновляем движок за 8 шагов

laravel-updateВсем привет! :-)

Если вы следите за судьбой фреймворка Laravel, то могли обратить внимание, что сравнительно недавно свет увидела новая версия движка — 5.5.

В ней появилось много интересного функционала, в частности, возможность предпросмотра отправляемых email в браузере, которую я в будущем планирую продемонстрировать с помощью Laravel Mailable.

А чтобы это и другие новые фичи были у нас доступны, то нужно сделать update Laravel движка.

Если вы подписаны на уведомления проекта и следите за выходом новых статей, то знаете, что сейчас я активно занимаюсь написанием курса по созданию сайта на Laravel. В его рамках я совместно с вами изучаю Laravel на примере создания типового корпоративного сайта, код которого доступен на GitHub.

Начинал я его разрабатывать на Laravel 5.3, потом пытался обновиться до 5.4, но, как выяснилось позже, сделал это не совсем корректно, о чём узнал, не обнаружив анонсированных фич новой версии в коде core-классов.

И теперь, когда вышел Laravel 5.5, я решил попробовать снова, проанализировав ошибки, допущенные ранее.

Так что сегодняшняя публикация — это даже не статья, а заметка, которая будет посвящена процессу обновления версии Laravel и будет представлять из себя пошаговую инструкцию.

Сразу скажу, что не претендую на 100% правильность своих действий, т.к. никаких подобных мануалов я по этой теме в сети не нашёл, поэтому пришлось экспериментировать :-)

Если по ходу изложения информации поймёте, что всё написанное — чушь, и вы знаете более правильный способ сделать Laravel update — пишите об этом в комментариях и делитесь своими знаниями со всеми.

Поехали!

А нашо оно мне надо?

Это первое, что вы услышали бы от одессита, которому предлагают сомнительную сделку. Сам я не оттуда, но почему-то кажется, что это звучало бы именно так :-)

Под сомнительной сделкой я имею ввиду как раз необходимость обновлять Laravel. Поэтому перед тем, как приступать, взвесьте все «за» и «против», к которым приведёт данное действие.

Для этого перед Laravel update изучайте список функционала, появившегося в новой версии, который доступен на официальном сайте Laravel. Например, для 5.5 он имеет следующий вид.

Конкретно в моём случае «за» перевесили «против», т.к. мне необходим функционал новой версии на моём текущем проекте, а он, в свою очередь, не так огромен, что делает обновление практически безболезненным. Ну, и версии у меня не так уж сильно и разнятся — 5.3 и 5.5.

Поэтому если вы создаёте корпоративный сайт вместе со мной по ходу написания статей по Laravel, то я вам настоятельно рекомендую выполнить обновление, чтобы описываемый в будущем функционал у вас заработал.

Кстати, если вы, как и я, обновляетесь до Laravel 5.5, то прошу учесть, что данная версия фреймворка будет устанавливаться и работать только на веб-сервере с PHP 7+, так что если вы по каким-то причинам не можете её изменить, то от обновления лучше всё-таки отказаться.

Если же данное действие не проблематично, то воспринимайте данное требование как возможность наконец-то перейти на PHP 7 и начать использовать его возможности по-полной :-)

По поводу других ситуаций, когда лучше всё-таки отказаться от Laravel update.

Если бы у меня был масштабный проект вроде MarketPlace или огромного Интернет магазина с кучей функционала, а также с массой сторонних библиотек и Laravel packages, реализованный, скажем, на Laravel 5.1, то, скорее всего, я бы отказался от полноценного обновления до 5.5 ради парочки бонусных фич.

Если бы проект был на Laravel 4.2 или ранее — сразу бы отказался, т.к. отставание четвёртой ветки от пятой огромное как в плане архитектуры, так и в плане самого подхода к разработке.

Возможно, я даже дописал бы новые функции сам или мигрировал бы с чистого проекта на свежей версии.

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

А именно в этом и заключается обновление Laravel «по уму», т.е. следовательно официальным инструкциям, которые, например, для 5.5 доступны здесь — laravel.com/docs/5.5/upgrade. Как видите, здесь подробно описаны действия по переходу с Laravel 5.4 на 5.5 — что нужно убрать, добавить в существующем коде и как поменять архитектуру проекта, если это нужно.

Ориентировочно, весь процесс рассчитан примерно на час времени.

А если нужно «перескочить» с 5.1 на 5.5? Умножайте это время как минимум на 4. Да плюс добавьте масштабы проекта. И эти расчёт будут действительны, как вы понимаете, только для идеального Laravel update, т.е., когда всё получится с первого раза. Но, сами понимаете, что практически никогда так не получается.

В итоге, на полноценное обновление у вас уйдёт до 2-3 дней. А теперь ещё раз ответьте себе на вопрос «Стоит ли оно того?» :-)

Инструкция по Laravel update

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

1. Бэкап — всему голова.

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

Причём, в случае с бэкапом проекта перед Laravel update, он должен содержать ВСЕ файлы, а не только те, что хранятся в репозитории, куда сами файлы движка не попадают.

Лучше на мгновение почувствовать себя школьником, которые не знают о существовании репозиториев, и бэкапят проекты архивами полностью, чем потерять потом что-то ценное.

2. Скопировать содержимое composer.json из репозитория (для требуемой версии Laravel).

Данное действие нужно для того, что от версии к версии движок расширяется новыми компонентами и отказывается от устаревших. Кроме того, меняются их версии.

Если же вы решили произвести обновление Laravel проекта, содержащего сторонние пакеты, команды, специфичные классы автозагрузки и прочее, указываемое в composer.json, то вам лучше сравнить ваш конфиг и содержащийся в репозитории какой-нибудь специальной программой сравнения содержимого файлов типа Meld. Ну, и внести руками нужные изменения. Медленно, зато у вас ничего не «отвалится», т.е. не перестанет работать :-)

Поскольку в моём тестовом проекте пока ничего подобного нет, то я позволил себе просто заменить имеющийся composer.json на аналогичный файл из репозитория Laravel 5.5.

3. Удаляем composer.lock.

Этот файл, как известно, хранит текущие версии установленных через Composer пакетов. Поскольку файл composer.json, на основании которого lock и создаётся, у нас изменился, я решил удалить последний, чтобы не возникло никаких проблем при обновлении.

4. Очистить кэш Composer.

Данное действие производится запуском следующей команды в консоли:

composer clearcache

Данный шаг необходим для получения актуальных версий пакетов, указанных в composer.json. Иначе они будут ставиться из кэша композера, а не скачиваться.

К примеру, если раньше через Composer вы устанавливали версию пакета 5.2.3, прописанную в composer.json в формате «5.2.*», а сейчас вам нужна версия 5.2.41, то, если кэш не очистить, установится первая как закэшированная.

Следовательно, фреймворк, скорее всего, работать будет не совсем как нужно или вообще не будет.

5. Чистим кэш Laravel.

Вслед за кэшом Composer нужно очистить кэш самого фреймворка от данных, которые могли быть созданы с использованием устаревших пакетов.

Делается это консольной командой, которую нужно запускать в директории Laravel проекта:

php artisan cache:clear

Для уверенности можно пройтись по директориям, вложенным в /storage/framework. Если какие-то файлы там чудом остались, их необходимо удалить вручную кроме .gitignore, чтобы не добавлять файлы кэша в репозиторий — они там не нужны абсолютно.

6. Удалить папку vendor Laravel проекта.

В этом каталоге хранятся файлы движка, которые при Laravel update должны обновляться. Но у меня при обновлении с 5.3 на 5.4 некоторые всё-таки не дополнились новыми конструкциями. Поэтому в этот раз я решил её попросту удалить и скачать затем заново.

Не бойтесь, шаг этот безопасный (если только вы не вносили какие-то правки на уровне движка или кода пакетов, что крайне нежелательно) — все проекты, которые вы разворачиваете у себя на машине из репозиторией, включая сам «чистый» Laravel и так идут без данного каталога.

7. Установка Laravel и пакетов через Composer

На данном этапе нам нужно, фактически, заново установить Laravel со всеми необходимыми для его работы компонентами. Для этого запускаем консоль, переходим в каталог Laravel проекта и выполняем знакомую команду, описанную в статье по ссылке выше:

composer install

8. Проверяем, что установилась требуемая версия Laravel.

Всё, обновление завершено. Надеюсь, никаких проблем в процессе не возникло. Для того, чтобы удостовериться, что Laravel у нас обновился не нужно лазить по файлам движка и искать анонсированные новые фичи. Достаточно лишьвыполнить следующую консольную команду в директории проекта:

php artisan --version

В моём случае в консоли показало 5.5.5 (красивое число :-) ). А у вас?

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

Ну, и если статья вам понравилась, то вы можете сказать мне «Спасибо», репостнув статью в социальных сетях или помочь проекту материально, замотивировав меня уволиться с основной работы и всецело посвятить свою жизнь написанию статей для вас :-)

Всем удачи и до новых встреч!

Что такое лендинг пейдж простыми словами: 4 примера

chto-takoe-lending-pejdzhПриветствую вас, друзья :-)

Сегодня я решил на мгновение отвлечься от написания статей по Laravel и поговорить с вами на более массовые темы, а именно, о всеми любимой электронной коммерции.

Если вы следите за проектом «Сделай сайт своими руками» с самого начала и подписаны на обновления, то вы, наверняка, помните вводные статьи о различных типах сайтов.

Тогда мы подробно рассмотрели блог и Интернет-магазин. Сегодня я решил продолжить разговор (внезапно… :-) ) и рассказать вам о том, что такое landing page и как его создать своими руками.

Landing page является прекрасным и уникальным инструментом электронной коммерции, позволяющим увеличивать продажи на 20-30% даже владельцам крупных и именитых Интернет магазинов.

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

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

Как?

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

Также мы рассмотрим примеры различных посадочных страниц и то, чем лендинг пейдж отличается от сайта.

Поехали :-)

Что такое landing page?

Говоря простыми словами, лендинг — это очень простой одностраничный сайт, посвященный, как правило, одному продукту.

Главное преимущество такой страницы — донести потенциальному покупателю основную информацию о продукте в сжатой, но очень информативной форме. Если обычный сайт чаще всего носит многоцелевой характер, то лендинг пейдж сосредоточен только на конкретном действии.

Цели у посадочных страниц (еще одно альтернативное название лендинг пейджа) могут быть самыми разными.

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

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

К нам landing page пришли немного позже, но они также прекрасно подошли под реалии Рунета.

Лендинг пейджи создают и успешно используют торговые компании любых объемов и ниш, предприниматели в области информационные услуги, компании, работающие на рынке уникальных товаров, туристические операторы, салоны красоты, спортивные клубы, кафе, рестораны.

Этот список можно продолжать до бесконечности, однако уже понятно, что посадочные страницы эффективны для любого вида деятельности.

Структура Landing page

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

  • Заголовок.

    Он же носит название самого одностраничника и продукта, о котором идет речь на лендинге.

  • Видео или изображение (ряд картинок в слайдере).

    Это основной элемент для привлечения внимания пользователя.

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

  • Информация о продукте.

    Это блок, где можно подробней рассказать о своем товаре, описать все его преимущества и выделить уникальные свойства.

    Постарайтесь выложить как можно больше полезной информации о продукте, но не забывайте указать и его недостатки.

    Ведь каждый из нас знает, что идеальных товаров не бывает.

  • Отзывы.

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

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

    Здесь уместно размещать не только отзывы в текстовом формате — видео и аудио отзывы станут прекрасными инструментами для привлечения внимания потенциальных клиентов.

  • Форма обратной связи.

    Без нее никуда. Это ваша база контактов и возможность связываться с пользователями в случае их заинтересованности в вашем продукте.

  • Призыв к действию или Call to action.

    Это яркая и заметная кнопка, которая побуждает пользователя совершить действие.

    Текст на кнопке может быть следующим: “Купить”, “Узнать”, “Заказать”, “Подписаться” и т.д.

  • Футер и кнопки социальных сетей.

    Очень рекомендуется на лендинг пейдже, который вы создаете, настроить футер и разместить там ссылки на политику конфиденциальности, правила использования продукта и т.д.

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

Виды лендингов

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

На сегодняшний день известно как минимум четыре типа landing:

  • long page (длинный одностраничник);
  • short page (короткий лендинг пейдж);
  • one step (одношаговая страница);
  • two step (двух шаговая страница, где на первой странице формируется интерес к продукту, а на второй — осуществляется призыв к действию).

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

Данный метод, кстати, может отлично подойти в ситуациях, когда вы продаете инновационный продукт, к которому рынок не готов. Однако, главное — чувство меры, чтобы у посетителей вообще появилось желание перейти на вторую страницу :-)

Зачем нужен лендинг пейдж?

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

Главный показатель того, что landing действительно эффективен и приносит своему владельцу пользу — конверсия. Даже при минимальной конверсии в 2-4% можно говорить о том, что необходимость создания лендинг пейджа совершенно оправдана.

К задачам посадочной страницы относятся:

  1. Дает возможность клиенту, прочитав важную для него информацию, принять окончательное для себя решение и заказать ваш товар.
  2. Оформление заявки на обратный звонок от менеджера вашей компании для обсуждения некоторых деталей относительно покупки продукта, его возможной доставки и других параметров.
  3. Подписка пользователя на рассылку ваших новостей, чтобы быть в курсе некоторых новинок, акций и других выгодных предложений, или же регистрация в каком-нибудь мероприятии.
  4. Скачивание книг и другого материала, просмотр каталогов и т.д.
  5. Поиск работы и просмотр актуальных вакансий.

Безусловно, это далеко не все задачи, которые способна решить посадочная страница. Однако красивый лендинг точно повысит вашу конверсию и привлечет внимание целевой аудитории.

Страница с конверсией от 15% уже считается грамотно созданной и эффективной.

Идеальный лендинг — это место, где пользователь может получить ответы на все свои вопросы относительно продукта. Такая страница не должна оставлять у пользователя сомнений, что ему нужен именно этот товар.

Хороший лендинг пейдж это всегда простота оформления с логически выстроенными элементами, ведущими к единому действию.

Как создать лендинг?

На вопросы о том, что такое лендинг пейдж и зачем он нужен, мы ответили. Давайте теперь поговорим о том, как можно создать landing page самостоятельно.

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

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

Но я, честно говоря, их недолюбливаю…

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

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

Итак, как же сделать лендинг самому?

Выбор шаблона лендинга

Лендинг — особенный тип сайтов.

В то время как для создания Интернет магазинов, порталов, блогов сложно обойтись без готовых платформ в виде CMS, фреймворков и т.д., то для создания лендинг пейдж достаточно всего лишь купить красивый шаблон, наполнить его актуальной информацией (контактные данные, информация о продукте) — и сайт готов!

А поскольку правильно подобранный шаблон — это 90% успеха, то к его выбору нужно подойти с особой ответственностью.

Первый шаг на этом пути — определиться с биржей шаблонов.

Критерии выбора должны быть следующие:

  1. Большой выбор шаблонов.
  2. Тщательная техническая модерация добавляемых продуктов (некачественный шаблон может не только непрезентабельно смотреться, но и стать источником вируса).
  3. Гарантированная техническая поддержка.
  4. Демократические цены.
  5. Удобная система оплаты.

Казалось бы — ничего сверхъестественного в этих требованиях нет. Но на деле найти биржу шаблонов лендинг пейдж, удовлетворяющую всем этим требованиям, очень сложно.

Лично я достаточно долго искал подходящую и в конце-концов остановился на TemplateMonster, как идеально им соответствующую. Шаблонов там действительно масса.

Приведу несколько особенно меня впечатливших, которые подойдут для создания landing page по различным тематикам.

Фото тематика/ Бизнес

html-shablon-lendinga-dlya-biznesa

Одностраничник, позволяющий связаться с владельцем такого лендинга, чтобы заказать какую-нибудь услугу. Блоки для размещения дополнительной информации, кнопка Call to action, фото — внутри весь функционал для быстрого запуска лендинга.

Свадебная тематика

primer-shablona-lending-pejdzh-dlya-svadby

Шаблон лендинг пейджа с собственной админкой. Удобный инструмент для приглашения родственников и друзей на мероприятие. Имеется функционал обратного отсчета времени.

Искусство и фотография

adaptivnyj-bootstrap-lending-dlya-foto-studii

Еще одно решение для представления своих услуг и работ для заказа.

Организация событий

luchshie-bootstrap-shablony-landing-page-dlya-iventov

Шаблон лендинг пейджа решает задачу по сбору контактов потенциальных заказчиков.

По поводу рассмотренных вариантов скажу, что качество их разработки — на высоте. Техподдержка также исправно осуществляется.

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

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

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

Тем более, что цены на TemplateMonster вполне приемлемые. К примеру, качественный шаблон лендинг пейдж можно купить, начиная с 19$.

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

Способов оплаты просто тьма, начиная от карт MasterCard/Visa, заканчивая привычными нам WebMoney и Яндекс.Деньги.

ThemeForest же сильно заточен под Западную аудиторию и PayPal, счёт в котором в Украине или России открыть нереально.

MasterCard/Visa тоже присутствуют, но при каждом платеже взымается комиссия в размере 2$, что не совсем красиво. Когда выбираешь шаблон, рассчитываешь на одну стоимость, а при оплате она оказывается другой.

Наполнение лендинга информацией

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

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

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

Благодаря ей вы узнаете, как найти интересующий элемент в коде, а изменить его значение на своё — вопрос техники :-)

Если же вы понимаете, что описанное выше для вас всё равно слишком сложно, изменить необходимо “труднодоступные” надписи в шаблоне (например, текст на кнопке слайдера) или же поменять какие-то блоки местами, куда удобней будет использовать шаблонное решение на базе CMS.

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

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

Кстати, при покупке шаблона на TemplateMonster у вас есть возможность заказа установки админки даже на HTML шаблон лендинга и «натяжки» его на интересующую вас CMS за отдельную плату.

Заливка готового лендинга на хостинг

Этот процесс полностью идентичен с публикацией в сети обычного сайта.

Для начала необходимо подобрать и зарегистрировать доменное имя вашего лендинг пейдж. Сделать это можно с помощью специальных сайтов-регистраторов.

Подходите к этому вопросу максимально ответственно, т.к. как корабль назовёте, так он и поплывёт :-)

После этого необходимо не менее серьёзно подойти к выбору хостинга и тарифа.

Вариант использования бесплатных хостингов я сразу откидываю, т.к. потерять время и деньги на создание лендинг пейдж и утратить свой сайт спустя некоторое время — слишком большая цена экономии 10$ в год на услугах платных хостингов.

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

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

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

Продвижение лендинга

Ну вот и всё. На этом процесс создания идеального лендинга окончен.

Однако это еще не повод сидеть сложа руки в ожидании высокой конверсии и больших объемов продаж. Для того, чтобы все это заполучить, необходимо уделить серьезное внимание продвижению одностраничника для охвата большей аудитории.

Способов достичь желаемого масса. Кратко рассмотрим самые действенные и рабочие из них.

  1. Социальные сети и ремаркетинг.

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

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

  2. Блог.

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

  3. Обмен статьями.

    Обменивайтесь своими постами с другими блогами, размещайте в них ссылки на свой одностраничник.

  4. Конкурсы и розыгрыши.

    Интерактивность редко бывает неинтересной и непривлекательной. Это очень эффективный способ обратить на себя внимание.

  5. Связь с партнерами.

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

  6. Реклама в социальных сетях.

    Даже при небольшом бюджете уделяйте внимание рекламе в социальных сетях.

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

  7. SEO-оптимизация.

    Этот пункт один из наиболее важных. При правильном SEO-продвижении вы можете рассчитывать на высокие позиции в поисковиках.

    Кроме этого, затраты на SEO всегда с лихвой окупаются.

Как видите, инструментов привлечения трафика на лендинг пейдж действительно много.

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

Для этого достаточно выполнить всего несколько действий, описанных далее в виде краткой инструкции.

Так называемая техническая или внутренняя SEO оптимизация landing page включает:

  • Мета-теги title и description.

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

  • Мета-тег keywords.

    Хоть Google и Яндекс уже давно его не учитывают, масса других поисковиков все еще с ним считается.

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

  • Заголовки H1, h2.

    Главный заголовок H1 должен использоваться на сайте не более одного раза, тогда как h2 допустимо прописывать до 6 раз на одной целевой странице.

  • Alt и title в изображениях и другой графике.

    Обязательно прописывайте эти атрибуты с использованием ключевых запросов.

  • robots.txt.

    Есть мнение, что для одностраничников ничего в файле robots.txt прописывать не нужно, однако даже такие мелочи помогут вам эффективней продвигать свой лендинг пейдж.

Более подробно о SEO продвижении сайта вы можете узнать из статьи по ссылке.

Итак, мы поговорили о том, что такое landing page, какими они бывают и как они помогают улучшить позиции в бизнесе при наличии высокой конкуренции.

Минимум функционала и только сжатая информация о продукте эффективно действуют на принятие решения о покупке.

Также мы рассмотрели процесс создания landing page и его продвижения своими силами и с минимальными вложениями. Так что пробуйте, дерзайте и пишите в комментариях о своём опыте использования лендингов для успешного ведения бизнеса.

Помните, что только проведение экспериментов и вечный поиск возможностей развития своего проекта поможет вам достичь конверсии на уровне 25-30% и успешно продавать в интернете. А по-другому в современном мире с его бешеной конкуренцией и не получится :-)

На этом у меня всё.

Удачи и до новых встреч! :-)

Laravel отправка почты: обзор 5 основных драйверов

laravel-pochtaВсем привет! :-)

Те, кто подписан на обновления проекта, и следит за выходом статей знают, что в прошлой публикации мы на примере создания формы обратной связи рассмотрели реализацию популярной технологии AJAX в Laravel.

В ней мы реализовали отправку запроса серверу и сценарий действий на сайте после получения ответа. Осталось только написать скрипт Laravel, отправляющий email сообщение администратору на сервере, вместо которого у нас сейчас стоит заглушка в виде вывода параметров запроса.

Сделать это я обещал в следующей статье, т.е. в текущей. Однако, при подготовке материала пришёл к выводу, что одной статьи будет мало для детального обзора всех способов Laravel email sending и полноценной реализации одного из них.

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

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

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

Поехали!

Особенности отправки почты в Laravel

Поскольку Laravel — PHP framework, то отправить email в коде можно средствами PHP, воспользовавшись функцией mail(). Или можно вообще воспользоваться сторонними приложениями типа sendmail, развернув их у себя на ПК в виде локального почтового сервера.

Эти способы рабочие, универсальные и гибкие в настройке, но на этом, по правде говоря, их преимущества заканчиваются. Спрашивается — «А что ещё нужно-то?» :-) Ответ большинства разработчиков будет прост — удобство.

К примеру, вам хочется украсить своё письмо, добавив туда HTML-разметку и CSS-стили. Отправка такого письма с помощью PHP mail() будет выглядеть примерно так:

<?php
$to = 'receiver@test.com';
$subject = 'Тестовое письмо с HTML';

$message = '
<html>
    <head>
        <title>Тестовое письмо с HTML</title>
        <meta charset="utf8">
    </head>
    <body>
        <p>Пример таблицы</p>
        <table>
            <tr>
                <th>Колонка 1</th><th>Колонка 2</th><th>Колонка 3</th><th>Колонка 4</th>
            </tr>
            <tr>
                <td>Ячейка 1</td><td>Ячейка 2</td><td>Ячейка 3</td><td>Ячейка 4</td>
            </tr>
            <tr>
                <td>Ячейка 5</td><td>Ячейка 6</td><td>Ячейка 7</td><td>Ячейка 8</td>
            </tr>
        </table>
    </body>
</html>
';

$headers[] = 'MIME-Version: 1.0';
$headers[] = 'Content-type: text/html; charset=utf8';
$headers[] = 'To: Receiver <receiver@test.com>';
$headers[] = 'From: Sender <sender@test.com>';
$headers[] = 'Cc: copy@test.com';

$result = mail($to, $subject, $message, implode("\r\n", $headers));
echo $result ? 'OK' : 'Error';

Если же воспользоваться API Laravel, то отправка такого же сообщения будет занимать всего пару строчек кода:

Mail::send('emails.test', [], function ($message) {
            $m->from('sender@test.com', 'Sender');
            $m->to('receiver@test.com', 'Receiver')->subject('Тестовое письмо с HTML');
            $m->cc('copy@test.com', '');
        });

Единственное, HTML код шаблона будет размещаться в отдельном файле /resources/views/emails/test.blade.php, который указан в качестве первого аргумента.

В целом, как по мне, данный пример очень убедительно демонстрирует удобство API Laravel для отправки email.

Кстати, данная АПИ-шка в Laravel реализована на базе популярной библиотеки SwiftMailer, являющейся компонентом Symfony PHP framework, которые очень любят использовать разработчики Laravel.

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

Единственный минус, который я смог найти при настройке отправки почты в Laravel через его API, — это обильная порой возня с настройками и установкой дополнительных пакетов, чтобы тот или иной способ заработал. Но это частный минус.

Плюсов же по сравнению с нативными методами намного больше.

Во-первых, это — удобство использования.

Во-вторых, куча примочек в виде создания специальных Mailable классов, которые придают удобство при массовых рассылках однотипных писем в различных местах кода.

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

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

Laravel почта — настройка

Я сейчас говорю об использовании специальных драйверов для различных способов отправки писем в Laravel и экспериментов с файлами конфигураций .env, /config/mail.php и /config/services.php.

Если о драйверах мы поговорим далее, то со структурой файлов познакомимся сейчас.

Из коробки в файле .env уже существует специальный блок переменных окружения для настроек отправки почты. Их легко узнать по приставке MAIL:

MAIL_DRIVER=smtp
MAIL_HOST=smtp.mailtrap.io
MAIL_PORT=2525
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null

Ну, а что по поводу /config/mail.php и /config/services.php?

Открываем первый из перечисленных и что же мы видим? Содержимое файлов я приводить не буду, т.к. у всех из коробки оно одинаково — просто откройте их у себя на компьютере.

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

Исключение составляют только следующие:

'from' => [
    'address' => 'hello@example.com',
    'name' => 'Example',
],

С помощью данных параметров у нас есть возможность указать email и имя отправителя для всех писем по умолчанию, отправляемых с нашего Laravel сайта.

По поводу остальных параметров из mail.php — я буду изменять их в своём файле файле окружения, т.к. если я буду править сам конфиг, то мои настройки зальются в общий репозиторий и только будут вас сбивать.

Ну, и в файле services.php ситуация не сильно отличается от mail.php: практически все параметры берутся из .env.

Так что в дальнейшем я буду править .env, а вы просто повторяйте за мной. Кстати, поскольку для различных способов отправки email в Laravel будут требоваться различные переменные из стандартного набора, то те, которые содержатся у нас в .env сейчас с приставкой MAIL я просто удалю, чтобы не путаться.

Исключение составит только переменная окружения MAIL_ADMIN_EMAIL (если вы, конечно, создаёте сайт вместе во всеми по данному Laravel курсу и уже добавили её), которая нужна для указания email администратора для отображения его в сообщении об ошибке в форме обратной связи.

Ну, а в сами файлы конфигураций mail.php и services.php мы будем заглядывать лишь за тем, чтобы узнать имена необходимых переменных с целью их добавления или редактирования в .env.

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

Отправка писем в Laravel через API почтовых сервисов

Первый способ отправки email в Laravel, который я решил рассмотреть, это — использование различных почтовых сервисов через их API.

Всё, что от вас потребуется для его реализации — это наличие аккаунта Mailgun, Mandrill, SparkPost или Amazon SES (на данным момент Laravel из коробки поддерживает только их) и установка необходимого пакета для реализации совместимости сервиса с Laravel.

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

Настройки Laravel Mailgun

Для отправки почты через данный сервис в первую очередь необходимо установить в Laravel Guzzle HTTP library. Делать мы это будем, естественно, через пакетный менеджер Composer.

Итак, открываем консоль и переходим в каталог, где расположен наш Laravel проект. Выполняем следующую команду:

composer require guzzlehttp/guzzle

В консоли будет описываться порядок установки. После успешного завершения всё, что нам останется для завершения настроек — это дополнить файл окружения .env следующим кодом:

MAIL_DRIVER=mailgun
MAILGUN_DOMAIN = ваш_домен
MAILGUN_SECRET = ваш_ключ

Переменным MAILGUN_DOMAIN и MAILGUN_SECRET нужно указать значения, полученные после регистрации в Mailgun для использования его АПИ.

Настройки Laravel Mandrill

Для настройки отправки почты Laravel через данный сервис процедура будет во многом схожа с предыдущим. Для начала устанавливаем Guzzle HTTP library.

А затем идём в Laravel .env и добавляем следующее:

MAIL_DRIVER=mandrill
MANDRILL_SECRET = ваш_ключ

Переменной MANDRILL_SECRET нужно указать значение, полученное вами при регистрации в Mandrill для использования его АПИшки.

Кстати! Процедура настройки Mandrill в официальной документации Laravel в последний раз была описана для версии Laravel 5.2, но, судя по коду движка, использование данного сервиса доступно до сих пор (видимо, решили оставить для работы старых приложений).

Поскольку в новых версиях фреймворка создатели Laravel по каким-то причинам решили отказаться от Mandrill, то придётся немного пошаманить и добавить в /config/services.php следующий блок для успешной отправки писем:

'mandrill' => [
    'secret' => env('MANDRILL_SECRET'),
],

Настройка Laravel SparkPost

Поддержка данного сервиса, если верить официальной документации, появилась в Laravel 5.3. Поэтому если у вас приложение использует более раннюю версию фреймворка, то данный способ у вас не сработает. Либо обновите Laravel, либо воспользуйтесь другим способом (благо, их хватает).

Для успешного использования SparkPost нам потребуется всё та же Guzzle HTTP library и следующие переменные окружения в файле .env:

MAIL_DRIVER=sparkpost
SPARKPOST_SECRET = ваш_ключ

Настройка Laravel Amazon SES

Данный почтовый сервис, как и SparkPost, появился в Laravel 5.3, придя на замену Mandrill. Поэтому, если вы используете более раннюю версию движка, то вам стоит либо обновиться, либо использовать другой способ отправки email в Laravel.

Его настройка будет слегка отличаться от предыдущих почтовых сервисов, т.к. для его поддержки в Laravel потребуется не знакомая уже Guzzle HTTP library, а другой пакет — Amazon AWS SDK for PHP, который устанавливается следующей командой в консоли:

composer require aws/aws-sdk-php:3.*

После установки дополняем файл .env следующими переменными окружения:

MAIL_DRIVER=ses
SES_KEY=ваш_ключ
SES_SECRET=ваш_секретный_ключ

Думаю, и так понятно, что значения ключей вам должны быть доступны после регистрации в Amazon SES. Кстати, не забудьте проверить код своего региона, сгенерированный Amazon. Если он будет не ‘us-east-1′, то зайдите в файл /config/services.php и задайте необходимое значение параметру ‘ses'[‘region’].

На этом обзор поддерживаемых Laravel API почтовых сервисов подходит к концу. Переходим к обзору следующего способа отправки почты.

Отправка почты в Laravel через SMTP

Думаю, что многие в курсе о протоколе передачи почты SMTP. Так же, многие знают, что практически все современные почтовые сервисы предоставляют свои SMTP-сервера для отправки почты с сайтов через них.

По сути, предыдущий способ отправки почты в Laravel через почтовые сервисы — это то же самое, что и текущий. За тем лишь исключением, что в первом случае мы отправляем письма через API сервиса, а во втором — обращаясь к почтовому серверу напрямую.

Ну, и при отправке через SMTP вы можете пользоваться любым почтовым сервисом, который предоставляет такую возможность (Gmail, Яндекс Почта и т.д.), а взаимодействую с сервисом по АПИ, вы имеете доступ лишь к избранным, которые поддерживает Laravel. Вот и вся разница :-)

Всё, что нужно сделать пользователям, чтобы воспользоваться возможностью отправки писем в Laravel через SMTP — это зарегистрироваться в сервисе и узнать настройки подключения к SMTP-серверу (адрес или доменное имя сервера, порт, шифрование и т.д.).

Ну, и ввести их в Laravel должным образом:

MAIL_DRIVER=smtp
MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME=ваше_имя_пользователя
MAIL_PASSWORD=ваш_пароль
MAIL_ENCRYPTION=tls

Выше приведён пример настроек Laravel для отправки почты через SMTP сервер почтового сервиса Google — Gmail. Я решил выбрать именно его, т.к. почтовый ящик gmail.com есть, наверное, практически у всех, поэтому данный способ подойдёт большинству.

Laravel почта — отправка с помощью PHP mail()

Спрашивается — «Что это за ерунда?» :-). Зачем использовать PHP mail() в качестве драйвера для отправки почты, если можно напрямую вызвать эту функцию в коде? Ответ всё тот же, что и ранее — для удобства, т.к. при использовании драйвера мы получаем возможность использовать API Laravel для «прокачанной» и более удобной отправки писем.

Итак, какой будет порядок настройки?

Для данного способа он будет самым что ни на есть примитивным. Достаточно будет содержания в файле окружения .env следующей строки:

MAIL_DRIVER=mail

Отправка письма в Laravel через sendmail

Скажу честно, о том, что с sendmail я познакомился сравнительно недавно. Ровно тогда, когда узнал, что в Laravel есть возможность отправлять email с помощью данной штуки.

Поэтому позволю сделать небольшое вступление для таких же, как я, о том, что такое sendmail.

Sendmail, как гласит Wikipedia — это один из древнейших агентов отправки почты на уровне ОС.
На данным момент существуют версии данного приложения практически под все операционные системы и аппаратные платформы.

Почти во всех Unix-подобных системах имеется в базовой комплектации. Для запуска под Windows, насколько я успел заметить, нужно дополнительно скачивать.

Распространяется бесплатно в виде исполняемого файла с конфигами и исходным кодом. Таким образом, для запуска sendmail необходимо будет запустить его исполняемый файл.

Ну, а для отправки почты в Laravel с помощью sendmail во-первых, нужно указать соответствующий драйвер в файле окружения .env:

MAIL_DRIVER=sendmail

И поскольку отправка email будет осуществляться с помощью системной утилиты, то фреймворку необходимо указать путь к её исполняемому файлу. Для этого в конфиге /config/mail.php есть специальный параметр, в качестве значения которого прописываем путь к sendmail на сервере (или локальной машине):

'sendmail' => '/usr/sbin/sendmail -bs',

В данном примере приведён код по умолчанию, который будет работать на Unix-подобных системах.

Laravel почта — запись логов

Напоследок я оставил обзор драйвера отправки почты в Laravel, с помощью которого email отправить не получится. Зато он отлично подходит для дебага процесса формирования и отправки письма.

Это становится возможным благодаря записи в логи Laravel сформированного текста email сообщения, которое обычно отправляется приложением на почтовый ящик конечного пользователя.

Чтобы включить данную возможность в Laravel, необходимо выполнить примитивную настройку, как и в случае использования PHP mail(). Достаточно всего лишь указать драйвер отправки почты в .env:

MAIL_DRIVER=log

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

[2017-09-12 08:23:06] local.DEBUG: Message-ID: <1e820046bbb4076f545196829aa701eb@laravel.portfolio>
Date: Tue, 12 Sep 2017 08:23:06 +0000
Subject: Your Subject
From: Sender <receiver@test.com>
To: Receiver <receiver@test.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Test  

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

А также, запись производится в файл логов Laravel /storage/logs/laravel.log, а не в логи сервера.

Выбираем оптимальный способ отправки email в Laravel

Ну, вот мы и рассмотрели все имеющиеся в Laravel драйвера отправки почты, использование каждого из которых позволяет производить email sending различными способами.

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

Итак, на повестке для у нас отправка email через почтовые сервисы по их API, через SMTP сервера, с помощью PHP mail() и sendmail. Запись в логи по понятным причинам способом отправки email мы не считаем, т.к. она при использовании драйвера log не производится. Однако, совсем игнорировать использование данного драйвера тоже не стоит, т.к. он представляет собой удобный инструмент дебага, и им рекомендуется пользоваться перед реальной отправкой почты, чтобы излишне не нагружать сервер и почтовые сервисы не заблокировали ваш сайт, как генератор спама.

Другое дело, что записи в логах позволят вам отследить сам факт оправки email и возникающих при этом ошибок, однако никак не помогут в коррекции вёрстки шаблона письма. Но, для этого в Laravel есть удобный инструмент предпросмотра письма в браузере, о котором мы с вами обязательно поговорим в дальнейшем.

Итак, какой же способ отправки писем в Laravel нам выбрать?

Отправка email в Laravel через почтовые сервисы с помощью API и через SMTP сервера — это, по сути, одно и то же, т.к. в обоих случаях письма будут отправляться не с сервера на котором расположен сайт, а со стороннего. Единственное различие в них — это порядок взаимодействия. В первом случае вы общаетесь с почтовым сервисом путём специальных API-методов, а во втором — посылаете запрос на сервер для отправки почты.

Таким образом, при использовании API список возможностей у вас может быть немного шире, чем при отправке email через SMTP. Но, по крайней мере, при стандартном использовании API Laravel для отправки писем и библиотеки SwiftMailer мы этих возможностей не ощутим.

Также, как утверждают некоторые разработчики, при отправке писем через SMTP сервер фиксируется IP адрес, с которого идёт обращение к серверу, что может быть нежелательно в отдельных случаях.

Ну, и при работе через API скорость взаимодействия может быть слегка выше, чем при использовании SMTP серверов. По крайнем мере, так утверждает Mailgun. А как оно на самом деле — честно говоря, не проверял :-) Так что если вы располагаете более точной и полной информацией по данному поводу, то прошу поделиться ей в комментариях.

По поводу использования PHP mail() и sendmail — эти подходы, как и предыдущие, довольно похожи. Их главным сходством является отправка писем на сервере, на котором расположен сайт. Остальные различия заключаются в субъективном удобстве настройки, потреблению серверных ресурсов и т.д.

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

Если вдруг я забыл о чём-то принципиально важном — просьба исправить меня в комментариях под статьёй.

Рассылка писем в Laravel на сервере приложения или через сторонний?

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

В первую попали использование почтовых сервисов через АПИ и их SMTP серверов, а во вторую — эксплуатация PHP mail() и sendmail. Внутри групп отличия между способами незначительны, а вот при сравнении групп в целом есть что сказать.

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

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

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

Если говорить о второй группе способов отправки писем в Laravel (использование API и SMTP серверов почтовых сервисов), то у них данный момент является самым главным преимуществом, т.к. письма отсылаются на сторонних серверах, т.е. расходуются их ресурсы, а не ваши. Зато вы будете постоянно упираться в ограничения, т.к. при использовании бесплатных тарифов количество email лимитировано и колеблется в пределах от 10000 в месяц для MailGun, заканчивая 60000 у Gmail и Amazon SES.

У некоторых почтовых сервисов, кстати, вообще нет бесплатных тарифов, как у SparkPost, к примеру. Естественно, вас будут уверять в других преимуществах использования почтовых сервисов, которые становятся доступными в премиум-аккаунтах… Не удивлюсь, если выяснится, что мифы о спамности PHP mail() выдуманы ими же 😉

Всё может быть… Нужно же им как-то существовать и конкурировать не только друг с другом, но и с бесплатными аналогами. Но я более не намерен продолжать данный разговор, т.к. ни первые, ни вторые за рекламу мне не платят :-)

Вернёмся к реальным и объективным особенностям. И тут хочется сказать, что даже если закрыть глаза на искусственные ограничения числа писем, отправка почты через сторонний сервис сама обладает рядом недостатков. К числу одним из самых главных хочется отнести большую продолжительность процедуры отправки email, в частности, через SMTP Gmail, которую я заметил на практике.

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

Прибавьте к этому ещё время ожидания очереди (вас же не одного обслуживают!) и самой обработки запроса. Думаю, понятно, к чему я веду :-)

Возможно, что при рассылке сообщений порциями время запроса к локальному серверу и удалённому будут примерно равны, но при отправке одиночных сообщений почтовые сервисы проигрывают PHP mail(), sendmail и другим локальным средствам рассылки писем.

Да, во время этого действа тратятся ресурсы сторонних серверов, но за этот плюс приходится расплачиваться временем.

Но, тем не менее, отправка писем через API и SMTP сервера почтовых сервисов всё равно очень популярна среди разработчиков и клиентов. Тем более, что большие порции писем (массовые рассылки) часто производятся в фоновом режиме, и при этом абсолютно всё равно, сколько времени они занимают. Зато на больших проектах, где ресурсы серверов экономятся до предела ввиду большого количества выполняемых задач, возможность вынести часть процессов на сторонний ресурс весьма привлекательна и обоснованна.

Поэтому, исходя из данных соображений, я при дальнейшей разработке буду использовать отправку почты в Laravel через сторонние почтовые сервисы. А точнее, через SMTP Gmail. Почему именно этот способ? Потому что у меня там уже есть учётная запись, настроенная для использования SMTP сервера, а на других почтовиках нет, и мне лень её создавать :-)

Это абсолютно не значит, что данный метод идеален (сами могли убедиться, сколько минусов у него удалось найти). Даже сам заголовок о выборе наиболее оптимального способа отправки почты в Laravel не совсем корректен, но нужно же было вас как-то заинтересовать прочитать весь материал :-) Тем более, что теперь вы познакомились с достоинствами и недостатками каждого подхода и сможете самостоятельно выбрать то, что вам больше по душе или подходит в конкретной ситуации.

На этом сегодняшняя статья с обзором способов отправки почты в Laravel подходит к концу. Надеюсь, вы теперь понимаете моё желание разделить теорию и практику реализации отправки email в Ларавель на разные публикации, т.к. одна статья обо всё этом была бы просто необъятной и вы бы половину её не читали бы… А так есть мизерный шанс, что вы дошли до этих строк :-) Если да — с вас лайк под статьёй.

Ну, а следующую публикацию я уже целенаправленно посвящу реализации отправки email через API Laravel, для чего воспользуюсь методами фасада Mail и подробно опишу его возможности. Остальные возможности API рассмотрим уже дальше, когда у нас будет готовый к работе сайт. Да и, возможно, не все этого и захотят…

На этом всё. Пишите ваши отзывы в комментариях и не забывайте вступать в социальные сообщества. Также принимаются ваши предложения по поводу новых статей о вещах, которые будут вам интересны.

До скорой встречи!

Laravel AJAX: создаём форму обратной связи

laravel-ajaxДоброго времени суток!

Сегодняшняя статья является продолжением цикла публикаций, посвящённых созданию сайта на Laravel, в рамках которого мы подробно рассмотрим процесс разработки корпоративного многостраничного сайта на базе шаблона с контактной формой и возможностью ведения блога.

Т.е. то, чем занимаются большинство веб-студий, требуя за свои услуги от 1000$. Если же вы наберётесь терпения изучить весь курс, то сэкономите означенную сумму и время на объяснение деталей сторонним исполнителям :-)

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

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

Сегодня же мы используем полученный опыт и приступим к созданию формы обратной связи, на примере которой я покажу вам, как реализовать популярную технологию AJAX в рамках Laravel framework.

Забегая наперёд, скажу, что саму отправку email через форму мы сегодня делать не будем, т.к. для обзора способов отправки email в Laravel запланирована отдельная публикация, а всего лишь подготовим всё необходимое для этого.

Итак, чем же мы сегодня конкретно займёмся?

Laravel AJAX форма — постановка задачи

Сказав, что сегодня мы будем делать обратную форму на Laravel, я немного слукавил, т.к. она у нас уже есть и доступна по url — laravel.portfolio/contact (я решил его немного поменять, поэтому в дальнейшем форма будет доступна по url laravel.portfolio/contacts).

Единственное, чего ей сейчас не хватает — это функциональности, т.е. непосредственно отправка письма не работает и при нажатии на кнопку «Отправить» фреймворк нам выдаёт ошибку.

Что же тогда мы будет творить, если самой отправкой письма заниматься будем в следующей статье?

Суть нашей сегодняшней работы будет заключаться в написании функции, которая будет вызываться при нажатии на кнопку «Отправить» и будет оправлять данные, введённые пользователем в поля формы, на сервер, а затем, при получении ответа с сервера будет выдавать уведомление об успешной или неуспешной отправке сообщения.

И ещё один нюанс — всё это будет происходить без перезагрузки страницы, т.е. с использованием технологии AJAX.

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

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

О них мы сейчас и поговорим.

Особенности реализации AJAX в Laravel

AJAX-запросы, по сути, ничем не отличаются от обычных HTTP-запросов к серверу, т.е. они могут отправляться теми же методами (GET, POST, PUT, DELETE и т.д.) с теми же самыми заголовками (HEADERS).

Исторически сложилось, что самыми популярными методами передачи запросов являются GET и POST. В GET-запросах параметры передаются через URL, а при POST они доступны только из суперглобальных массивов $_POST или $_REQUEST.

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

Исходя из этих соображений, при отправке email в Laravel с помощью AJAX мы будем пользоваться POST-запросом. И тут нас ждёт один неприятный сюрприз, т.к. по умолчанию все AJAX-запросы, отправляемые POST-методом, будут приводить к ошибке:

laravel-oshibka-proverki-csrf-tokena

Что за чушь? Что ещё за VerifyCsrfToken.php, если мы к данному файлу непосредственно не обращаемся?

Если у вас возникли подобные вопросы, то ответы ждут вас в статье о Laravel CSRF.

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

Реализация в Laravel AJAX контактной формы

Итак, нам нужно будет сделать следующее:

  • Подготовить HTML-форму для AJAX-отправки запроса
  • Реализовать JavaScript-код для отправки и обработки результатов запроса
  • Прописать правило роутинга Laravel
  • Метод контроллера Laravel для совершения действий на сервере (в будущем именно там у нас будет размещаться код отправки email)

Ну, что такое AJAX и в чём заключается его суть, я думаю, нет смысла описывать, т.к. технология уже лет 10 как не инновационная :-) Если вдруг вам нужны будут подробности — напишите об этом в комментариях.

Поехали :-)

AJAX контактная форма в Laravel — готовим HTML

Итак, что же конкретно мы будем делать?

На данный момент на сайте у нас уже есть контактная форма, которая отправляет POST-запрос на сервер скрипту contact.php. Загляните в файл с кодом контактной формы /resources/views/contact.blade.php, где это прописано:


<form id="contactform" action="contact/contact.php" method="post" class="validateform" name="send-contact">
...
</form>

Кстати, немного подумав, решил переименовать данный файл и соответствующую ссылку на страницу с контактной формой, так что в дальнейшем файл будет называться contacts.blade.php, чтобы было созвучно с новым url /contacts.

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

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

Поэтому очищаем тэг формы от ненужных атрибутов. И, чтобы избавится от валидации данных формы, встроенной в шаблон, очистим поля формы от ненужных атрибутов. Стандартной Bootstrap валидации нам вполне хватит.

Ну, и для добавления реализации Laravel CSRF protection и для исключения ошибки проверки CSRF token, о которой мы говорили ранее, в нашу форму следует добавить следующее:


{{ csrf_field() }}

Или воспользоваться другими вариантами указания токена, которые были перечислены в статье о Laravel CSRF по ссылке выше.

В итоге наша форма примет следующий вид:


<form id="contactform" method="POST" class="validateform">
    {{ csrf_field() }}

    <div id="sendmessage">
        Ваше сообщение отправлено!
    </div>
    <div id="senderror">
        При отправке сообщения произошла ошибка. Продублируйте его, пожалуйста, на почту администратора <span>{{ env('MAIL_ADMIN_EMAIL') }}</span>
    </div>
    <div class="row">
        <div class="col-lg-4 field">
            <input type="text" name="name" placeholder="* Введите ваше имя" required />
        </div>
        <div class="col-lg-4 field">
            <input type="email" name="email" placeholder="* Введите ваш email" required />
        </div>
        <div class="col-lg-4 field">
            <input type="text" name="subject" placeholder="* Введите тему сообщения" required />
        </div>
        <div class="col-lg-12 margintop10 field">
            <textarea rows="12" name="message" class="input-block-level" placeholder="* Ваше сообщение..." required></textarea>
            <p>
                <button class="btn btn-theme margintop10 pull-left" type="submit">Отправить</button>
                <span class="pull-right margintop20">* Заполните, пожалуйста, все обязательные поля!</span>
            </p>
        </div>
    </div>
</form>

Как видите, я ещё решил добавить блок с сообщением о неудачной отправке (такое тоже случается) с просьбой связаться с администратором по email напрямую. Email администратора я записал в файл окружения .env, который лежит в корне проекта, в следующем виде:

MAIL_ADMIN_EMAIL=admin@gmail.com

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

Ну, а для вывода переменных окружения в blade я воспользовался следующей конструкцией:

{{ env('MAIL_ADMIN_EMAIL') }}

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

Более подробно о ней вы можете прочитать здесь — https://laravel.com/docs/5.4/helpers#method-env. И вообще рекомендую распечатать данную статью документации Laravel и повесить себе на стеночку, т.к. Laravel helpers — вещь очень удобная и позволяет иногда сэкономить время на написании велосипедов.

Ну, и для визуального оформления сообщения об ошибке отправки письма с контактной формы я добавил стили для селектора #senderror в файлик /public/css/style.css следующим образом:

#sendmessage, #senderror {
	border:1px solid #e6e6e6;
	background:#f6f6f6;
	display:none;
	text-align:center;
	padding:15px 12px 15px 65px;
	margin:10px 0;
	font-weight:600;
	margin-bottom:30px;
}

#senderror {
    color: #f00;
}

#senderror span {
    font-weight: bold;
}

Только не нужно бездумно копипастить код. Первый блок свойств уже существует для селектора #sendmessage. Всё, что нужно, — это добавить эти свойства для #senderror, прописав его через запятую. Остальные два блока просто копируем.

Итак, на этом HTML часть контактной формы готова. Следующим этапом мы подготовим JS-код для передачи запроса и обработки его результатов без перезагрузки страницы.

Laravel AJAX контактная форма — JavaScript код

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

В проекте мы пользуемся JavaScript библиотекой jQuery (многие называют её JS-фреймворком, кому как угодно), поэтому и код AJAX запроса будет с использованием jQuery конструкций. Сам же код будет следующим:


$(document).ready(function(){
    $('#contactform').on('submit', function(e){
        e.preventDefault();

        $.ajax({
            type: 'POST',
            url: '/sendmail',
            data: $('#contactform').serialize(),
            success: function(result){
                console.log(result);
            }
        });
    });
});

Пару слов о том, что же здесь написано. Функция отправки AJAX запроса будет работать только когда страница загрузится, о чём говорит первая строка кода.

Запрос мы будем отправлять при событии submit HTML формы, т.е. при её подтверждении, что видно на второй строчке кода.

На третьей строке происходит прерывание стандартного подтверждения отправки формы. Если его не прервать, то вместо нашего кода Laravel пытался бы отправить запрос на action формы, которого нет, и мы получали бы ошибку о несуществующем URL.

На пятой строке можно увидеть вызов специальной функции jQuery ajax, которая делает отправку и обработку AJAX запросов невероятно удобной и простой, лишая разработчиков необходимости вникать в премудрости отправки и обработки результатов XMLHttpRequest из чистого JavaScript-кода.

Шестая, седьмая и восьмая строки говорят о том, что запрос будет отправляться методом POST на URL /sendmail и в теле запроса в качестве параметров будут передаваться данные, введённые пользователем в поля HTML формы.

Дальнейший код описывает действие, которое должно произойти при получении ответа от сервера. Пока что я решил прописать только вывод текста ответа в консоль браузера. В дальнейшем же, когда отправка email будет реализована, мы заменим данную «заглушку» на что-то более осмысленное.

В завершение описания данного этапа скажу, что код выше необходимо вставить в самый конец нашего кастомного JS-файла /public/js/app.js.  И неплохо будет почистить кэш браузера, иначе мы рискуем не увидеть результат выполнения.

Laravel AJAX — прописываем роуты

Итак, как вы могли заметить, в JS функции отправки AJAX запроса мы указали тип запроса и URL, на который он будет передан. Теперь самое время создать соответствующее правило Laravel routing для того, чтобы указать фреймворку как нужно обрабатывать данный запрос.

Для этого заходим в файл /routes/web.php и прописываем в его конце следующее правило:


Route::post('/sendmail', 'Ajax\ContactController@send');

Данный код говорит фреймворку, что при поступлении POST запроса на URL /sendmail следует вызвать метод контроллера Ajax\ContactController send().

Обработка Laravel AJAX запроса

Несмотря на то, что у нас уже есть контроллер ContactController, я решил для обработки AJAX запросов создать отдельный каталог с одноименным названием и заполнить его специальными одноимёнными контроллерами для обработки AJAX запросов на страницах сайта, т.к. считаю это архитектурное решение более правильным.

Если вы не разделяете мою точку зрения, можете создать метод send() в файле существующего контроллера /app/Http/Controllers/ContactController.php.

Я же воспользовался для создания нового контроллера уже знакомым алгоритмом.

Запускаем консоль и перемещаемся в каталог сайта:


cd c:/openserver/domains/laravel.portfolio

Выполняем artisan команду для создания нового контроллера:


php artisan make:controller Ajax/ContactController

После успешного выполнения должна была создаться папка /app/Http/Controllers/Ajax с файлом нового контроллера внутри ContactController.php.

Создаём в нём новый метод send(), который в качестве входного параметра будет принимать экземпляр класса Request, у которого в качестве свойств будут доступны тело, заголовок и параметры запроса, обрабатываемого данным методом.

Внутри данного метода в дальнейшем как раз и будет располагаться код отправки email сообщения. Пока же ограничимся «заглушкой», которая будет выводить на экран параметры запроса, которыми в нашем случае являются данные полей HTML формы.

В результате, контроллер Ajax/ContactController будет содержать следующий код:


<?php

namespace App\Http\Controllers\Ajax;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;

class ContactController extends Controller
{
    public function send(Request $request)
    {
        dd($request->all());
    }
}

Проверка выполнения Laravel AJAX запроса

Ну, вот и всё. Все необходимые приготовления выполнены. Осталось только проверить правильность работы нашей реализации Laravel AJAX.

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

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

Итак, вводим произвольные данные в нашу HTML форму и нажимаем на кнопку «Отправить». В консоли вы должны увидеть следующее:

laravel-ajax-otvet-v-konsoli

Если вы увидели данный набор символов — поздравляю, вы всё сделали верно :-) Не обращайте внимание на то, что AJAX ответ от сервера пришёл в таком неприглядном виде, главное — это положительный результат!

Увиденное — это результат выполнения отладочной функции Laravel dd(), которая на самом деле на выходе содержит много HTML кода, скрытого от глаза пользователя. При выводе же HTML кода в консоли браузера он не обрабатывается, и мы на экране видим «голый» HTML и JavaScript.

Если же хотите увидеть Laravel AJAX ответ сервера во всей красе, стоит лишь переместиться на вкладку инструментов разработчика «Network» и нажать на /sendmail, чтобы увидеть следующее:

laravel-ajax-otvet-html

Как видите, сервер вернул список значений всех полей HTML формы, а также вывел его в консоли, что и было прописано нами в коде.

А это значит, что Laravel успешно выполнил и обработал AJAX запрос, который был нами отправлен через форму обратной связи.

Теперь дело осталось за малым — в контроллере вместо «заглушки» прописать действия, которые будут производиться на сервере при обработке данного запроса, а в JavaScript скрипте прописать сценарии для фронтэнда сайта, выполняемые при успешном получении результатов обработки запроса.

Этим мы и займёмся в следующей статье, где рассмотрим способы отправки email в Laravel более детально. Поэтому подписывайтесь на обновления по ссылке в начале статьи, чтобы получить уведомление на почту о выходе нового материала.

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

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

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

Пока :-)

Laravel CSRF: обзор понятий и реализаций защиты

laravel-csrfЗдравствуйте, уважаемые посетители cccp-blog.com! Наконец, после трёхмесячного перерыва я снова возвращаюсь к творчеству и продолжаю цикл публикаций по созданию корпоративного сайта на Laravel.

Так что тех из вас, кто думал, что я позабыл про свои обещания довести сайт до конца, спешу «обрадовать» :-) А тем из вас, кто попал впервые на данных блог, рекомендую подписаться на обновления, чтобы увидеть, чем данный цикл в итоге всё-таки закончится.

Итак, в предыдущей статье я показал вам как создавать Laravel controllers и правила роутинга для указания обработчиков запросов, посылаемых на определённые url сайта.

Там же я пообещал в будущих статьях рассказать об особенностях реализации AJAX в Laravel на примере создания контактной формы.

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

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

Поехали :-)

Что такое CSRF

Те из вас, кто интересовался когда-то кибербезопасностью и безопасностью сайтов, в частности, наверняка знаком термин с аббревиатурой CSRF, которая расшифровывается как «Cross Site Request Forgery».

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

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

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

Самое интересное, что ничего они не узнают :-) Пользователи сами же дают согласие на произведение действий, угодных хакерам.

Как работает CSRF

Всем вам, наверное, неоднократно приходили на почту письма с содержанием вида «Смотри, какие милые котики» или «Не думал, что ты такое способен. Смотри, что я нашёл» и какими-то левыми ссылками с зашифрованными url и текстом, побуждающим по ним перейти.

При CSRF атаке после перехода по такой ссылке отправляется запрос на атакуемый ресурс — банка, блога или другой сайт с необходимыми параметрами, содержащие текст комментария, размер денежного перевода хакеру и т.д. И если вы будете залогинены на сайте, а атакуемый сайт будет хранить данные залогиненных пользователей в куках клиентских браузеров, то такой запрос будет с лёгкостью обработан.

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

Ну а что? Всё правильно. После обращения к администрации сайта люди там будут мягко говоря обескуражены. Действие от авторизованного в системе пользователя было, но он при этом утверждает, что ничего не делал. Мистика какая-то :-)

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

Запрос прошёл проверку авторизации пользователя на сайте? Прошёл.

Получатель платежа и сумма были указаны? Были.

Даже IP адрес, с которого был произведён запрос, будет ваш же, т.к. вы сами нажали на ссылку.

Как уберечься от CSRF

Отсюда мораль: как пользователь, ни в коем случае не переходите ни по каким сомнительным ссылкам, особенно из писем в папке «Спам». Ну, а как разработчик, вы должны учитывать возможность данных атак на пользователей создаваемых вами сайтов и всячески их предотвращать.

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

Во-вторых, важные действия (переводы денег, комментарии и т.д.) производить с помощью POST, PUT, DELETE, PATCH HTTP запросов, но никак не GET, HEAD, OPTIONS и TRACE. Так их сложнее будет подделать, т.к. отправить такой запрос с IP пользователя путём клика на ссылку не получится, адрес уже будет компьютера хакера, с которого он будет отправлять запрос, по которому его можно будет и вычислить (если он, конечно, не додумается его изменить или отправить запрос через прокси).

И, собственно говоря, вторая группа запросов предназначена для получения данных сайта, а не для изменения состояния сервера.

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

Защита от CSRF в Laravel

К счастью, Laravel соответствует всем указанным выше требованиям. Поэтому, выбрав его, вы можете быть уверены, что данные ваших пользователей будут в полной безопасности. Осталось только научиться пользоваться методами Laravel CSRF protection.

А они достаточно просты и заключаются в указании CSRF токена при отправке запроса, который сверяется на сервере перед его обработкой.

CSRF token в Laravel представляет собой строку из 40 случайных символов (судя по коду Laravel 5.4, которым я в данный момент располагаю), который генерируется при создании новой сессии приложения, т.е. при активности нового пользователя на сайте.

Таким образом, проверка CSRF токена перед обработкой запроса позволяет выяснить, что данный запрос был отправлен конкретным пользователем, а не кем-то вместо него.

Если вы отправите запрос, скажем, через HTML форму методом POST, PUT, DELETE или PATCH, то получите следующую ошибку проверки CSRF:

laravel-oshibka-proverki-csrf-tokena

Чтобы запрос отправился, необходимо в форму, с помощью которой отправляется запрос, добавить скрытое поле со значением CSRF token с помощью специальной функции-хэлпера csfr_field следующим образом:


<form method="post">
    {{ csrf_field() }}
    ...
</form>

Кстати, данный хэлпер появился сравнительно недавно — в Laravel 5.1. Так что, если вы используете более раннюю версию, то можете воспользоваться следующей конструкцией вместо предложенной:

<input type="hidden" name="_token" value="{!! csrf_token() !!}">

Также разработчики Laravel рекомендуют для дополнительной защиты AJAX запросов добавлять CSRF токен ко всем запросам на уровне JavaScript путём указания токена в значении метатэга, размещённого в секции head HTML-документа:

<meta name="csrf-token" content="{{ csrf_token() }}">

Считывание данного значения в JS производится следующей JQuery-конструкцией:

$.ajaxSetup({
    headers: {
        'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
    }
});

При отправке же GET запроса для успешной его обработки сервером CSRF token указывать не нужно. Но, как известно, данный тип запроса и так считается небезопасным благодаря указанию параметров в URL запроса, которые можно увидеть в браузере. Поэтому пользоваться им для передачи конфиденциальных и важных данных не то, что не рекомендуется, а запрещается :-)

Кстати, текущий CSRF токен указывается в качестве значения переменной COOKIE X-XSRF-TOKEN, которая присутствует в каждом ответе сервера. Поэтому иногда его будет удобнее использовать, особенно в ситуациях, когда значение CSRF токена необходимо получить в JavaScript, где хэлперы Laravel, как известно, не работают.

Обход CSRF защиты

Иногда возникают ситуации, когда запрос нужно не проверять на наличие в его параметрах CSRF токена. Особенно это актуально при работе с различными сервисами по API, т.к. ресурсы не будут знать, какой CSRF токен отправить при посылке ответа Laravel сайту.

За чтение CSRF token и его проверку перед выполнением запроса ответственны, как ни странно, Laravel middleware, а именно VerifyCsrfToken.php, который и генерирует исключение (exception) при попытке отправить POST запрос без указания токена.

Мы можем им воспользоваться в случаях, когда нам необходимо будет обойти CSRF защиту (совершайте это действие крайне осознанно!), указав необходимые url в потомке оригинального core-вского VerifyCsrfToken.php класса App\Http\Middleware\VerifyCsrfToken следующим образом:


<?php

namespace App\Http\Middleware;

use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as BaseVerifier;

class VerifyCsrfToken extends BaseVerifier
{
    /**
     * The URIs that should be excluded from CSRF verification.
     *
     * @var array
     */
    protected $except = [
        //url запросов, для которых не нужно проверять CSRF токен
    ];
}

Вот и всё, что нужно для исключения url от проверки на CSRF безопасность.
И на этом данная статья подходит к концу. В следующей я покажу вам, как реализовывать в Laravel AJAX запросы с применением сегодняшних знаний.

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

На этом всё. Пока :-)

Знакомимся с Laravel routing и controllers

laravel-routing-i-controllersВсем доброго времени суток!

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

На данный момент мы уже установили HTML-шаблон, откорректировали его для своих нужд и сделали «хлебные крошки» с помощью Laravel middleware.

Сегодня я познакомлю вас с Laravel routing, а также мы создадим Laravel controllers для страниц будущего сайта, в которых будет описана вся будущая вычислительная логика.

Не буду затягивать со вступительным словом. Начинаем :-)

Laravel routing — что, как, зачем?

Laravel routing — это механизм, позволяющий связывать url нашего приложения с какими-то конкретными действиями.

К примеру, у нас есть страница с url ‘http://site.com/contacts’. Как нам сообщить нашему сайту, что, когда в приложение поступает запрос по данному url, нужно выполнить какую-то функцию?

Если бы мы делали самописный движок сайта на чистом PHP, то мы бы написали в нашем index.php (поскольку данный файл распознаётся веб-серверами как точка входа) нечто следующее:

$url = $_SERVER['REQUEST_URI'];
if($url == '/contacts')
{
    //какое-то действие
    echo 'Это страница контактов';
}

else die('404');

Суть в том, что мы проверяем url, по которому поступил запрос в приложение, и при определённых значениях выполняем какие-то действия.

И так для каждого url, который должен быть обработан нашим веб-приложением, т.е. сайтом. Для всех остальных будет выдаваться 404 ошибка.

Какие тут минусы?

  • Во-первых, приведённый выше способ обработки применим только к простым url и абсолютно не учитывает параметры и тип запроса, а также много других факторов;
  • Во-вторых, для сложных url нужно будет ещё писать парсер, который будет разбивать адрес на сегменты;
  • В-третьих, вся эта красота будет лежать в index.php, внося разнообразие в его скучный и короткий код :-)

Ну, и самое главное, всё это придётся писать самостоятельно, т.е. «изобретать велосипед».

Но создатели Laravel избавили нас от такой необходимости, написав свой роутер (router, маршрутизатор), реализующий механизм роутинга (маршрутизации), который решает все приведённые выше недостатки. Кроме того, Laravel routing предоставляет следующие возможности:

  1. Именованные роуты (маршруты);
  2. Группы роутов;
  3. Маршруты для поддоменов;
  4. Передача данных в виде параметров роута;
  5. Фильтрация параметров с помощью регулярных выражений.

Как видите, возможностей у Laravel router весьма много. Также нужно сказать, что он очень прост и удобен в использовании, в чём мы с вами сейчас и убедимся.

Итак, как же пользоваться Laravel routing (кстати, как и множество англоязычных терминов его можно адаптировать к русскому языку в виде слова «роутинг»)?

Создаём Laravel routes

Для того, чтобы создать Laravel routes (правила маршрутизации) нам нужно будет работать с каталогом Laravel приложения под названием «routes» и, в частности, с файлом web.php, находящемся внутри.

Ещё до версии Laravel 5.3 файл с правилами роутинга был всего один и располагался в корне каталога «app». Но после создатели Laravel решили разделить роуты по назначению, создав для правил сайта, API и команд консоли отдельные файлы web, api и console соответственно.

Также для правил в файлах web и api в движок были добавлены базовые группы middleware, описанные в файле App/Http/Kernel.php, которые там можно и править при необходимости.

Многие фанаты Laravel, кстати, восприняли такие меры в штыки, посчитав их усложняющими жизнь.

Помню, когда я только осваивал Laravel и искал в сети подобные мануалы по созданию Laravel сайтов, натолкнулся на одного автора, который сознательно вёл разработку на Laravel 4, хотя текущая версия на тот момент была 5.3, вроде как. Свой выбор он аргументировал как раз-таки раздуванием фреймворка за счёт во многом лишних фич.

В какой-то степени я с ним согласен, т.к. тоже являюсь сторонником простых решений, но от прогресса прятаться бессмысленно и безполезно :-) Поэтому мы будем рассматривать фичи, доступные в современных версиях.

Кстати, с этой целью я решил обновить движок нашего будущего сайта, т.к., несмотря на то, что статьи по Laravel я начал публиковать сравнительно недавно на сайте, материал был написал ещё в октябре 2016 года, когда версия Laravel была 5.3. Теперь же она 5.4.23.

Если хотите обновить версию Laravel или какого-либо другого установленного через Composer пакета, прописанного в composer.json, просто зайдите в данный файл, лежащий в корне сайта, и пропишите интересующую вас версию или ветку в формате 5.4.*, например. После запустите в консоли команду composer update. Использовать системную консоль или консоль сервера — зависит от того, как вы устанавливали Composer.

Итак, приступаем к написанию наших роутов.

Забегая наперёд, скажу, что я не буду демонстрировать вам использование всех возможностей Laravel routes. Будем решать проблемы по мере их поступления 😉

Заходим в файл routes/web.php и смотрим, что у нас там есть:

Route::get('/', function () {
    $data = array('description' => 'Moderna - Главная страница', 
                  'title' => 'Moderna - Главная страница');
    return view('index', $data);
});

Route::get('/{page}', function ($page) {
    $data = array('description' => 'Moderna - ' . $page, 
                  'title' => 'Moderna - ' . $page);
    $data['breadcrumbs'] = Request::Get('breadcrumbs');
    
    return view($page, $data);
})->middleware('breadcrumbs');

У нас уже прописаны два правила роутинга: отдельно для главной страницы и для всех остальных, попутно применяя к ним middleware breadcrumbs, которые мы создали ранее. Я люблю универсальные решения, но в данном примере лучше будет создать отдельные правила роутинга для каждой страницы, чтобы назначить каждому url отдельное действие.

Это позволит нам вместо одного большого универсального метода, содержащего фрагменты кода, необходимого на отдельных страницах, разнести код по отдельным файлам. Одним словом, улучшить структуру, чтобы в случае внесения правок было понятно что и где искать. В будущем, возможно мы её изменим.

Итак, добавляем в файл routes/web.php Laravel routes для всех наших существующих страниц:

Route::get('/', 'MainController@index');
Route::get('/pricingbox', 'PriceController@index');
Route::get('/portfolio', 'PortfolioController@index');
Route::get('/blog', 'BlogController@index');
Route::get('/contact', 'ContactController@index');

Вот и всё. Получилось даже меньше строк кода, чем было раньше :-)

Давайте теперь разберёмся, что же я тут такое написал.

Route — это фасад Laravel, который нужен для работы с url. В данном случае, для его обработки.

get — это метод фасада, соответствующий методу, которым отправляется HTTP-запрос на данный url. Из доступных в Laravel имеются:

  • get;
  • post;
  • put;
  • patch;
  • delete;
  • options;

Также есть два метода фасада Route, позвляющие задавать одно действие для запросов, отправленных разными методами. Это match() и any(). Первый позволяет перечислять необходимые методы, а второй будет выполнять действие по url, не зависимо от того, каким методом был отправлен запрос.

Применяются они следующим образом:

Route::match(['get', 'post'], '/', function () {
    //действие
});

Route::any('/page', function () {
    //действие
});

Если вы, к примеру, отправляете HTTP-запрос на сервер методом POST, а правило обработки запроса на данный url будет описано для GET, то запрос не обработается.

Функция get() принимает два параметра:

  1. непосредственно url (лучше указывать со слэшом в начале, сообщая, что путь относительно корня сайта, иначе при создании админки придётся все url переписывать);
  2. действие, которое должно происходить после получения соответствующего запроса.

Действие может быть описано в разных форматах. Самый простой предполагает просто безымянную функцию, в теле которой будет прописано какое-либо действие. Пример данного подхода — наши старые Laravel маршруты, которые ещё находятся в файле web.php.

Также действие может быть прописано в таком формате, в каком я указал:

AboutController@index

Эта запись означает, что для обработки Laravel route будет вызываться определённый метод контроллера. Наименование контроллера — слева от символа «@», а метод — справа. В данном случае будет вызываться метод index() контроллера AboutController — всё просто :-)

Доведём файл routes/web до ума. Для этого нам нужно применить к нашим новым Laravel routes, отвечающим за страницы сайта (кроме главной) middleware для вывода хлебных крошек. Напомню, что можно сделать это двумя способами: применением его к каждому url в отдельности и к групповым применением ко всем роутам.

Первый способ мы использовали ранее с помощью конструкции:

Route::get('/{page}', function ($page) { ... })-&gt;middleware('breadcrumbs');

Можно было бы его снова применить к каждому роуту отдельно, но я предпочту массовое применение Laravel middleware:

Route::group(['middleware' => 'breadcrumbs'], function(){
    Route::get('/pricingbox', 'PriceController@index');
    Route::get('/portfolio', 'PortfolioController@index');
    Route::get('/blog', 'BlogController@index');
    Route::get('/contact', 'ContactController@index');
});

Предыдущие Laravel routes, которые у нас были в файле до этого, предлагаю пока что просто закомментировать, потому что в будущем, когда мы будем создавать контроллеры, данный код нам ещё пригодится.

Итак, файл с правилами Laravel маршрутизации у нас готов. Но, если мы сейчас попробуем перейти по url сайта в браузере, то увидим следующее:

laravel-routes-oshibka-vyzova-controllera

Эта ошибка вполне логична, т.к. ни контроллера, ни вызываемого метода у нас ещё нет.

Настало время исправить это:-)

Создаём Laravel controllers

Контроллер — это компонент паттерна программирования MVC, согласно которому код приложения разделяется на модели, контроллеры и представления.

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

Следовательно, в соответствующих контроллерах мы будем прописывать логику и выводить её в представления (Laravel views).

Файлы контроллеров Laravel хранятся в каталоге app/Http/Controllers. По умолчанию там расположен один-единственный базовый контроллер Controller.php, от которого будут наследоваться все остальные.

Для создания нового Laravel controller, как и в случае создания Laravel middleware, воспользуемся Laravel artisan. Для начала создадим контроллер, ответственный за вывод на экран кода главной страницы.

Запускаем консоль, переходим в папку проекта с помощью команды cd путь_к_проекту и запускаем следующую команду:

php artisan make:controller MainController

После успешного выполнения у нас в папке app/Http/Controllers появится новый файл MainController.php со следующим кодом:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class MainController extends Controller
{
    //
}

Всё просто и без излишеств — так и должен выглядеть пустой контроллер, внутри которого можно создавать всё, что угодно. Если посмотреть на файл Laravel роутов, то увидите, что я решил сделать однородную структуру контроллеров, т.к. в каждом из них для вывода HTML-кода в браузер будет вызываться метод index(), к созданию которого мы и приступаем.

Для этого создаём функцию index и переносим в её тело закомментированный код из app/routes/web:

public function index()
{
    $data = [
        'title' => 'Наша компания',
        'description' => 'Наша компания - самая лучшая в своём роде'
    ];
        
    return view('index', $data);
}

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

Создаём остальные контроллеры страниц приведённым выше способом. Единственное, чем они будут отличаться от MainController.php — это содержимое метода index(), которое будет взято из другого закомментированного универсального правила Laravel маршрутизации. К примеру, для страницы с url «portfolio» он будет выглядеть так:

public function index()
{
    $data = [
        'title' => 'Портфолио',
        'description' => 'Наши лучшие работы'
    ];
        
    $data['breadcrumbs'] = \Request::get('breadcrumbs');
        
    return view('portfolio', $data);
}

Тут, кстати, тоже нужно сделать небольшое уточнение по поводу слэша перед Request. Он необходим, когда вам нужно воспользоваться глобальным фасадом (классом) Laravel из числа описанных в файле config/app.php в массиве aliases, если использование фасада не описано прямо путём следующей директивы в начале файла php:

use Request;

Мораль сей басни такова: если код составлен верно, но Laravel выдаёт ошибку, что какой-то класс не найден, то проверьте, подключен ли он в файле или попробуйте перед его именем поставить слэш. Но этот способ работает не всегда, так что сильно на него на надейтесь и пропишите прямо.

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

В итоге, у нас должно появиться на одну рабочую страницу больше :-)

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

В завершение, удалите закомментированный код из app/routes.web.php.

Напоминаю, что все сегодняшние изменения вы сможете посмотреть в репозитории на Github в виде четвёртого коммита. Ну, и, ествественно, если у вас что-то не получилось и возникли какие-то трудности — пишите о них в комментариях, постараюсь всем помочь :-)

На этом у меня сегодня всё.

Laravel routes мы создали и перенесли код из файла роутинга в Laravel controllers. В следующей статье мы с вами будем создавать контактную форму и реализовывать отправку email на Laravel различными способами.

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

До новых встреч.

Laravel middleware: разрабатываем Laravel breadcrumbs

Laravel-middleware-znakomimsya-na-primere-laravel-breadcrumbsВсем привет! :-)

Мы продолжаем создание сайта на Laravel, и сегодняшняя статья будет посвящена знакомству с Laravel middleware.

Я не просто расскажу, что это за штука такая, но и приведу пример её использования, создав с помощью данной конструкции Laravel breabcrumbs («хлебные крошки» по-русски), в которых так нуждается наш сайт.

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

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

Поехали :-)

Знакомимся с Laravel middleware

Итак, что такое Laravel middleware?

По сути, данная конструкция служит для фильтрации HTTP-запросов, поступающих приложению. Middleware является промежуточным звеном (в переводе с англ. middleware — «промежуточный слой») между запросом к приложению и действием, которое должно происходить при приёме его фреймворком.

Таким образом, Laravel middleware можно использовать для проведения различных проверок подлинности url перед выполнением соответствующего действия, авторизации пользователей, ролей пользователей для совершения действий, в зависимости от результатов проверки.

Использование Laravel middleware для проверки авторизации пользователя я обязательно вам продемонстрирую в дальнейшем. Сегодня же я решил с помощью данного механизма реализовать хлебные крошки, которые будут основаны на распарсивании текущего url.

Честно говоря, для данной задачи middleware – не самое лучшее решение, т.к. передача итогового массива с «хлебными крошками» в представление (view) потребует от нас определённых танцев с бубном :-)

Более простым и аккуратным с точки зрения чистоты кода были бы способы реализации с помощью контроллеров и конструкции View::composer. Но, несмотря на это, я решил прибегнуть к middleware, как говорится, в академических целях, чтоб познакомить вас с этим функционалом, который появился в Laravel, кстати, совсем недавно – в 5 версии.

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

Ну что же, начинаем.

Создание и настройка Laravel middleware

Для начала нам необходимо создать сам файл middleware. Можно, конечно сделать его вручную на основе существующих образцов, которые идут в Laravel по умолчанию, но правильнее будет воспользоваться Laravel artisan.

Laravel artisan — это консоль Laravel, в которой можно манипулировать движком путём запуска специальных команд. С помощью Laravel artisan можно создавать контроллеры, модели, middleware, миграции, а также очищать кэш, совершать различные действия с БД и т.д.

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

Если вы не в первый раз читаете мой блог, то могли обратить внимание, что я работаю под Windows и являюсь сторонником WAMP-сборки OpenServer. Следовательно, в моём случае, запуск консоли на сервере будет происходить следующим образом:

openserver-zapusk-konsoli

Если же вы пользуетесь другой WAMP, LAMP, MAMP сборкой или XAMPP, то для запуска консоли в данном случае изучайте соответствующие официальные руководства. Ну, а если вы используете чистые Apache/Nginx + PHP + MySQL, установленные на вашей локальной или виртуальной машине/хостинге, то вам достаточно запустить системную консоль.

Допустим, у вас всё получилось.

Далее переходим в каталог вашего Laravel сайта с помощью команды консоли cd:

laravel-breadcrumbs-perehodim-v-katalog-sajta

Ну, и теперь мы можем пользоваться artisan. Для начала проверим, работает ли он у вас (ввиду различных причин artisan может не запуститься) и вводим команду


php artisan --version

Если всё в порядке, то вы увидите версию Laravel, на базе которой вы создали своё проект. Если нет, то первым делом проверьте список требований, необходимых для работы Laravel, а если с требованиями всё «ОК», а проблема существует, то пишите о ней в комментариях — постараюсь вам помочь.

Кстати, для просмотра всех команд, доступных в artisan, достаточно запустить следующую:


php artisan --list

В дальнейшем мы воспользуемся большей их частью, а сейчас же, для создания файла middleware, ограничимся следующей:


php artisan make:middleware

Для просмотра доступных параметров команды достаточно добавить в конце —help. У данной команды всего один аргумент — это имя Laravel middleware, которое в моём случае будет BreadCrumbs:

Sozdanie-laravel-middleware-cherez-artisan

Если у вас возникли какие-то проблемы на данном этапе (а это вполне возможно), также не стесняйтесь делиться ими в комментариях. В итоге, у нас автоматически создался файл app/Http/Middleware/BreadCrumbs.php со следующим базовым кодом:


<?php

namespace App\Http\Middleware;

use Closure;

class BreadCrumbs
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        return $next($request);
    }
}

Как видите, структура Laravel middleware крайне проста и представляет собой фунцию handle(), которая в качестве параметров принимает $request — массив с параметрами запроса для манипуляций с ними, и $next, который позволяет продолжить Laravel выполнение действия, соответствующего роуту запроса.

Для того, чтобы мы могли пользоваться нашим middleware в коде проекта, мы должны сообщить Laravel о его существовании. Для этого необходимо зарегистрировать его в файле app/Http/Kernel.php, дописав в самый конец массива $routeMiddleware следующий код:


protected $routeMiddleware = [
    //...
    'breadcrumbs' => \App\Http\Middleware\Breadcrumbs::class,
];

Также в данном файле app/Http/Kernel.php есть возможность создавать группы middleware для одновременного их применения. Для декларации такой группы необходимо добавить новый элемент в конец массива $middlewareGroups в следующем формате:


protected $middlewareGroups = [
    //...
    'group_name' => [
        \Illuminate\Routing\Middleware\CustomMiddleware::class,
    ],
];

Из коробки у Laravel уже есть, кстати, группы web и api, так что перед созданием своей группы проверьте, возможно, всё необходимое вам уже есть :-)

Всё, необходимые приготовления мы сделали. Теперь займёмся кодом самого Laravel middleware.

Созданию хлебных крошек на PHP я уже посвятил отдельную статью по приведённой ссылке. Поэтому всё, что нам нужно сделать, — это скопировать итоговый код оттуда и вставить в наш созданный Laravel middleware.

Принцип создания «хлебных крошек» там заключался в разбивке текущего url на сегменты (по слэшам) и сборке итоговой навигационной цепочки, заменяя название сегмента на подготовленное название.

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

В итоге, наш Laravel middleware должен принять следующий вид:


<?php

namespace App\Http\Middleware;

use Closure;

class BreadCrumbs
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure  $next
     * @return mixed
     */
    public function handle($request, Closure $next)
    {
        $url = $_SERVER['REQUEST_URI'];
        $urls = explode('/', $url);
        
        //Хлебные крошки
        $crumbs = array();

        //На главной не показываем
        if (!empty($urls) && $url != '/')
        {
            foreach ($urls as $key => $value)
            {
                //Собираем url для каждого пункта цепочки
                $prev_urls = array();
                for ($i = 0; $i <= $key; $i++)
                {
                    $prev_urls[] = $urls[$i];
                }

                //собираем url для всех, кроме текущей страницы
                if ($key == count($urls) - 1) $crumbs[$key]['url'] = '';
                elseif (!empty($prev_urls)) $crumbs[$key]['url'] = count($prev_urls) > 1 ? implode('/', $prev_urls) : '/';

                //Прописываем название пункта, исходя из url
                switch ($value)
                {
                    case 'portfolio' :
                        $crumbs[$key]['text'] = 'Портфолио';
                        break;
                    case 'pricingbox' :
                        $crumbs[$key]['text'] = 'Наши цены';
                        break;
                    case 'blog' :
                        $crumbs[$key]['text'] = 'Блог';
                        break;
                    case 'contact' :
                        $crumbs[$key]['text'] = 'Контакты';
                        break;
                    default :
                        $crumbs[$key]['text'] = 'Главная страница';
                        break;
                }
                
                if ($key > 0) $crumbs[$key]['text'] = $crumbs[$key]['text'];
            }
        }
        
        return $next($request);
    }
}

Поскольку я планирую постепенно, по мере наполнения контентом, переводить сайт на русский, то наименования в хлебных крошках я решил сделать на русском.

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

Так что пишите в комментариях, стоит ли мне этим заниматься или нет.

Использование Laravel middleware и breadcrumbs в коде

Итак, мы создали и зарегистрировали Laravel middleware, теперь самое время воспользоваться им :-)

Пользоваться ими можно тремя различными способами.

Способ 1: применение middleware к отдельным правилам роутинга Laravel

Прежде всего, Laravel позволяет применять middleware к отдельным правилам роутинга, описанным в файле routes/web.php (в версиях до Laravel 5.3 это app/Http/routes.php). Производится это с помощью следующей конструкции:


Route::get('route_name', function () {
    //...
})->middleware('middleware_name');

Способ 2: применение middleware к группам роутов

Данный способ позволяет применять один, несколько Laravel middleware или целые их группы сразу к нескольким правилам роутинга, оформленным в виде группы. Для этого необходима данная конструкция:


Route::group(['middleware' => ['middleware_name']], function () {
    //...
});

Указывая middleware для группы роутов, можно также указывать префикс для данных роутов и прочие параметры, которые можно найти в официальной документации.

Способ 3: использование middleware в контроллерах

О манипуляциях с контроллерами Laravel я ещё расскажу вам в дальнейшем, но о том, как использовать в них middleware, решил сейчас, раз уж затронул эту тему.

Итак, помимо роутов, middleware можно применять как ко всем методам контроллера, так и к определённым, указывая это в конструкторе контроллера, внутри «магического метода» __construct следующим образом:


public function __construct()
{
    $this->middleware('auth'); //применение Laravel middleware для всем методов контроллера
    $this->middleware('log')->only('index'); //применение только к методу index
    $this->middleware('subscribed')->except('store'); //применение middleware ко всем методам, кроме store
}

Из всех приведённых способов для хлебных крошек нам вполне будет достаточно первого, т.к. роут для всех страниц сайта у нас один (кроме главной, для которой нам Laravel breadcrumbs и не надо), следовательно, для него мы и будем применять наш middleware:


Route::get('/{page}', function ($page) {
    $data = array('description' => 'Moderna - ' . $page, 
                  'title' => 'Moderna - ' . $page);
    
    return view($page, $data);
    
})->middleware('breadcrumbs');

Хлебные крошки мы собрали в виде массива $crumbs. Возникает резонный вопрос: «Как же нам теперь передать их в представление (view), чтобы вывести на экран?». К сожалению, напрямую передать их из middleware не удастся, т.к. данная конструкция Laravel предназначена для обработки запросов.

Следовательно, передача «хлебных крошек» будет происходить посредством записи их в атрибуты запроса с помощью следующего кода:


$request->attributes->Add(['breadcrumbs' => $crumbs]);

Код прописываем в самом конце файла app/Http/Middleware/BreadCrumbs.php, перед функцией возврата итогового значения:


$request->attributes->Add(['breadcrumbs' => $crumbs]);
     
return $next($request);

Поскольку middleware является, по сути, фильтром запроса, который накладывается до или после его обработки (в нашем случае — до), то мы теперь можем извлечь наш массив с «хлебными крошками» из атрибутов запроса ещё до того, как он обработается и вернёт результат на экран.

Для этого возвращается в файл роутинга и в нашем правиле, к которому мы применяли middleware, вытаскиваем данные из запроса, записав их в виде подмассива «breadcrumbs» массива $data, который мы уже и так передаём в представление.

В итоге, наше правило роутинга для страниц сайта, кроме главной, примет следующий вид:


Route::get('/{page}', function ($page) {
    $data = array('description' => 'Moderna - ' . $page, 
                  'title' => 'Moderna - ' . $page);
    $data['breadcrumbs'] = Request::Get('breadcrumbs');
    
    return view($page, $data);
    
})->middleware('breadcrumbs');

В Laravel blade view, как не сложно догадаться, к «хлебным крошкам» можно будет получить доступ благодаря переменной $breadcrumbs.

Теперь, благодаря автоматическому формированию «хлебных крошек», мы наконец сможем придать их выводу на странице человеческий вид :-) Напомню, что сейчас у нас на каждой странице сайта определена секция «breadcrumbs» в виде:


@section('breadcrumbs')
    <ul class="breadcrumb">
        <li><a href="/"><i class="fa fa-home"></i></a><i class="icon-angle-right"></i></li>
        <li class="active">Pricing box</li>
    </ul>
@stop

Содержимое секций подставляется на место директивы blade шаблонизатора @yield в файле resources/views/layouts/breadcrumbs.blade.php:


<section id="inner-headline">
    <div class="container">
        <div class="row">
            <div class="col-lg-12">
                @yield('breadcrumbs')
            </div>
        </div>
    </div>
</section>

А сам шаблон «хлебных крошек» подключается в главном макете _layout.blade.php перед блоком контента:


<div id="wrapper">
    @include('layouts/header')
       
    @if(Request::path() != '/')
        @include('layouts/breadcrumbs')
    @endif
       
    @yield('content')

    @include('layouts/footer')
</div>

Поскольку у нас теперь в наличии массив с «хлебными крошками», который может быть доступен из любого шаблона, наиболее правильным решением будет:

  1. Организовать вывод содержимого в шаблоне breadcrumbs.blade.php;
  2. Его подключение в главном макете оставить;
  3. Секции на страницах сайта убрать вообще.

Этим мы и займёмся.

Вставляем в шаблон «хлебных крошек» код для вывода содержимого массива $breadcrumbs вместо директивы @yield. В итоге, breadcrumbs.blade.php будет выглядеть так:


<section id="inner-headline">
    <div class="container">
        <div class="row">
            <div class="col-lg-12">
                <ul class="breadcrumb">
                    @foreach($breadcrumbs as $item)
                        @if(!empty($item['url']))
                            <li>
                                <a href="{{$item['url']}}">{{$item['text']}}</a>
                            </li>
                        @else
                            <li class="active">{{$item['text']}}</li>
                        @endif
                    @endforeach
                </ul>
            </div>
        </div>
    </div>
</section>

Поскольку $breadcrumbs является массивом с названиями страниц и их url, то вывод «хлебных крошек» организовываем в цикле с помощью blade-директивы @foreach, в котором ещё раз проверяем (проверок много не бывает :-)) url текущего элемента на пустоту, и если он не пустой, то выводим его на экран, обернув в ссылку с url, который мы передали.

Если же url не указан – значит, проверяемый элемент соответствует текущей странице, поэтому его в ссылку не оборачиваем.

Итак, если вы всё сделали правильно, то можно открывать любую страницу сайта в браузере и любоваться плодами своих трудов :-) К примеру, блок «хлебных крошек» на странице «Портфолио» примет следующий вид:

laravel-breadcrumbs-hlebnye-kroshki-pokazyvayutsya-nepravilno

Хм… что-то тут явно не так. Почему-то элементы у нас одинакового цвета – и текущий и предыдущие, которые оформлены ссылками. При наведении на ссылочный элемент курсор меняется – значит, ссылка есть.

Для выделения сделаем его текст подчёркнутым, чтобы пользователи сайта не ломали голову над тем, как пользоваться такими «хлебными крошками».

Для этого открываем файл style.css и в блоке свойств для селектора #inner-headline ul.breadcrumb li a дописываем свойство text-decoration: underline. Если интересно, как я нашёл css-селектор требуемого элемента, то читайте об этом в статье «Меняем интерфейс сайта самостоятельно».

После данный манипуляций «крошки» станут более привлекательными:

laravel-breadcrumbs-finalnyj-variant

Вот, собственно говоря, и всё. Осталось только «размножить» наши обновлённые «хлебные крошки» для других страниц сайта, но это я рассматривать не буду, т.к. всё будет происходить по аналогии с вышеописанным примером.

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

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

Отдельной статьёй эти правки я решил не оформлять, но и не описать ход действий тоже не смог, чтобы у вас в дальнейшем не возникало вопросов «Почему у него всё работает, а у меня поломанное, хотя делал всё по статье?» :-) Меня самого сильно раздражают такие ситуации, когда всё делаешь по мануалам, а потом получаешь не тот результат, что у автора, потому что он не описал какую-то важную мелочь.

Я решил не уподобляться и привести весь порядок действий.

Итак, что же мне удалось обнаружить?

Фронтэнд доработки Laravel шаблона

В первую очередь, я обратил внимание, что в данной теме не работает подсветка активного пункта меню. Я решил исправить этот баг, используя код из статьи по ссылке выше.

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

Для этого, первым делом, нам нужно как-то найти пункты главного меню в JS-коде. Самый простой способ это сделать — добавить меню какой-то уникальный идентификатор.

Для этого идём в файл resources\views\layouts\header.blade.php нашего Laravel проекта, ищем там ul class=»nav navbar-nav» и добавляем ему какой-нибудь уникальный идентификатор. И ещё я решил прописать адреса ссылок в виде абсолютных url, воспользовавшись Laravel хэлпером url();

Также, попутно я решил перевести элементы меню на русский язык. В моём случае получилось следующее меню:


<ul class="nav navbar-nav" id="mainmenu">
    <li><a href="{{ url('/') }}">Главная</a></li>
    <li><a href="{{ url('/pricingbox') }}">Наши цены</a></li>
    <li><a href="{{ url('/portfolio') }}">Портфолио</a></li>
    <li><a href="{{ url('/blog') }}">Блог</a></li>
    <li><a href="{{ url('/contacts') }}">Контакты</a></li>
</ul>

Теперь нам нужен JavaScript-код для подсветки активного пункта. По своей старой привычке, я решил сделать файлик app.js, в котором обычно хранится JS-код сайта, да только в Laravel такой файл есть по умолчанию с минифицированными и скомпонованными Bootstrap и jQuery.

Поскольку данные компоненты идут вместе с шаблоном, я решил очистить стандартный файл app.js и хранить в нём свой пользовательский код, т.к. новые версии компонентов могут не сочетаться с кодом шаблона, поэтому лучше использовать те библиотеки, которые идут в комплекте с шаблоном.

Следовательно, в шаблоне resources/views/layouts/scripts.blade.php, в котором у нас содержится список скриптов, которые мы подключаем, добавляем следующую строчку:


<script src="{{ asset('js/app.js') }}"></script>

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

Файл public/css/app.css, который содержит минифицированный Bootstrap, я решил пока что вовсе удалить, т.к. в нём также нет надобности.

Итак, вставляем код из статьи о выделении активного пункта меню с помощью jQuery в файл app.js, поменяв id главного меню и имя класса активного элемента на наши значения.

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

Ну, и поскольку адреса ссылок в нашем меню — это абсолютные url, то пришлось написать функцию, формирующую их в JavaScript.

В итоге, получился следующий код:


//Функция, возвращающая абсолютный url
var getAbsoluteUrl = (function () {
    var a;
    return function (url) {
        if (!a) a = document.createElement('a');
        a.href = url;
        return a.href;
    };
})();
    
//Функция для подсветки активного пункта меню
$(function () {
    var location = window.location.href;
    var cur_url = getAbsoluteUrl(location.split('/').pop());
    
    $('#mainmenu li').each(function () {
        var link = $(this).find('a').attr('href');
        if(cur_url == link)
        {
            $(this).find('a').removeAttr('href');
            $(this).addClass('active');
        }
    });
    
});

После установки всё будет работать за исключением небольшого бага – при загрузке страницы у нас пункт меню “Home” подсвечивается голубым, а потом подсветка исчезает и выделяется текущий пункт меню.

Этот «прыгающий эффект» присутствует из-за того, что у главного пункта меню в шаблоне прописан класс «active», поэтому удаляем его. Теперь текущий пункт меню становится активным без всяких «прыжков».

Отлично, с этим моментом разобрались.

Из оставшихся багов были следующие, код которых я приводить не буду:

  1. Передвинул логотип в шапке на одну линию с меню, задав .navbar-brand margin-top: 42px вместо 30px;
  2. На странице блога убрал в сайдбаре тэги и категории (будем пока что делать без категорий, чтобы не усложнять жизнь) и вынес его в отдельный файл для удобного повторного использования (он также будет присутствовать на странице отдельного поста, которую ещё предстоит немного сверстать);
  3. Убрал из футера блоки с фотографиями и список страниц, т.к. все необходимые у нас и так будут в главном меню, а также социальные кнопки;
  4. По ходу инспектирования страниц прописал все url и пути к картинкам и прочим ресурсам с помощью хэлперов url() и asset();
  5. Также по ходу правок перевёл контент на русский;

Данные правки я не стал детально описывать, т.к. необходимость их внесения чисто моя субъективная, вы же в праве обойтись и без них. Ну, и чтобы не захламлять текст статьи лишним кодом, который вы и так можете посмотреть на GitHub :-)

Кстати, напоминаю, что код создаваемого нами Laravel сайта находится на GitHub, а сегодняшние правки вы можете найти на нём в виде второго и третьего коммитов.

В качестве критики сегодняшней статьи многие могут возразить, что в масштабах нашего веб-ресурса пользы от программных «хлебных крошек», которыми я решил заморочиться, вообще нет, т.к. они будут содержать одну-единственную ссылку на главную страницу — вполне можно было бы обойтись хардкодом (т.е. прописать на каждой странице вручную).

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

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

Поэтому подписывайтесь на обновлениями проекта, всё самое интересное вас ждёт впереди :-)

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

На этом сегодня я с вами прощаюсь, удачи вам в начинаниях и до новых встреч :-)

Laravel views: знакомимся с Laravel blade и натягиваем шаблон

Laravel-views-znakomimsya-s-laravel-blade-i-natyagivaem-shablonВсем привет!

Мы продолжаем создание сайта на Laravel 5. В предыдущих публикациях мы уже установили Laravel и настроили его запуск.

Сегодня наконец-то пришло долгожданное время писать код :-)

И я решил начать с фронтэнда, чтобы наш сайт уже начинал выглядеть презентабельно и его не стыдно было показать своим родственникам и друзьям :-)

Для этого нам понадобятся Laravel views и умение работы с шаблонизатором Laravel blade – собственной разработкой команды Laravel, а также знание его основных директив.

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

А для того, чтобы наш итоговый код был доступен широкой общественности, я решил создать для данного проекта публичный репозиторий на GitHub, ссылку на который вы сможете найти в конце статьи.

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

Выбор шаблона для Laravel framework

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

Шаблоны (templates) в их случае представляют собой набор HTML-документов и каталога (как правило, он носит название «assets») с различными JavaScript-библиотеками и картинками, которые используются в данном шаблоне.

Поэтому создать данный HTML-шаблон может без труда любой желающий и я хотел бы порекомендовать данное занятие всем, кто хочет себя попробовать в качестве фронтэнд-разработчика, т.к. чистые templates позволяют не вникать в структуру CMS.

И, кстати, благодаря таким особенностям структуры, уникальный дизайн для сайтов на Laravel и фреймворке в целом сделать намного проще, чем для CMS.

Однако, такая универсальность далеко не на руку нам, как разработчикам, которым предстоит данный шаблон «натянуть» или, другими словами, установить на сайт, базирующийся на фреймворке.

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

По поводу технических характеристик… Вот здесь я вас ничем не обрадую, потому что их попросту нет, в отличие от CMS, где нужно смотреть, чтобы шаблон подходил к определённой версии движка, использовал определённые технологии (VQmod/ocMod в случае OpenCart, например) и т.д.

При выборе шаблона Laravel, как и для других фреймворков главное требование к технологиям должно быть «Никаких технологий» :-)

Я имею ввиду, что в списке технических требований, необходимых для работы шаблона, не должно быть названия никаких движков (OpenCart, Magento и т.д.) и их версий. Как правило, шаблоны Laravel называются кратко и лаконично «HTML template» — наличие данной или похожей фразы в названии, пожалуй, и должно быть единственным условием выбора, остальные критерии будут чисто эстетическими «нравится/не нравится».

Ну, и лучше, конечно, выбирать для Laravel Bootstrap шаблоны (хотя, сегодня, наверное, уже все работают на базе данной технологии).

Кстати, поддержка последней официальной версии Twitter Bootstrap (альфа, бета версии не в счёт) идёт у Laravel из коробки, причём, уже в виде скомпонованных и минифицированных файлов (app.js и app.css).

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

Ну, а по поводу стоимости, то шаблоны для фреймворков ничем не отличаются от CMS: бывают как платные, так и бесплатные.

Ресурсы для скачивания всё те же:

  1. templatemonster.com
  2. market.envato.com и ресурсы, входящие в данный конгломерат:
    • themeforest.net
    • codecanyon.net и др.
  3. bootstraptaste.com

Отечественных глобальных бирж подобного масштаба, к сожалению, не встречал.

Я лично пользовался TemplateMonster и ThemeForest, но порекомендовать могу только первый из них (это видно из размещённой ссылки на ресурс) благодаря русскоязычному саппорту и удобным способам оплаты (включая WebMoney и Яндекс.Деньги).

На втором цены на шаблоны немного дешевле, но перечисленных преимуществ там нет. Кроме того, при оплате нас ждёт неприятный «сюрприз» в виде дополнительной комиссии при оплате с PayPal или MasterCard/VISA (других способов оплаты просто физически нет). При оплате с внутреннего счёта комиссия не взымается, но вы её всё равно заплатите при вводе денег на этот счёт :-)

В общем, как вы могли понять из всех вышеприведённой информации, уникальным шаблоном я решил не заморачиваться и взял готовый (и, естественно, бесплатный) c bootstraptaste.com с поэтическим названием Moderna, демо-версия которого доступна по адресу bootstraptaste.com/demo/Moderna.

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

Устанавливаем шаблон на Laravel

Итак, займёмся «прикручиванием» шаблона.

Для этого распакуйте скачанный вами архив с файлами шаблона и скопируйте все его каталоги с ресурсами (кроме «contact») в каталог public, подтверждая перезапись файлов в существующих каталогах js и css (файлы при условии чистого движка не будут пересекаться).

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

В моём примере сайт будет иметь url http://laravel.portfolio, следовательно, обращение к ресурсам будет происходить подобным образом: «http://laravel.portfolio/js/file.js».

Естественно, это при условии, что корень сайта был настроен в Laravel на директорию public.

Обращаться к файлам из данной директории мы будем с помощью функции-хэлпера Laravel asset(), которая формирует абсолютный url к ресурсу, переданному в качестве параметра.

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

Очень тонкая грань, согласен :-)

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

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

Сами шаблоны страниц (файл readme.txt копировать не нужно) переносим в директорию resources/views, предназначенную для представлений (view), которые в паттерне MVC служат для вывода информации, собранной в моделях и обработанной в контроллерах.

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

Главная страница сайта Laravel

Итак, начнём с лица сайта, его главной страницы.

Создавать мы её будем на базе документа index.html, входящего в комплект шаблона.

Первым делом, чтобы при открытии сайта мы видели содержимое данного документа, необходимо прибегнуть к Laravel роутингу и прописать соответствующее правило в файле routes/web.php.

Данный файл актуален для Laravel 5.3+ и содержит правила роутинга, т.е., описания действий, которые необходимо выполнять при переходе по соответствующему url необходимым методом (POST/GET и т.д.).

В предыдущих версиях Laravel данный файл можно найти по пути app/routes.php.

Итак, открываем требуемый файл и можно смело удалить всё его содержимое :-) По умолчанию он содержит один-единственный роут (правило) для главной страницы, отображающий содержимое view (представления) welcome.blade.php.

Данный файл нам больше не потребуется, т.к. он является заглушкой и не несёт никакой пользы от присутствия на сайте, поэтому его также можно удалить.

В итоге, файл роутов на данном этапе должен содержать одно-единственное правило для главной страницы (можете как отредактировать существующее, так и удалить всё содержимое и вставить код ниже), которое будет выглядеть так:

Route::get('/', function () {
    return view('index');
});

Данный код будет возвращать содержимое Laravel view index при обращении к корневому url сайта.

Чтобы проверить работоспособность наших действий, вводим в браузере следующий url: http://laravel.portfolio/.

И что же мы видим?

oshibka-pri-laravel-blade-view-v-html-formate

Не очень-то похоже на главную страницу шаблона, правда? :-)

При использовании Laravel view есть один нюанс: собственный шаблонизатор Laravel blade.

Следовательно, Laravel views могут содержать различные директивы шаблонизатора (в случае с blade они начинаются с символа «@»). Но, чтобы они стали доступными, файлы представлений должны иметь расширение *.blade.php.

Следовательно, чтобы мы могли вывести содержимое Laravel view на экран с помощью хэлпера view(), нужно поменять расширение файла index с html на blade.php.

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

primer-ustanovlennogo-laravel-shablona

Для остальных страниц Laravel шаблона можно поступить подобным образом, но давайте не будем спешить и усложнять себе жизнь.

Laravel blade содержит массу директив, которые призваны облегчить работу разработчикам. Одной из них является @extends, позволяющая страницам следовать какому-то определённому шаблону, т.е. использовать повторяющиеся куски кода (layouts или макет), не прописывая их в каждом документе заново.

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

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

В нашем шаблоне на всех страницах сайта есть одинаковые блоки вверху страницы (логотип и меню) и внизу (ссылки на социальные сети, копирайты и т.д.) – хэдер и футер.

Единственное, что на страницах различается – это зона контента, которая расположена между указанными блоками.

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

Для таких файлов создадим отдельный каталог в папке resources/views нашего проекта под названием «layouts».

Для формирования главного макета, содержащего условную схему страницы, создадим файл _layout.blade.php, в который перенесём код из index.blade.php.

В файле главной странице всё удаляем и вместо этого прописываем следующее:

@extends('layouts._layout')

Директивы шаблонизатора – это не функции PHP, поэтому не нужно ставить после них «;» или другие символы, иначе они будут присутствовать на скомпилированной странице в браузере.

В качестве параметров директива @extends принимает имя файла макета (без расширения blade.php), путь к которому нужно указывать относительно папки Laravel проекта resources/views.

При использовании @extends нам ещё понадобятся сопутствующие директивы @yield и @section, но о них мы поговорим немного позже.

Итак, из главного шаблона выносим повторяющиеся блоки в отдельные файлы.

В первую очередь, вынесем подключение стилей и скриптов.

Для файла стилей создаём макет styles.blade.php и выносим следующий код из тега <head>:

<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="author" content="http://bootstraptaste.com" />
<link href="css/bootstrap.min.css" rel="stylesheet" />
<link href="css/fancybox/jquery.fancybox.css" rel="stylesheet">
<link href="css/jcarousel.css" rel="stylesheet" />
<link href="css/flexslider.css" rel="stylesheet" />
<link href="css/style.css" rel="stylesheet" />
<link href="skins/default.css" rel="stylesheet" />

Из соображений SEO тэги <title> и <meta name=”description”> оставим в исходном шаблоне, чтобы для каждой страницы сайта значение этих элементов было уникальным.

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

Также пропишем пути к файлам с помощью хэлпера asset(), о котором я уже упоминал ранее.

Вызов в шаблонах blade Laravel хэлперов, переменных и прочих конструкций производится с помощью следующей конструкции:

{{ $peremennaya }}

Следовательно, а нашем случае, подключение файлов через asset будет выглядеть так:

<link href="{{ asset('css/bootstrap.min.css') }} " rel="stylesheet" />

Переподключите подобным образом остальные css-файлы самостоятельно.

По умолчанию, Blade экранирует HTML код в выводимых подобным образом элементах. Поэтому, если вы выводите текст, содержащий HTML-тэги, то они будут показаны как текст. Чтобы отключить экранирование и увидеть разметку, нужно написать:

{!! $peremennaya !!}

Если нужно будет вывести фигурные скобки вместе с выводом переменной, пропишите следующее:

{{!! $peremennaya !!}}

Кстати, если вы захотите что-то закомментировать внутри кода Laravel blade-документа, то в данном шаблонизаторе для этого есть специальная директива {{— comment —}}. Данный формат комментариев использовать даже предпочтительнее языковых комментариев JS, CSS, HTML и т.д., т.к. blade-комментарии не отображаются в итоговом коде HTML-страницы в браузере, как первые.

Итак, стили мы вынесли. Нужно теперь подключить файл с ними в файле макета, для чего в _layout.blade.php удаляем код, вынесенный в файл styles.blade.php, и вместо него прописываем:

@include('layouts.styles')

Данная директива @include служит для подключения blade Laravel views внутри себе подобных :-) При этом все переменные, присутствующие в родительском view становятся доступными и в подключаемом.

В качестве параметров, как и у @extends, принимается имя файла представления, а также, могут быть переданы дополнительные переменные в формате:

@include('layouts.styles', ['var1' => $var1, 'var2' => 'var2'])

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

Теперь аналогичным образом вынесем из главного макета подключение js-скриптов. Подключаются они правильно, в самом конце документа, что позволяет увеличить скорость загрузки страниц и благотворно влияет на поисковое ранжирование Google и прочими поисковыми системами.

Поэтому местоположение менять не будем, изменим лишь способ подключения.

Создаём scripts.blade.php с кодом:

<script src="{{ asset('js/jquery.js') }}"></script>
<script src="{{ asset('js/jquery.easing.1.3.js') }}"></script>
<script src="{{ asset('js/bootstrap.min.js') }}"></script>
<script src="{{ asset('js/jquery.fancybox.pack.js') }}"></script>
<script src="{{ asset('js/jquery.fancybox-media.js') }}"></script>
<script src="{{ asset('js/google-code-prettify/prettify.js') }}"></script>
<script src="{{ asset('js/portfolio/jquery.quicksand.js') }}"></script>
<script src="{{ asset('js/portfolio/setting.js') }}"></script>
<script src="{{ asset('js/jquery.flexslider.js') }}"></script>
<script src="{{ asset('js/animate.js') }}"></script>
<script src="{{ asset('js/custom.js') }}"></script>

И подключаем наш макет в файле _layout.blade.php вместо приведённого выше кода с помощью следующей строки:

@include('layouts/scripts')

Проверить правильность действий вам поможет переключение слайдов на верхнем баннере, нажатие на кнопку «Вверх» внизу страницы и сообщения в консоли браузера.

Итак, скрипты и стили мы вынесли. На очереди ещё два больших, повторяющихся фрагмента – хэдер и футер.

Начнём с хэдера. Для этого создаём файл в той же директории — resources/views/layouts с названием header.blade.php и перенесём в него из главного шаблона тэг <header> со всем его внутренним содержимым.

В главном макете _layout.blade.php подключаем вырезанный кусок знакомым способом:

@include('layouts/header')

То же самое проделываем и с футером, вырезая элемент <footer> со всем содержимым из главного шаблона. Вместо вырезанного кода вставляем аналогичный предыдущим примерам код:

@include('layouts/footer')

На этом перенос повторяющихся фрагментов страниц в отдельные файлы завершён.

Оставшийся большой HTML-блок является контентом, который для каждой страницы будет уникальным. Для того, чтобы зарезервировать место для него в главном макете, воспользуемся следующей директивой шаблонизатора Laravel blade:

@yield(‘content’)

Разместим данную строку сразу после подключения файла хэдера в главном шаблоне _layout.blade.php, а весь html-код, который находится в <div id=»wrapper»> после прописанной нами только что директивы, вырезаем.

Затем идём в resources/views/index.blade.php и прописываем следующую конструкцию:

@section(‘content’)

@stop

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

Давайте теперь разбираться, что же мы такое сделали :-)

В главном шаблоне _layouts.blade.php мы с помощью директивы @yield забронировали место для секции «content», содержимое которой мы должны будем прописывать в каждом файле страницы сайта внутри директивы @section с названием секции «content», которая закрывается директивой @stop.

В итоге, наш главный макет _layout.blade.php должен был принять следующий вид:

<!DOCTYPE html>
<html lang="en">
<head> 
    <title>Moderna - Bootstrap 3 flat corporate template</title>
    <meta name="description" content="" />
    
    @include('layouts.styles')

</head>
<body>
    
    <div id="wrapper">
        @include('layouts/header')

        @yield('content')

        @include('layouts/footer')
    </div>
    
    <a href="#" class="scrollup"><i class="fa fa-angle-up active"></i></a>
    @include('layouts/scripts')
    
</body>
</html>

Вроде бы всё симпатично получилось, однако, нет предела совершенству :-)

Лично мне не нравится один момент.

SEO-тэги <title> и <meta name=”description”> выносились в макет с благой целью – сделать их содержимое различным на разных страницах сайта, а сейчас они будет содержать постоянно один и тот же текст.

Чтобы разобраться с этой недоработкой, мы вместо статического текста организуем вывод с помощью переменных, значения которым будем задавать программно.

В итоге, шапка главного шаблона примет следующий вид:

<title>{{ $title }}</title>
<meta name="description" content="{{ $description }}" />

Эти переменные мы будем задавать в контроллерах соответствующих страниц при выводе информации на экран. Пока же, чтобы не оставлять их пустыми (да и избежать ошибок Laravel об использовании необъявленных переменных), зададим им значения в файле роутинга следующим образом:

Route::get('/', function () {
    return view('index')->with('description', 'Moderna - Главная страница')
                        ->with('title', 'Moderna - Главная страница');
});

Так будет выглядеть передача данных в шаблон Laravel при переходе на главную страницу сайта. Как видите, для передачи данных в Laravel используется метод with, который принимает в качестве аргументов имя передаваемой переменной и её значение. Для каждой переменной требуется отдельный вызов метода.

Если хотите передать все данные сразу в виде массива – нет ничего проще :-)

В Laravel данные в шаблон можно передавать и таким способом:

Route::get('/', function () {
    return view('index', ['description' => 'Moderna - Главная страница', 
                            'title' => 'Moderna - Главная страница']);
});

Также можно использовать ещё и такую вариацию последнего метода:

Route::get('/', function () {
    $data = array('description' => 'Moderna - Главная страница', 
                  'title' => 'Moderna - Главная страница');
    return view('index', $data);
});

Для других страниц пропишем следующее правило:

Route::get('/{page}', function ($page) {
    $data = array('description' => 'Moderna - ' . $page, 
                  'title' => 'Moderna - ' . $page);
    return view($page, $data);
});

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

В нашем примере переменная, содержащая имя страницы, просто будет передаваться в шаблон для формирования заголовка и описания страницы.

Ну, а как же проверить это правило, если у нас ещё нет ни одной страницы, кроме главной?

Страница портфолио Laravel проекта

Давайте, в качестве примера, разработаем Laravel blade документ для страницы «Portfolio». Для этого создаём в папке resources/views файл с названием portfolio.blade.php и копируем в него содержимое portfolio.html.

Удаляем повторяющийся код, который мы подключаем в главном макете _layout.blade.php, т.е. содержимое тэгов <head>, <header> и <footer>. Оставляем в файле шаблона только часть, расположенную между хэдером и футером, – область контента.

Оборачиваем её в используемые ранее тэги:

@section(‘content’)
   {{-- контент страницы --}}
@stop

И подключаем наш главный шаблон, прописав в самом начале файла, перед объявением секции контента, следующую конструкцию:

@extends(‘layouts/_layout’)

Итоговый код файла приводить не буду, т.к. он достаточно объёмный. Просто перейдите на страницу с портфолио в браузере, воспользовавшись элементами навигации сайта или введя прямой адрес http://laravel.portfolio/portfolio.

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

Laravel view с хлебными крошками

Повторный обзор кода страниц сайта помог мне выделить ещё один общий блок – это область под хэдером с «хлебными крошками».

Соответственно, также вынесем её в отдельный файл шаблона, который будем потом подключать.

Кстати, «хлебные крошки» в данном шаблоне организованы абсолютно неверно – на каждой странице прописаны вручную. В масштабах корпоративного сайта эта погрешность допустима, но на больших проектах такой способ будет крайне нерациональным.

Поэтому на данном этапе мы оставим всё, как есть, зарезервировав под список «крошек» секцию в макете, но в будущем сделаем формирование «хлебных крошек» автоматическим, о чём я напишу в отдельной статье.

А пока займёмся вынесением кода в отдельный шаблон. Для этого в resources/views/layouts создадим файл breadcrumbs.blade.php и перенесём  в него следующий блок кода из portfolio.blade.php:

<section id="inner-headline">
    <div class="container">
        <div class="row">
            <div class="col-lg-12">
                <ul class="breadcrumb">
                    <li><a href="#"><i class="fa fa-home"></i></a><i class="icon-angle-right"></i></li>
                    <li class="active">Portfolio</li>
                </ul>
            </div>
        </div>
    </div>
</section>

Содержимое тэга <ul class=»breadcrumb»> у нас будет различным на разных страницах, поэтому резервируем секцию с помощью кода:

@yield(‘breadcrumbs’)

Эту строку нужно вставить вместо списка «хлебных крошек»:

<ul class="breadcrumb">
   <li><a href="#"><i class="fa fa-home"></i></a><i class="icon-angle-right"></i></li>
   <li class="active">Portfolio</li>
</ul>

Список же со всем содержимым мы вырезаем и вставляем обратно в portfolio.blade.php, оформив код в виде секции breadcrumbs, которую мы вставляем после объявления секции content.

На данном этапе, в принципе, у нас нет острой необходимости делать «секцию в секции», можно было бы секцию breadcrumbs смело размещать перед content.

Но, заглядывая наперёд, когда «хлебные крошки» у нас будут формироваться программно и подключаться из единого файла, нынешний вариант удобнее, т.к. вместо кода секции мы просто вставим ссылку на требуемый файл, избежав перепрыгиваний по коду. Думаю, логика понятна.

В итоге, код страницы «Портфолио» будет иметь такой вид:

@extends('layouts._layout')
@section('content')
@section('breadcrumbs')
    <ul class="breadcrumb">
        <li><a href="#"><i class="fa fa-home"></i></a><i class="icon-angle-right"></i></li>
        <li class="active">Portfolio</li>
    </ul>
@stop
{{-- элементы контента --}}
@stop

Всё, что осталось, — это подключить шаблон «хлебных крошек» breadcrumbs.blade.php в нашем главном макете _layout.blade.php с помощью следующего кода, который необходимо вставить перед объявлением секции контента:

@include('layouts/breadcrumbs')

Теперь точно всё :-) Если вы всё сделали правильно – то на странице «Портфолио» ничего не должно было измениться.

Ах да, теперь у нас на главной странице появилась депрессивная чёрная полоса под хэдером, т.к. мы прописали подключение шаблона «хлебных крошек» в главном макете, на базе которого формируются все страницы.

Чтобы избавиться от этого маленького бага, сделаем подключение шаблона «хлебных крошек» для всех страниц, кроме главной, обернув строку подключения файла breadcrumbs.blade.php в _layout.blade.php следующим условием с помощью директивы @if:

@if(Request::path() != '/')
   @include('layouts/breadcrumbs')
@endif

Как видите, условие заключается в проверке части urlа текущей страницы, которая следует за названием сайта. Получить её нам помогает метод path() класса Request, к которому мы обращаемся и проверяем значение, которое он вернул.

После чего строка на главной странице исчезнет, а на остальных страницах блок хлебных крошек останется на своём месте.

Оформление остальных страниц Laravel шаблона

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

Всё, что вам потребуется – это создать файл с расширением .blade.php, назвав его так же, как и оригинальный файл шаблона, указать родительский макет с помощью @extends, описать секцию контента и вставить в ней всё, что находится между хэдером и футером в исходном файле.

Кстати, не забудьте после создания страниц поменять ссылки в главном меню сайта, которое расположено у нас в файле resources/views/layouts/header.blade.php, убрав из названий приставку «.html», а то страницы будут недоступны через элементы навигации, только по прямым ссылкам.

Также пройдитесь поиском по проекту в вашем редакторе кода и исправьте ссылки на главную страницу типа <a href=”index.html”>, прописав в качестве url «/».

Выполняя аналогичную финальную проверку файлов перед заливкой в репозиторий, я обнаружил ещё один небольшой баг шаблона. Не смотря на то, что страницы «Features» у нас нет – есть только пункт главного меню – в «хлебных крошках» есть соответствующий элемент на страницах «Components», “Typography” и “PricingBox”.

Это не правильно ни с точки SEO, ни с точки здравой логики, которая подсказывает, что элементы в «хлебных крошках» должны содержать ссылки, которую в данной ситуации невозможно поставить на несуществующую страницу.

Поэтому на всех вышеупомянутых страницах в секции breadcrumbs удалите элемент с текстом «Features» — он там ни к чему.

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

Также не забудьте удалить исходные файлы шаблона с расширением .html – они нам больше не понадобятся.

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

А код страниц вы можете посмотреть в репозитории данного проекта на GitHub, которые оформлены в виде первого коммита.

Вы, конечно, можете просто скопировать их к себе в проект, но не рекомендую это делать, т.к. написание кода своими руками будет в 100 раз полезнее, в первую очередь, для вас самих.

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

Если вы будете копировать мой GitHub репозиторий к себе на компьютер через Git целиком, то не забудьте после этой процедуры перейти в консоли в папку проекта и запустить следующую команду:


composer update --no-scripts

Это необходимо для установки файлов фреймворка (в частности, директории vendor, которой нет в Laravel репозиториях), причём тех их версий, которые прописаны в вашем файле composer.json. Этот момент, кстати, очень важен, т.к. при нестыковке версий движка и их зависимостей сайт работать будет некорректно.

На этом сегодня я с вами прощаюсь, успехов вам в выполнении задания. Если по ходу изложения сегодняшнего материала у вас возникли какие-то трудности и вопросы – не стесняйтесь делиться ими  в комментариях под статьёй. Буду рад любому вашему мнению.

Следите за обновлениями. Будет интересно :-)

Laravel настройка и запуск под Apache, Nginx, OpenServer

laravel-nastrojkaВсем хэллоу :-)

Мы продолжаем цикл публикаций, посвящённых самостоятельному созданию сайтов на Laravel 5. В предыдущих статьях из данной серии я рассказал вам, что такое Laravel и какими способами его можно установить на хостинг или локальный веб-сервер.

Сегодня же мы поговорим о том, как настроить Laravel для запуска реальных проектов на его базе.

Не понимаете, о какой настройке идёт речь? Тогда просто попробуйте запустить Laravel в браузере после его установки — думаю, что все вопросы отпадут сами собой :-)

А о том, как исправить данную ситуацию — читайте далее.

В чём будет заключаться настройка Laravel

Ну, вот мы и произвели установку Laravel. Теперь, казалось бы, остаётся радоваться жизни и начинать работу над реальными проектами… Но, не тут-то было :-)

Файловая структура Laravel обладает одной раздражительной для новичков особенностью – файл index.php, который распознаётся web-серверами как точка входа на сайт, расположен не в корне проекта, а в папке «public».

Поэтому после установки Laravel на ваш веб-сервер и ввода в браузере доменного имени сайта вместо ожидаемой стартовой страницы вы увидите только список файлов.

laravel-public-problemy-pri-zapuske

Сайт, конечно, можно запустить, если вбить URL сайта в формате «http://localhost/laravel.corp/public», но вы только посмотрите на этот адрес… Сколько букв, а это всего лишь адрес корня сайта :-)

Работать с такой простынёй в будущем будет крайне неудобно и ни о каком ЧПУ даже и думать не приходится.

Для того, чтобы сообщить серверу, что точка входа находится не в корне сайта, а в его директории public, нам необходимо либо изменить настройки самого сервера, либо, если вы используете Web-сервер Apache, отредактировать файл .htaccess.

А ещё, помимо чистых веб-серверов существуют различные сборки ПО для комфортной работы веб разработчиков. Они называются LAMP, WAMP, MAMP, XAMP.

Первая буква данных аббревиатур означает ОС, на которой сборка будет работать (Linux, Windows, MacOS, X- любая). А последние три — это заглавные буквы основных программ для создания сайтов, входящих в дистрибутив (Apache, MySQL, PHP).

Про себя могу сказать, что я фанат таких решений и пользуюсь ими практически с самого начала своей профессиональной карьеры веб-разработчика.

И, хотя, сегодня активно применяются и другие средства для быстрого старта веб проектов — виртуализаторы и виртуальные среды разработки, о которых я упоминал в предыдущей статье об установке Laravel, я всё так же являюсь сторонником использования *AMP сборок.

Сам я веду разработку под ОС Windows и пользуюсь WAMP-сборкой OpenServer, о чём уже неоднократно говорил в статьях на данном блоге.

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

Ну, а поскольку я начал рассказывать об OpenServer, то и настройку Laravel для полноценного запуска проектов начну на его примере.

Установка Laravel на OpenServer

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

Для всего этого в OpenServer есть уже всё необходимое. Нужно только знать, где и что клацать :-)

Итак, после установки OpenServer и его запуска нам нужно настроить Laravel для запуска проекта по прямому запросу к его доменному имени, а не к папке public.

Перед этим действием предполагается, что Laravel вы уже установили и разместили его файлы в папке domains на OpenServer, которая предназначена как раз для будущих сайтов, запускаемых с помощью сервера. В моём примере Laravel находится по пути «C:\openserver\domains\localhost\laravel.corp».

Запустить в браузере я его сейчас могу только послав запрос на URL «http://localhost/laravel.corp/public», что крайне неудобно. Итак, чтобы избавиться от этой неприятности, первым делом нам нужно зайти в настройки OpenServer, что можно сделать следующим образом:

laravel-openserver-nastrojki

В открывшемся окне переходим на вкладку «Домены» и в списке «Управление доменами» выбираем пункт «Ручное управление» или «Ручное + Автопоиск», чтобы можно было задавать своим проектам произвольные доменные имена.

В качестве примера я использовал первый вариант, но всё же рекомендую последний, т.к. он позволяет как добавлять произвольные доменные имена, так и запускать проекты из папки «openserver/domains», обращаясь к ним по их названиям каталогов.

При ручном управлении вы сможете запускать только те сайты, доменные имена которых будут прописаны на сервере со ссылками на соответствующие папки:

laravel-openserver-nastrojka-domena

Итак, для добавления нового домена пропишите его имя в поле «Имя домена», а в поле «Папка домена» выберите каталог с файлами сайта. После этого не забудьте нажать кнопку «Добавить», а потом «Сохранить», после чего сервер перезапустится.

Кстати! При данном варианте добавления новых сайтов на сервер файлы ресурса могут быть расположены в любом месте, не обязательно в «openserver/domains».

Если вы всё сделали правильно, то при вводе в браузере доменного имени (laravel.portfolio в моём случае), которое вы добавили, вы увидите стандартную страницу приветствия Laravel:

laravel-openserver-rabochij-sajt

Поздравляю, на этом установка Laravel на OpenServer подошла к концу. Сайт заработал, причём теперь исчезла необходимость обращаться к папке public!

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

Для этого просто скопируйте каталог с проектом или сделайте его архив в отдельном месте, кратко описав текущий функционал и дату создания.

Также не лишним будет сделать Git репозиторий для хранения списка изменений и быстрого их восстановления в будущем.

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

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

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

Но, это не беда. Стоит только начать… И, со временем, занимаясь разработкой сайтов на framework, у вас под рукой уже будет собственная мини-CMS благодаря готовым фрагментам кода и отдельным модулям.

А мы с вами начнём заниматься непосредственно разработкой уже в следующей статье, где я покажу вам, как «натянуть» чистый HTML-шаблон на фреймворк, на базе которого мы в дальнейшем создадим полнофункциональный сайт-визитку с админкой и возможностью ведения блога.

Поэтому подписывайтесь на обновления проекта, чтобы не пропустить самое интересное :-)

Итак, для фанатов Windows и OpenServer мы Laravel настроили. А как же быть тем, кто пользуется Linux-дистрибутивами или MacOS, на которых OpenServer не работает?

Когда-то передо мной стояла подобная задача — настроить Laravel на Ubuntu сервере.

На stackoverflow.com каких только способов я не находил… вплоть до изменения файловой структуры самого Laravel проекта (способ хоть и рабочий, но не рекомендую им пользоваться, чтобы у других разработчиков при виде «сего творения» не вставали дыбом волосы) :-)

Как же быть?

Достойным внимания является настройка виртуальных хостов, корнем которых будет являться папка public вашего Laravel проекта (по сути, это мы и сделали при запуске Laravel на OpenServer). Но, этот вариант подойдёт только для локального использования и на выделенных серверах.

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

Рассмотрим данные операции для различных веб-серверов.

Настройка Laravel проекта на различных веб-серверах

Поскольку самыми распространёнными программными веб серверами на сегодня являются Nginx и Apache, то рассмотрю данный процесс для них.

Настройка Laravel для Apache

Для Apache настройка Laravel может быть произведена двумя способами, каждый из которых мы подробно рассмотрим:

Способ 1.

Он будет заключаться в настройке Laravel в виде виртуального хоста. Лучше всего для этого воспользоваться консольным режимом (по крайней мере, так поступаю лично я) и будет выглядеть следующим образом:

1. Переходим в папку виртуальных хостов Apache: apache2/sitesavailable

2. Если вы ещё не создавали виртуальные хосты, то в данной папке у вас будет всего лишь один файл default. Откройте его для редактирования либо скопируйте и переименуйте его в название вашего будущего сайта. Например, laravelsite.local.

3. Внутри файла прописываем следующие настройки:

<VirtualHost *:80>
    
    ServerName laravelsite.local
    DocumentRoot "path_to_site/myapp/public"
        
    <Directory "path_to_site/myapp/public">
        AllowOverride all
    </Directory>
        
</VirtualHost>

4. Если вы создавали новый файл в sites-available, то для активации виртуального хоста нужно будет сделать ссылку на файл из apache2/sitesavailable в apache2/sites-enabled (в Unix-подобных системах это производится с помощью команды ln). Если вы редактировали существующий файл default, то данные действия будут лишними.

5. Перезапускаем Apache.

Вот и всё, после запуска Apache сайт будет доступен по адресу http://laravelsite.local/. Если что-то пойдёт не так, то ищите текст ошибки в логах Apache.

Способ 2.

Благо, что Apache предоставляет ещё один, более простой способ настройки корня Laravel сайта на директорию public с помощью директив в файле .htaccess, размещённом в корне проекта. Я сам активно пользуюсь данным способом при разворачивании Laravel сайтов на shared хостингах, т.к. он максимально прост и быстр — достаточно однажды подготовить соответствующий файл — и вперёд :-)

Код его должен быть следующим:

DirectoryIndex /public/index.php
RewriteEngine On

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.+) $1 [L]

RewriteCond %{DOCUMENT_ROOT}/public%{REQUEST_URI} -f
RewriteRule ^(.+) /public/$1 [L]

Options +SymLinksIfOwnerMatch
RewriteRule ^(.*)$ /public/ [QSA,L]

Этот нужно разместить в папке с Laravel в .htaccess, который находится в корне самого проекта. Тот .htaccess, который лежит в директории public, трогать не нужно!

Всё, с настройкой Laravel для Apache мы разобрались. Теперь самое время сделать то же самое для Nginx, который также достаточно активно применяется для запуска веб-проектов ввиду своей фантастической скорости работы.

Настройка Laravel проекта на Nginx сервере

Итак, для настройки Laravel для Nginx, к сожалению, нет такого изобилия различных способов, как для Apache. По крайней мере, я знаю только один в виде настроек Laravel проекта в виде виртуального хоста.

Если вы знаете больше, то не отмалчивайтесь и поделитесь ими в комментариях со мной и всеми остальными :-)

В случае с Nginx для настройки виртуальных хостов нужно произвести действия, аналогичные в случае с Apache:

1. Переходим в папку виртуальных хостов Nginx: nginx/sitesavailable.

2. Сделать файл нового виртуального хоста или отредактировать существующий default.

3. Внутри файла прописываем следующие настройки:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only = on;
    root path_to_app/myapp/public;
    index index.php index.html index.htm;

    server_name server_domain_or_IP;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        try_files $uri /index.php = 404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Учтите, что последний блок кода — это настройки PHP для запуска сайта: путь к интерпретатору, модули, расширения файлов и т.д. Если с данными настройками сайт не заработает, то отредактируйте их в соответствии со своей конфигурацией сервера. Подробный текст ошибок ищите в логах Nginx.

4. Если создавали новый виртуальный хост, то активируем его созданием ссылки на файл с настройками из папки sites-available в sites-enabled. Если новый хост вы не создавали, а редактировали существующий, то данный шаг пропускаем.

5. Перезапускаем Nginx.

Итак, после данных действий, при вводе в веб браузере адреса сайта (в моём примере он будет http://laravelsite.local/) вы увидите не список файлов, как прежде, а ожидаемую страницу приветствия Laravel.

Если этого не произошло, то ищите ответы на вопросе в логах вашего веб-сервера (Nginx или Apache, соответственно). Скорее всего, они будут вызваны неверными правами на различные папки (как проекта в целом, так и на отдельные внутренние каталоги). В таком случае всё, что вам потребуется, это установить их в 755 или 644 :-)

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

Настройка локалей и соединений с БД в Laravel

Теперь можно приступить непосредственно к разработке.

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

Поскольку в дальнейшем я планирую продемонстрировать создание сайта-визитки с возможностью ведения блога, то нам необходимо будет создать базу данный сайта (БД) для хранения в ней текста и названия постов блога.

При написании статей на данном блоге я неоднократно описывал процесс создания БД через программу phpMyAdmin, предоставляющую веб-интерфейс для работы с базами, имеющимися на сервере.

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

Также можете использовать другие интерфейсы, вплоть до консольного варианта. Тут уж кому что нравится…

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

Настройки различных компонентов, входящих в состав фреймворка, хранятся в отдельных файлах, расположенных внутри каталога config, который после установки чистого дистрибутива Laravel выглядит так:

nastrojka-laravel-configuratsionnye-fajly

Здесь, как вы видите, содержатся конфиги для различных вещей: сессий, кэширования, файловой системы, авторизации и т.д. Помимо всего прочего, здесь присутствует и конфиг с настройками, необходимыми для взаимодействия с БД.

Кстати! Настройки устанавливаемых сторонних расширений (пакетов) вы сможете найти в этом же каталоге после их установки и публикации конфигов. Правда, не всегда. Некоторые разработчики предпочитают хранить их вместе с остальными файлами пакета в папке vendor.

Я не буду его здесь приводить полностью, т.к. вы всегда можете сами его открыть и посмотреть. И описывать, за что отвечает каждая отдельная опция, тоже смысла не вижу, т.к. каждая из них отлично продокументирована создателями Laravel.

Единственное, на что я хочу обратить ваше внимание, так это на постоянное использование внутри конфигов функции env():

'default' => env('DB_CONNECTION', 'mysql'),

Вот по этому поводу хотелось бы внести некоторые комментарии.

Функция env() в Laravel является переработанным вариантом getenv(), являющейся частью PHP библиотеки DotEnv от Vance Lucas, которая используется в составе Laravel.

Данная библиотека позволяет создавать файл с перечнем переменных рабочего окружения — .env в корне проекта, переменные из которых становятся глобально доступными благодаря функции getenv (env для Laravel) и из суперглобальных массивов $_ENV и $_SERVER.

Причём, как вы видите в примере выше, данная функция принимает два параметра:

  1. Имя переменной окружения;
  2. Значение, которое будет использоваться, если переменная не будет найдена.

Возникает вопрос: «Что за окружение такое?». Имеется ввиду набор настроек проекта, актуальные для отдельных разработчиков, т.е. хранящиеся на его рабочем компьютере.

Это и соединения с БД и, возможно, даже отдельные драйверы кэширования, хранения сессий и т.д., которые разработчик прописывает у себя, поднимая локальную копию проекта.

Естественно, что имя локальной БД, к примеру, может (а скорее всего, так и будет) не совпадать с основной.

Так вот, чтобы не менять каждый раз значения глобальных переменных после заливки файлов в общий репозиторий или на сервер, эти переменные хранятся в специальном файле локального окружения, который автоматически добавляется в .gitignore и недоступен к просмотру в некоторых файловых системах и программах (к примеру, в SSH клиенте WinSCP при базовых настройках его не видно).

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

К чему я всё это? Да к тому, что лучше нам свои настройки хранить в файле .env. Пока вы работаете одни над проектом, для вас, естественно, нет никакой разницы — в .env ли будут храниться настройки или в специализированных конфигах.

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

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

Итак, открываем файл .env и ищем следующий блок переменных, отвечающий за настройки соединения с базой данных:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

Кстати! Если вы устанавливали Laravel не через Composer, а, например, вручную, путём скачивания с GitHub, то файла .env у вас не будет. Вместо него вы найдёте файл .env.example, который нужно будет скопировать и переименовать в .env вручную.

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

В моём случае я назвал БД laravel_corp. Пользователь БД у меня стандартный — root, пароль пустой. СУБД использую MySQL и сервер у меня расположен на локальном ПК.

Следовательно, мой конфиг принял такой вид:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel_corp
DB_USERNAME=root
DB_PASSWORD=

Думаю, что по моему примеру вам несложно будет ввести свои настройки.

Ещё одна вещь, которую вам может понадобиться изменить в дефолтных настройках Laravel — это настройка локали и времени. Где это может пригодиться?

Локаль — это язык по умолчанию. Следовательно, если у вас сайт будет мультиязычный, то контент на данном языке будет по умолчнию.

А настройка времени (часового пояса) нам нужна для корректного хранения данных, касающихся времени (создание записи в БД, её обновление и т.д.). Лично мне некорректное значение данного параметра очень сильно подпортило нервы однажды, когда я не мог никак понять, почему у сообщения в чате, которое я только что отправил, время создания указывалось на час меньше. А виной всему был один-единственный параметр :-)

Поэтому советую вам сразу расставить все точки над «ё» и установить этим каверзным переменным нужные значения изначально, чтобы не ломать потом голову, почему что-то идёт не так, как вам хочется.

Итак, обе переменные находятся в одном файле — config/app.php. Открываем его и ищем следующий блок:

'timezone' => 'UTC',
'locale' => 'en',

В моём случае значения у них были ‘Europe/Kiev’/’ru’. Тут хочется сделать небольшое уточнение по поводу часового пояса.

Изначально, увидев значение «UTC», мне захотелось использовать запись в формате UTC+2, но данная переменная принимает в качестве значения PHP timezones, нужную из которых вы можете найти по указанной ссылке.

Ну вот, собственно говоря, и всё, что я хотел вам сегодня сказать. В ходе публикации мы с вами произвели комплексную настройку Laravel, начиная с запуска проекта на веб-серверах Apache, Nginx и WAMP-сборке OpenServer, и заканчивая настройкой глобальных переменных, необходимых для соединения с БД и корректной работы сайта в целом.

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

Также не забывайте пользоваться социальными кнопками под статьёй.

На этом у меня всё. До скорых встреч :-)

Laravel install: 5 способов установки и 2 варианта запуска

laravel-ustanovkaПриветствую вас, друзья!

Сегодня мы продолжаем знакомство с Laravel PHP framework, которое началось в предыдущей статье, посвящённой обзору особенностей данного фреймворка.

А сегодня мы от сухой теории переходим к практике и произведём установку Laravel на веб-сервер, чтобы наконец-то приступить к разработке сайта.

Framework, как и программы, имеет свои системные требования для полноценной работы. Они, правда, слегка отличаются от софтовых, т.к. заключаются не в особенностях железа (объём ОЗУ, частота процессора и т.д.), а в наличии необходимых программ и их версий.

Вот с этого мы и начнём процесс установки Laravel.

Установка Laravel – системные требования

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

  • PHP >= 5.6.4
  • OpenSSL PHP Extension
  • PDO PHP Extension
  • Mbstring PHP Extension
  • Tokenizer PHP Extension
  • XML PHP Extension

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

По поводу разновидности самого web-сервера нет ни слова. Apache, Nginx и др. — на всём этом Laravel установить и запустить более чем реально :-) Потребуются некоторые настройки конфигурации для комфортной работы, но об этом мы поговорим немного позже.

Способы установки Laravel

Переходим непосредственно к процессу установки Laravel, которую можно произвести несколькими способами. Я рассмотрю все возможные, а вы сами выбирайте тот, который вам по душе.

Install Laravel через Composer

Я решил начать с самого распространённого способа установки Laravel среди разработчиков — через пакетный менеджер Composer.

Почему данный способ самый распространённый? Да потому, что у многих данное ПО уже установлено :-) И всё, что нужно для того, чтобы развернуть Laravel, — это запустить соответствующую команду и немного подождать, пока скачаются все необходимые файлы, и установятся соответствующие зависимости.

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

Установка Composer

Для того, чтобы установить Composer, необходимо перейти по данной ссылке.

Если вы используете ОС Windows, то для установки Composer можно воспользоваться инсталлятором, который, кроме установки, также редактирует системную переменную $PATH, благодаря чему консольную команду composer возможно вызывать глобально, вне зависимости от того, в какой папке вы находитесь.

Всё же не лишним будет перезапустить компьютер после установки, чтобы изменения переменной $PATH воспринялись ОС.

Если же вы работаете из-под другой ОС (Linux, MacOS), то в вашем случае для установки существует ещё и консольный вариант:

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('SHA384', 'composer-setup.php') === '669656bab3166a7aff8a7506b8cb2d1c292f042046c5a994c43155c0be6190fa0355160742ab2e1c88d40d5be660b410') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"

При данном варианте возможно выбирать целевую директорию, в которой будет установлен Composer, его версию и название файла, который по умолчанию называется composer.phar.

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

Также не забудьте изменить переменную $PATH и перезагрузить компьютер :-)

Установка Laravel

После успешной установки Composer на ваш сервер в консоли переходим в папку, где будет располагаться будущий сайт. Я при разработке сайтов пользуюсь ОС Windows и замечательной программкой OpenServer, поэтому я создам Laravel проект прямо в каталоге сайтов OpenServer, предназначенном для этих нужд:


cd c:\openserver\domains\localhost

Далее устанавливаем Laravel следующей командой:


composer create-project --prefer-dist laravel/laravel Laravel5Portfolio

Самый последний параметр – название каталога сайта, в который будет установлен Laravel. В моём случае это «Laravel5Portfolio», вы можете написать вместо него своё название.

Данная команда автоматически скачивает Laravel в указанную папку и запустит процесс установки. Остаётся только наблюдать.

На финальном этапе установщик генерирует ключ приложения, который будет использоваться для шифрования сессий, кук и паролей, поэтому рекомендуется его на всякий случай проверить, чтобы в дальнейшем не было проблем с данными объектами.

Он хранится в файле .env в корне проекта в виде 32-символьного значения переменной APP_KEY. Ежели она пустая, запустите в консоли artisan-команду key:generate.

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

Установка Laravel с помощью установщика

Итак, ещё один способ установки Laravel, потребующий наличия Composer.

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

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

composer global require "laravel/installer"

Далее, как и при установке Composer, необходимо будет отредактировать системную переменную $PATH, о чём я уже говорил. Это нужно для декларации глобальной консольной команды, благодаря которой новый Laravel проект будет создаваться следующим способом:

laravel new blog

В данном примере, после вызова команды в определённой директории, в которую можно попасть путём ввода команды cd путь_к_директории, будет создана папка blog, в которую установится последняя версия Laravel PHP framework.

Ручная установка Laravel

Установка Laravel с помощью Composer проста, понятна, а потому и рекомендуема. Но всё же, данный способ не является единственным, чтобы развернуть Laravel у себя на компьютере.

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

Для этого необходимо зайти на github.com и скачать файлы из официального репозитория Laravel:

laravel-ustanovka-s-github

Для download Laravel 5 нужно нажать на кнопку «Download ZIP», которая доступна в правом выпадающем меню. Кстати, при скачивании файлов из ветки «master», которая доступна по умолчанию, при входе в репозиторий, вы получите самую последнюю версию движка, которая на сегодняшний день Laravel 5.4.19.

Ну, а далее следует стандартная распаковка zip-архива в директорию, где будет располагаться будущий сайт.

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

Кстати! При данном способе установки не забудьте после распаковки архива перейти в консоли в папку проекта и запустить следующую команду:


composer update

С помощью неё вы установите файлы самого фреймворка, хранящиеся в папке vendor, и прочие компоненты, идущие в Laravel из коробки, которые не храняться в Laravel репозиториях благодаря соответствующему правилу в файле .gitignore, расположенному в корне проекта.

Установка Laravel через Git с GitHub

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

Для этого запускаем Git Bash (Git консоль) в любой директории вашего ПК (лучше всего запустить её сразу в каталоге веб-сервера, содержащего папки сайтов) и вводим следующую команду:


git clone https://github.com/Pashaster12/Laravel5Portfolio.git

С помощью неё вы скопируете файлы из официального репозитория Laravel, адрес к которому указывается в качестве параметра. Если интересно, как я его узнал — посмотрите на скриншот в предыдущем способе установки, где открыто окно с кнопкой «Download ZIP».

Выше кнопки есть текстовое поле, в котором прописан адрес репозитория в HTTPS/SSH форматах. Я использовал HTTPS-вариант, который достаточно скопировать в буфер, а потом вставить в консоли в качестве параметра.

После запуска команды вы получите файлы фреймворка у себя на компьютере. И не забудьте, как и в предыдущем способе, запустить composer update для установки недостающих ресурсов. Без них запустить и воспользоваться фреймворком у вас не получится.

Особенности установки Laravel на виртуальную машину

Наверное, если не все, то многие из вас слышали о виртуальных машинах, которые возможно создавать путём установки специальных программ (виртуализаторов) на вашу основную операционную систему (ОС) реального компьютера.

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

Плюсов в данном подходе масса:

  1. Для всех необходимых компонентов сервера уже есть готовые пакеты, поэтому устанавливать их очень просто;
  2. Если вы работаете над проектом параллельно с несколькими другими разработчиками, то всё, что будет нужно сделать новым участникам команды — это скопировать существующую виртуальную машину на свой локальный компьютер;
  3. Начало работы будет максимально простым — достаточно настроить автозапуск компонентов при старте виртуальной машины и запустить её (если сделать подобное на реальной машине, то вся эта куча будет стартовать даже тогда, когда вам нужен будет ПК лишь для запуска Skype, что неудобно).

Помимо виртуальной машины, в разработке есть понятие виртуальной рабочей среды, которое заключается в наличии «как бы установленного» необходимого ПО для запуска отдельных проектов.

Данную виртуальную среду разработки можно получить как при помощи установки отдельного ПО (например, Docker) либо используя надстройки для уже используемых программ-виртуализаторов.

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

Установка Laravel Homestead

Laravel Homestead — это официальный пакет для Vagrant, средства для конфигурации и установки виртуальной среды разработки.

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

The Laravel framework has a few system requirements. Of course, all of these requirements are satisfied by the Laravel Homestead virtual machine, so it’s highly recommended that you use Homestead as your local Laravel development environment.

Vagrant является программной обёрткой для существующих виртуализаторов (Oracle VirtualBox, VMWare, Parallels и т.д.), т.е. для того, чтобы организовать виртуальную среду разработки для работы с Laravel данным способом, придётся:

  1. Установить виртуализатор;
  2. Установить Vagrant;
  3. Установить Laravel Homestead.

После всех данных действий вы получите следующий список ПО без их физической установки:

  • Ubuntu 16.04
  • Git
  • PHP 7.1
  • Nginx
  • MySQL
  • MariaDB
  • Sqlite3
  • Postgres
  • Composer
  • Node (With Yarn, Bower, Grunt, and Gulp)
  • Redis
  • Memcached
  • Beanstalkd
  • Mailhog
  • ngrok

Если у вас уже есть виртуализатор с настроенной виртуальной машиной, то данный способ не предоставит вам особых сложностей.

Если же у вас ничего нет, то потребуется достаточно много телодвижений, т.к. помимо установки требуемых программ для ОС Windows ещё необходимо будет включить аппаратную виртуализацию в BIOS (VT-x). Это, пожалуй, единственный минус данного подхода.

Ну, и ещё, тут имеет дело привычки. Мне, например, данные инновации в виде виртуальных сред разработки не пришлись по вкусу. Я давно нашёл для себя комфортное средство для разработки — OpenServer, добавление новых компонентов в котором также происходит путём визуального выбора нужного ПО и его версии.

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

Но, мне пока что и не нужно никуда свои проекты переносить :-) Поэтому для моих задач OpenServer мне с головой хватает: раз настроил версии серверных компонентов — и вперёд, только новые проекты добавлять останется.

В случае с тем же Docker, для каждого нового проекта придётся снова производить конфигурацию модулей. Причём, всё это происходит в консольном режиме с использованием команд API Docker.

Я пытался пользоваться данным ПО, но лично мне оно показалось неудобным и, честно говоря, не вижу в нём особого смысла. Зачем извращаться и изучать ещё одно API, если можно направить свой энтузиазм на изучение настроек серверов, которые применяются повсеместно — и при локальной разработке, и при работе сайтов на Shared хостингах, и на выделенных серверах.

В общем, Docker мне пока что показался бессмысленным и абсолютно не понравился, поэтому я решил вернуться к OpenServer.

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

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

Установка Laravel — завершающий этап

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

Как же теперь проверить, что мы всё сделали правильно?

Самый простой способ проверки работоспособности Laravel даже не потребует от вас наличия настроенного веб сервера. Минимальным требованием является наличие установленного PHP.

В таком случае для запуска Laravel можно будет воспользоваться встроенным в PHP сервером разработки с помощью artisan команды serve:

php artisan serve

Данная команда запускает сервер разработки по URL http://localhost:8080 и делает доступным сайт, в папке которого вы вызвали команду serve.

Если же у вас уже есть в наличии настроенным веб-сервер со всеми необходимыми компонентами (минимум Apache/Nginx + PHP), то для тестового запуска Laravel введите в строке браузера url вашего сайта, добавив в конце «/public», т.к., ввиду файловой структуры Laravel, даже после успешной установки, при входе на сайт вы увидите только список файлов.

Итак, если вы всё сделали правильно, то в окне браузера вы увидите приветственный экран Laravel:

laravel-ustanovka-ekran-privetstviya

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

Если же вы не смогли даже настроить Laravel на веб-сервере, то дождитесь следующей статьи, в которой будут изложены подробные инструкции по запуску Laravel как на WAMP/LAMP сборках, так и на чистых серверах — Nginx и Apache. А также мы поговорим, как избавиться от ссылки на public директорию в URL сайта.

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

Ну, и не лишним будет напомнить о том, чтобы вы не забывали делиться записью со своими друзьями с помощью социальных кнопок внизу. Для вас мелочь — а мне приятно :-)

На этом всё. Пока.

the_posts_pagination(array( 'mid_size' => 3, 'prev_text' => __('« Предыдущая'), 'next_text' => __('Следующая »') ));