Author Archives: Pashaster

About Pashaster

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

WP Elementor: достойная альтернатива онлайн-конструкторам

wordpress-elementorВсем привет! 🙂 Эх, давненько я не писал… даже успел соскучиться за этим делом.

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

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

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

Уверен, что будет интересно. Поехали! 🙂

WordPress конструкторы сайтов — что это и зачем они нужны?

Когда люди говорят о WordPress конструкторах, они имеют ввиду плагины конструкторов сайтов и страниц WordPress (page builder plugins). Их много: Visual Composer, Beaver Builder, Velocity Page… WP Elementor — лишь один из них.

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

Виджеты представляют собой, по сути, детали, из которых и собирается итоговое изделие — страница сайта, в нашем случае. Поэтому аналогия с детскими конструкторами типа LEGO как нельзя кстати 🙂wp-elementor-vozmozhnosti

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

Что такое WordPress конструкторы — думаю, понятно. Зачем они нужны? Думаю, вы догадались… для упрощения жизни пользователям, не знакомым с программированием, т.к. процесс создания страниц сайта при использовании page builders заключается в добавлении на полотно необходимых элементов, их настройке и взаимном расположении на странице.

Именно поэтому, когда говорят о конструкторах, частенько добавляют приставку «визуальный», т.к. они позволяют максимально визуализировать процесс создания сайта и сделать из вашей WordPress админки аналог онлайн конструкторов (например, всем известного Wix), в которых процесс создания веб-ресурсов заключается в добавлении на пустую страницу различных элементов путём их перетаскивания (Drag-n-Drop).

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

WP Elementor: первое впечатление

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

Для этого я решил изучить его описание на официальном сайте и в официальном репозитории WP плагинов.

Сразу скажу, что начальное впечатление сложилось хорошее 🙂

Во-первых, потому что у WordPress Elementor вообще есть сайт, отсутствием которого грешат многие продукты.

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

Во-вторых, у WP Elementor есть свой YouTube-канал с массой интересный и профессионально смонтированных видео. В качестве примера предлагаю вашему вниманию короткое интро, на котром представлен процесс создания сайта с использованием данного плагина:

В-третьих, меня впечатлила статистика WP Elementor на wordpress.org:

  • больше миллиона установок;
  • средний балл 4.8 из 5 (900 из 982 проголосовавших поставили высший балл);
  • частота обновлений (на момент изучения его описания последнее обновление было сделано 2 дня назад);
  • поддержка 30 языков интерфейса.

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

А в конце я озвучу вам отличия Pro версии от бесплатной с подробными расценками, чтобы вы могли понять — нужно ли вам её приобретать или нет 🙂

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

  1. https://www.page-and-paper.de — настоящий Интернет-магазин, демонстрирующий интеграцию WP Elementor с WooCommerce элементами;
  2. https://salonbook.one — красивый WordPress Elementor сайт с системой бронирования;
  3. https://sodapopdigital.com.au — яркий сайт со Sticky Elementor menu;
  4. https://www.prodtool.com.br — многостраничный сайт с множеством форм обратной связи и заказа звонка;
  5. https://teamonesecurity.dk — интересный многостраничный сайт с Masonry структурой;

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

WordPress Elementor: установка плагина и подготовка сайта

После положительного первоначального впечатления о ВордПресс Elementor я, естественно, решил продолжить знакомство с ним.

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

Свои эксперименты с ВордПресс Elementor я решил производить на чистом WordPress сайте, что позволит нам смоделировать процесс создания веб-ресурса с применением Elementor page builder с нуля.

Для этого я в панели управления своего хостинга (всё время существования данного сайта пользуюсь TheHost и пока не планирую его менять благодаря низким ценам) создал поддомен для данных целей, доступный по адресу http://elementor.cccp-blog.com, куда установил чистый WordPress.

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

Установку можно произвести как минимум двумя способами:

  1. скачать WordPress Elementor с официального сайта или репозитория WP плагинов в виде архива с дальнейшей его установкой в админке;
  2. установить WordPress Elementor прямо в админке из встроенного каталога плагинов.

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

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

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

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

Elementor WordPress: как пользоваться?

После установки WP Elementor на сайт первым изменением, которое лично я заметил, стала большая кнопка Редактировать в Elementor, которая появилась при редактировании содержимого страниц и постов в админке WordPress:

wordpress-elementor-knopka-zapuska

Как видите, в качестве подопытного кролика я решил взять стандартную WordPress sample page, т.е. пример страницы, говоря по-русски, которая имеет url http://корень_сайта/sample-page и выглядит следующим образом:

stranica-do-redaktirovaniya-v-wordpress-elementor

После нажатия на кнопку Редактировать в Elementor плагин активируется, и интерфейс редактирования контента страницы принимает следующий вид:

wordpress-elementor-interfejs

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

Весь существовавший до редактирования через WP Elementor page builder контент страницы автоматически преобразуется в подходящие по типу виджеты, что и произошло с основным текстом страницы на скриншоте выше.

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

Следить за структурой документа в WordPress Elementor помогает инструмент под названием Навигатор, который вызывается из футера панели инструментов, и выглядит так:

wordpress-elementor-navigator

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

Изменить шаблон страницы в WP Elementor page builder можно через следующее меню:

wordpress-elementor-nastrojki-stranicy

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

wordpress-elementor-kontekstnoe-menyu

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

Если вместо кастомного контекстного меню WordPress Elementor вы захотите использовать стандартное меню браузера, то используйте комбинацию Ctrl + ПКМ (правый клик мышью).

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

Состоит она, как и большинство сайтов, из хэдера, блока контента и футэра.

В хэдере всего две кнопки:

  1. Меню плагина.
  2. Кнопка возврата на стартовый экран с виджетами.

Если со вторым элементов всё предельно ясно, то меню требует дополнительного изучения:

wordpress-elementor-menyu-plagina

Здесь находятся ссылки на экраны настроек шрифтов и цветов заголовков H1, H2, основного и акцентного текста. Пункт Выбор цвета нужен для добавления новых цветов в палитры WordPress Elementor.

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

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

История изменений

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

wp-elementor-istoriya-izmenenij

В данном меню будут также доступны и версии документа, созданные при ручном сохранении в Elementor конструкторе, которое происходит при нажатии на соответствующую кнопку в футере:

wp-elementor-sokhranenie-izmenenij

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

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

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

wordpress-elementor-kontrol-dejstvij

Режим адаптивности

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

wordpress-elementor-rezhim-adaptivnosti

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

Просмотр изменений

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

wordpress-elementor-prosmotr-izmenenij

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

wp-elementor-globalnye-nastrojki-plagina

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

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

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

wp-elementor-menedzher-rolej

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

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

wp-elementor-menedzher-shablonov

Правда, как видите, ограничивать доступ к контенту можно только при наличии Pro версии WP Elementor плагина.

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

wordpress-elementor-rezhim-obsluzhivaniya

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

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

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

Сейчас же мы займёмся изучением виджетов WordPress Elementor на практике, рассматривая их свойства на примере создания реального сайта, чтобы вы могли воочию убедиться, насколько данный page builder plugin облегчает жизнь своим пользователям 🙂

Создание сайта на WP Elementor — инструкция

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

Ну, и, естественно, разными специфичными виджетами WordPress Elementor, ради которых всё это занятие и будет проводиться.

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

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

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

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

Надеюсь, вам и мне этот эксперимент понравится 🙂

Структура сайта вышла следующая:

  • главный блок с презентацией продукта;
  • счётчики клиентов, преподавателей, офисов и городов;
  • программа курса;
  • блок отзывов довольных клиентов;
  • стоимость занятий;
  • «как нас найти?» (адрес и отметка на Google карте);
  • «мы в соцсетях» (ссылки на социальные сообщества);
  • копирайт.

Думаете, что на подбор виджетов, изучение их свойств и саму разработку потребуются дни? Как бы… нет 🙂 Лично у меня, как у человека, впервые в жизни работавшего с WP Elementor, и придумывающего дизайн «на лету» на всё про всё потребовалось 3 часа 34 минуты.

Поэтому рекомендую вам прямо сейчас засечь время и написать в комментариях, сколько времени уйдёт на создание сайта у вас 🙂 Устроим, так сказать, мини-соревнование 🙂

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

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

wordpress-elementor-struktura-sekcij

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

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

Для этого у свойства Фон на вкладке Стиль выбираем нужный цвет (можно с различными типами градиента) или картинку, как в моём случае. Правда, у фона секций в WordPress Elementor нет настроек прозрачности, яркости, контрастности и т.д. Зато всё это есть в блоке настроек Перекрытие фона, значениям которого я установил следующие значения:

wordpress-elementor-oformlenie-nalozheniya-fona

Чтобы добиться Parallax-эффекта, параметру Привязка я установил значение Замостить. Остальные настройки — чистой воды Фотошоп, только средствами CSS.

Надписи на фоне — это отдельные виджеты. Первый — Заголовок. Второй — Текстовый редактор. Настройки шрифта у обоих находятся на вкладке Стиль в выпадающем меню пункта Типографика:

wp-elementor-nastrojki-stilya-zagolovka

На этой же вкладке находятся настройки выравнивания текста.

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

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

Настройки его содержимого выглядят следующим образом:

wordpress-elementor-nastrojki-vidzheta-spiska

Здесь, как видите, можно управлять элементами списка. Причём, как их текстом, типом иконки и адресами ссылок, так и взаимным расположением (вертикальный или горизонтальный список). На вкладке Стиль для данного WP Elementor виджета можно устанавливать настройки шрифта заголовка и иконки, а также разделители элементов списка и расстояние между ними.

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

wordpress-elementor-nastrojki-animacii

Для списка я установил эффект анимации Fade In Up, который заключается в «выезжании» объекта снизу вверх, а для заголовка — Fade In Down, чтобы он «выезжал» сверху вниз, т.е. навстречу списку. Получилось, как по мне, симпатично 🙂

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

Следующий структурный элемент нашей landing page — это блок с отзывами клиентов, создать который не составило никакого труда благодаря специализированному WordPress Elementor виджету с названием Отзыв, настройки содержимого которого выглядят так:

wordpress-elementor-vidzhet-otzyvaЗдесь можно настраивать как сам текст отзыва (с применением кастомной HTML разметки и CSS свойств), так и картинку, имя рецензента, его должность и стили всех перечисленных блоков.

После блока отзывов у нас идёт ценник — сколько, собственно говоря, будут стоить продаваемые услуги. Я решил не заморачиваться составлением ценников, которые вы могли видеть на большинстве лэндингов: с различными расценками и списками услуг, и решил обойтись единой ценой. На данное решение, кстати, повлияло ещё и то, что данный виджет доступен только в WordPress Elementor Pro, о возможностях которого я буду рассказывать далее.

Данный блок я оформил, как и предыдущие: одноколоночная секция с минимальной высотой в 400px и Parallax-фоном, внутри которой разместил два h2-заголовка с эффектами анимаций Fade In Left и Fade In Right, чтобы они выезжали навстречу друг другу только не вертикально, а горизонтально — в принципе, ничего интересного 🙂

Зато для следующей секции лэндинга с отображением географического положения офиса мне понадобился новый тип виджета — Карты Google. Настройки его содержимого выглядят следующим образом:

wp-elementor-vidzhet-google-karty

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

Следующий блок нашего лэндинга — кнопки социальных сетей со ссылками на соответствующие сообщества. Для его создания также не пришлось сильно изощряться, т.к. в WordPress Elementor уже есть необходимый виджет — Иконки соцсетей, настройки контента которого выглядят так:

wp-elementor-vidzhet-ikonki-socsetej

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

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

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

Вот и всё, на этом сайт был готов. Казалось бы — можно размещать на хостинге и колотить бабло 🙂 Но, не тут-то было…

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

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

wp-elementor-nastrojki-vidzhetov-dlya-razlichnykh-ustrojstv

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

На основании получившегося в итоге WordPress Elementor документа я создал шаблон, который можно скачать по этой ссылке. А что с ним делать — об этом я расскажу в следующей статье, посвящённой созданию и установке WP Elementor шаблонов и плагинов.

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

Если вы пока ещё не заметили по приведённым в данной статье картинкам, она одинакова, что позволяет лучше ориентироваться в местоположении параметров у разных элементов. Свойства всех объектов состоят из 3 вкладок: Содержимое, Стиль и Расширенное.

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

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

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

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

  • вставка картинок и видео контента с Youtube и Vimeo;
  • галерея изображений;
  • Elementor slider или, по-простому говоря, карусель (слайдер) картинок;
  • шкала прогресса;
  • вкладки;
  • Elementor popup — всплывающие окна для форм подписок на новости и прочих маркетинговых штук;
  • аккордеон и toggle элементы — группа связанных аккордеонов, из которых одновременно может быть открыт только один;
  • якоря;
  • кнопки (кнопка в Elementor обычно используется для вызова всплывающих меню, форм и для перемещения по секциям страницы);
  • чистый HTML-код;
  • шорткоды — позволяет вставлять в WP Elementor документы кастомные шорткоды или генерируемые другими плагинами;
  • сайдбар — разные сайдбары, как основной WordPress темы, так и кастомные.

WordPress Elementor Pro: отличия от бесплатной версии

С возможностями бесплатной версии WP Elementor я вас познакомил. Для создания незаурядных landing page, подобных созданной мной выше, как вы поняли, их хватит с головой. А вот если вы захотите чего-то посерьёзней, то вам, скорее всего, понадобится немного больше.

Как раз для этого у WordPress Elementor есть расширенная Pro версия, с помощью которой возможно создавать не только лэндинги, но и другие типы сайтов, в том числе и Интернет-магазины.

Чем конкретно WordPress Elementor Pro отличается от бесплатной версии плагина?

Нужно больше виджетов…

Прежде всего, в ней доступно на 25 виджетов больше, среди которых такие, как:

  • список постов блога;
  • портфолио;
  • редактирование header и footer в Elementor конструкторе;
  • конструктор форм, с помощью которого можно создавать контактную форма, форму подписки на почтовую рассылку, календарь бронирования услуг (booking calendar) и многое другое;
  • авторизация на сайте;
  • конструктор меню сайта (причём, WordPress Elementor позволяет делать как липкое меню, sticky menu, так и фиксированное);
  • прайслист и таблица ценников, которую я хотел добавить на свой тестовый сайт, но в бесплатной версии, к сожалению, без костылей таковую не создать;
  • карусель отзывов, которой мне, кстати, тоже не хватило в бесплатной версии при создании сайта, из-за чего я вынужден был добавить всего один отзыв;
  • обратный отсчёт, который отлично подходит для организации акций;
  • интеграция Facebook (комментарии, страница, кнопка лайка и т.д.) и WooCommerce с WordPress Elementor сайтами (категории, товары, элементы, добавление в корзину) элементов;
  • элементы навигации: поиск по сайту, хлебные крошки, пагинация постов и т.д.

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

Больше настроек

WordPress Elementor Pro предоставляет также множество дополнительных настроек структуры секций (можно делать разные вариации Masonry блоков), гридов постов блога, списков и т.д.

Глобальные виджеты

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

Схема проста: берёте стандартный виджет WP Elementor, настраиваете его, а затем используете в кастомизированном виде на любой странице сайта. Удобно 🙂

Кастомные CSS стили

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

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

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

  • 49$ для одного сайта — идеально для владельцев сайтов, разрабатывающих свой ресурс самостоятельно;
  • 99$ для 3 сайтов  — отлично подойдёт для владельцев нескольких ресурсов;
  • 199$ для неограниченного количества сайтов — вариант для веб-студий и фрилансеров, зарабатывающих себе на хлеб с маслом созданием сайтов на базе WordPress Elementor.

Приобрести и скачать WordPress Elementor Pro вы сможете по этой ссылке. Если плагин вас разочарует или по каким-то причинам не подойдёт, вы сможете получить свои деньги обратно в течении 30 дней.

WordPress Elementor: финальные выводы

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

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

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

Как при условии профессионального создания сайтов, так и при разработке ресурса самостоятельно стоимость WordPress Elementor Pro окупится в первый же месяц, гарантирую! При разработке сайта данная сумма окупится при первом же заказе, а при условии развития собственного проекта 49$ — не такая уж и заоблачная инвестиция 🙂

И ещё одной фишкой, которая мне особенно понравилась в WordPress Elementor, стала возможность самостоятельного создания WordPress Elementor шаблонов с целью дальнейшей их продажи и повторного использования.

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

На этом сегодня всё. Устанавливайте WordPress Elementor на свой сайт и смело испытывайте его функционал, т.к., несмотря на краткий экскурс по его возможностям в данной статье, лучше один раз попробовать продукт самостоятельно, чем сто раз о нём прочитать 🙂

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

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

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

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

Laravel custom admin: делаем админку своими руками

laravel-custom-adminВсем привет! 🙂

После написания статьи с обзором Laravel Admin Panel пакетов, которые позволяют легко и быстро добавить в своё Laravel приложение админку, я получил несколько сообщений как в комментариях на сайте, так и в офлайне (что было для меня приятной неожиданностью, если честно) от моих читателей, которые жаждали продолжения и ответа на вопрос «На чём же я всё-таки остановился» 🙂

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

Но, в итоге, спустя два месяца ожиданий, я наконец созрел с выбором, прикрутил понравившуюся мне админку к сайту и наконец расскажу вам об этом 🙂

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

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

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

Поехали!

Чем не устроили Laravel Admin пакеты?

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

Скажу сразу и честно, что мои мотивы, на самом деле, были нелогичны и лишены здравого смысла 🙂

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

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

Это, кстати, и послужило первым мотивом для создания кастомной Laravel admin panel.

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

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

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

А вот по поводу универсального мануала, который позволит вам самим добавить админку на Laravel сайт, причём с frontend и backend частями, а также разработанные с применением технологий, которые вы выберите сами, я ещё не встречал 🙂

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

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

Поэтому в демонстрации разработки кастомной Laravel admin panel я также заинтересован, т.к., возможно, кто-то из вас решит в дальнейшей оформить получившуюся админку в виде пакета и сделать её достоянием общественности, добавив плюсик в портфолио себе, карму мне, и в развитие OpenSource в целом 🙂

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

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

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

Так что данный момент можно считать третьим мотивом отказа от пакетов в пользу разработки самописной Laravel custom admin panel, т.е. кастомные админки можно разрабатывать с целью профессионального роста и задела на будущее.

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

Ну, и последним, четвёртым мотивом отказаться от Laravel packages при добавлении админки к сайту послужил тот факт, что пакеты есть пакеты… Пока они саппортятся разработчиком и комьюнити — всё хорошо.

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

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

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

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

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

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

Этот способ реализации Laravel custom admin отлично подойдёт при выполнении 99% проектов «под ключ», т.е. без дальнейшего саппорта разработанного в его рамках кода.

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

С чего начать реализацию кастомную Laravel админки?

Итак, допустим вы, как и я, приняли решение создавать самописную Laravel admin panel. Отлично! 🙂

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

Итак, при подборе инструментов реализации кастомной Laravel админки я лично руководствовался следующим мини-алгоритмом:

1. Как делать фронт: верстать с нуля или на шаблоне?

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

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

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

2. Выбор стэка технологий

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

Речь сейчас идёт о frontend-стэке, т.е. CSS, HTML препроцессорах и постпроцессорах, JS фреймворках и библиотеках, сборщиках статики и т.д.

В отношении бэкэнда набор инструментов для админок, как правило, не такой обширный, т.к. никаких сложных процессов, кроме работы с БД и, может быть, управление очередями сообщений и кэшированием, в ней не происходит. Но, если ваш проект нестандартный — возможно, внимание придётся уделить и backend стэку.

В любом случае, полностью из внимания этот момент упускать нельзя.

3. Подготовка к реализации

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

Но, главное — не переусердствовать 🙂 Если понравившийся вам вариант не будет содержать 100% определённых вами технологий (а, может, наоборот, будет напичкан ими чрезмерно) — это не должно являться причиной отказываться от него.

Всё должно упираться в конечные цели.

Например, в моём случае, помимо написания своего backend для админки я хотел попутно ещё и освоить VueJS JavaScript фреймворк. Поэтому я сознательно выбирал для своего тестового сайта шаблоны админок, которые не были разработаны с использованием данной технологии. И фреймворков вообще, чтобы не заниматься потом их «выпиливанием» и переписыванием готовых компонентов «под себя».

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

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

4. Собственно реализация

Ну, и после того, как все подготовительные этапы будут успешно пройдены, останется приступить к реализации задуманного. Главное — не спешить и настраиваться, что быстро вы админку не сделаете. При удачном стечении обстоятельств потребуется не меньше 4-х полноценных рабочих дней, т.е. 32 часа. Лучше всё делать не спеша, максимально взвешенно и получать удовольствие от процесса 🙂

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

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

Laravel custom admin panel: пример реализации

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

Подготовка к реализации кастомной Laravel админки

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

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

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

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

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

  1. Чистый CSS3 и HTML5. Использование препроцессоров и постпроцессоров было не принципиально.
  2. Конфиги для каких-либо сборщиков статики также не были must have. По той простой причине, что я всё равно отказался бы от них, т.к. в дальнейшем планирую собирать статику с помощью Laravel Mix, а встретить шаблон, заточенный под эту либу, было практически нереально.
  3. Шаблон должен быть разработан с использованием Bootstrap4. Просто потому что люблю я этот frontend фреймворк, т.к. достаточно долго с ним работал и более-менее в курсе его API. Ну, а для разработки стартапа я выбрал, естественно, последнюю его версию (не смотря на то, что витрина моего корпоративного сайта разработана на Bootstrap3 шаблоне).
  4. Никаких JS фреймворков не должно быть и следа. За исключением jQuery, может быть. Хотя его и фреймворком-то назвать можно весьма условно 🙂 Это требование основывалось на том, что, как я уже и говорил ранее, в дальнейшем я планирую самостоятельно переписать полученную на данном этапе админку с использованием VueJS, поэтому сторонние компоненты будут меня только отвлекать.

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

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

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

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

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

В моём случае, правда, этого, слава Богу, не понадобилось, т.к. мне на глаза в конце-концов попался вариант, который отвечал всем моим требованиям — Ela Admin. Лично для меня он выступил золотой серединой между функциональностью и минималистичностью дизайна, который я также искал.

Ну, и дополнительным плюсом для выбора этого шаблона выступил тот факт, что данный продукт — разработка создателя одного из самых популярных HTML Admin templates — Gentelella, у которого на Github сейчас более 15000 звёзд.

Следовательно, с качеством кода у его нового детища также должно было быть всё ОК.

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

Я никак не мог подумать, что проект, у которого было больше 300 звёзд, могут вот так просто удалить… Возможно, это связано с тем, что его разработчик решил коммерциализировать проект (уж очень мне этот его шаблон показался похожим на Ela Admin).

В прочем, это — его право. Жаль только, что для OpenSource комьюнити код его, похоже, будет навсегда потерян… Правда, если репозиторий так и не реанимируют, можете обратиться ко мне в комментариях — я поделюсь архивчиком 🙂 А, может быть, и выложу его на свой GitHub аккаунт в публичном доступе. Не знаю только, как настоящий хозяин к этому отнесётся…

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

Реализация custom Laravel admin panel

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

1. Разделение файлов витрины и админки

Итак, первым делом я решил разделить файлы, относящиеся к админке и витрине сайта, путём создания отдельных каталогов site и admin, которые я создал в директории контроллеров (app/Http/Controllers), ассетов (resources/assets) и views (resources/views).

Все существующие на данный момент файлы, которые располагались в корне указанных папок, я переместил в подкаталоги site, т.к. они соответствуют витрине сайта. Файлы же, необходимые для работы админки, будут создаваться в подкаталоге admin — всё просто 🙂

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

2. Перенос файлов шаблона в Laravel приложение

Если вы когда-нибудь работали с шаблонами, неважно чего: витрины сайта или админки, то вы должны иметь представление, как они устроены.

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

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

Лично мне на данном этапе, для добавления новых постов в блог, нужно сделать три страницы:

  • страница авторизации;
  • список постов с элементами редактирования и удаления конкретных элементов;
  • страница добавления нового поста.

Поэтому я выбрал из файлов шаблона те страницы, которые содержали необходимые мне UI элементы, и перенёс их в директорию resources/views для дальнейшей их обработки.

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

3. Создание Blade views на базе файлов шаблона

Файлы шаблона в большинстве случаев представляют собой самые простые HTML файлы с подключёнными внутри них JS и CSS скриптами. Причём, практически в каждом файле данные куски кода одинаковые, как и элементы структуры (сайдбар, шапка, футер).

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

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

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

Исходя из базовой структуры страниц Ela Admin template мне удалось выделить следующие повторяющиеся блоки:

  1. заголовки HTML документа и прочая информация, размещаемая в тэге head;
  2. блок подключения CSS-скриптов в самом верху документа;
  3. хэдер;
  4. сайдбар;
  5. футер;
  6. блок подключения JS-скриптов в самом верху документа.

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

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

Итак, в результате у меня получились следующие Blade-файлы, найти которые можно в каталоге resources/views/admin/layouts:

htmlheader.blade.php — HTML заголовки:

<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="description" content="">
    <meta name="author" content="">
    
    <link rel="icon" type="image/png" sizes="16x16" href="{{ asset('/admin/images/favicon.png') }}">
    <title>Laravel Ela Admin</title>
    
    @include('admin.layouts.styles')
</head>

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

Внизу подключается файл с CSS-скриптами посредством Blade-директивы include.

styles.blade.php — подключение CSS-скриптов:

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

@stack('custom_styles')

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

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

header.blade.php — хэдер страницы:

<div class="header">
    <nav class="navbar top-navbar navbar-expand-md navbar-light">
        <div class="navbar-header">
            <a class="navbar-brand" href="{{ url('admin') }}">
                <b><img src="{{ asset('/admin/images/logo.png') }}" alt="homepage" class="dark-logo" /></b>
                <span><img src="{{ asset('/admin/images/logo-text.png') }}" alt="homepage" class="dark-logo" /></span>
            </a>
        </div>
        <div class="navbar-collapse">
            <ul class="navbar-nav mr-auto mt-md-0">
                <li class="nav-item"> <a class="nav-link nav-toggler hidden-md-up text-muted  " href="javascript:void(0)"><i class="mdi mdi-menu"></i></a> </li>
                <li class="nav-item m-l-10"> <a class="nav-link sidebartoggler hidden-sm-down text-muted  " href="javascript:void(0)"><i class="ti-menu"></i></a> </li>
                <li class="nav-item">
                    <a class="nav-link text-muted" href="{{ url('/') }}"><i class="ti-home"></i>
                        <span class="hidden-sm-down">Перейти на витрину</span>
                    </a>
                </li>
            </ul>
            <ul class="navbar-nav my-lg-0">
                <li class="nav-item dropdown">
                    <a class="nav-link dropdown-toggle text-muted  " href="#" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false"><img src="{{ asset('/admin/images/user.jpg') }}" alt="user" class="profile-pic" /></a>
                    <div class="dropdown-menu dropdown-menu-right animated zoomIn">
                        <ul class="dropdown-user">
                            <li>
                                <a class="fa fa-power-off" href="{{ route('logout') }}"
                                   onclick="event.preventDefault();
                                                     document.getElementById('logout-form').submit();">
                                    Выход
                                </a>

                                <form id="logout-form" action="{{ route('logout') }}" method="POST" style="display: none;">
                                    @csrf
                                </form>
                            </li>
                        </ul>
                    </div>
                </li>
            </ul>
        </div>
    </nav>
</div>

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

Здесь из новенького встречается использование Laravel helper url, который используется для формирования абсолютных ссылок, но, в отличие от asset, как вы знаете, его можно использовать только для url, но никак не для ссылок на статические файлы, хотя технически ничего этому не мешает 🙂

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

А также здесь интересна появившаяся в Laravel 5.6 Blade директива csrf, после обработки которой в итоговый HTML код страницы на форму, внутри которой он присутствует, добавляется поле с генерируемым CSRF токеном.

В предыдущих версиях Laravel для данной цели использовался хэлпер csrf_field.

sidebar.blade.php — сайдбар страницы:

<div class="left-sidebar">
    <div class="scroll-sidebar">
        <nav class="sidebar-nav">
            <ul id="sidebarnav">
                <li class="nav-devider"></li>
                <li> <a class="has-arrow" href="#" aria-expanded="false"><i class="fa fa-wpforms"></i><span class="hide-menu">Блог</span></a>
                    <ul aria-expanded="false" class="collapse">
                        <li><a href="{{ url('admin') }}">Список статей</a></li>
                        <li><a href="{{ url('admin/articles/create') }}">Создать статью</a></li>
                    </ul>
                </li>
            </ul>
        </nav>
    </div>
</div>

footer.blade.php — футер страницы:

<footer class="footer"><a href="https://github.com/puikinsh/ElaAdmin">Ela Admin</a> © 2018 All rights reserved.</footer>

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

scripts.blade.php — подключение JS-скриптов:

<script src="{{ asset('/admin/js/lib/jquery/jquery.min.js') }}"></script>
<script src="{{ asset('/admin/js/lib/bootstrap/js/popper.min.js') }}"></script>
<script src="{{ asset('/admin/js/lib/bootstrap/js/bootstrap.min.js') }}"></script>
<script src="{{ asset('/admin/js/jquery.slimscroll.js') }}"></script>
<script src="{{ asset('/admin/js/sidebarmenu.js') }}"></script>
<script src="{{ asset('/admin/js/lib/sticky-kit-master/dist/sticky-kit.min.js') }}"></script>
<script src="{{ asset('/admin/js/scripts.js') }}"></script>

@stack('custom_scripts')

Сам же файл главного шаблона _layout.blade.php принял такой вид:

<!DOCTYPE html>
<html lang="en">

@include('admin.layouts.htmlhead')

<body class="fix-header fix-sidebar">
    <div class="preloader">
        <svg class="circular" viewBox="25 25 50 50">
			<circle class="path" cx="50" cy="50" r="20" fill="none" stroke-width="2" stroke-miterlimit="10" /> </svg>
    </div>
    
    <div id="main-wrapper">        
        @include('admin.layouts.header')        
        @include('admin.layouts.sidebar')
        
        <div class="page-wrapper">            
            @yield('breadcrumbs')            
            @yield('content')
            
            @include('admin.layouts.footer')
        </div>
    </div>
    
    @include('admin.layouts.scripts')

</body>
</html>

Как видите, в нём описана структура будущих страниц: фрагменты повторяемого кода подключены с помощью Blade-директив include, а для тех частей, которые будут уникальными, зарезервированы места с помощью yield — в принципе, ничего сложного 🙂

Наследоваться данный шаблон в Blade-файлах остальных страниц нашей Laravel админки будет с помощью директивы extends, а код, подставляемый в зарезервированные с помощью yield места, будет добавляться благодаря section.

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

@extends('admin.layouts._layout')

@push('custom_styles')
    <link rel="stylesheet" href="/admin/css/lib/summernote/summernote-bs4.css" />
@endpush

@push('custom_scripts')
    <script src="/admin/js/lib/summernote/summernote-bs4.js"></script>
    <script src="/admin/js/lib/summernote/lang/summernote-ru-RU.js"></script>
    
    <script type="text/javascript">
        $(document).ready(function() {
            $('.summernote').summernote({
                height: 300,
                lang: 'ru-RU'
            });
        });
    </script>
@endpush

@section('breadcrumbs')
<div class="row page-titles">
    <div class="col-md-5 align-self-center">
        <h3 class="text-primary">Создание статьи</h3> </div>
    <div class="col-md-7 align-self-center">
        <ol class="breadcrumb">
            <li class="breadcrumb-item"><a href="{{ url('/admin') }}">Админка</a></li>
            <li class="breadcrumb-item active">Создание статьи</li>
        </ol>
    </div>
</div>
@stop

@section('content')
<div class="container-fluid">
    <div class="row">
        <div class="col-lg-12">
            <div class="basic-form">
                <form method="POST" action="{{ url('articles/save') }}">
                    <div class="form-group">
                        <label for="slug" class="control-label">URL новости</label>
                        <input type="text" class="form-control input-default" id="slug" name="slug" placeholder="Введите url новости">
                    </div>
                    
                    <div class="form-group">
                        <label for="title" class="control-label">Заголовок новости</label>
                        <input type="text" class="form-control input-default" id="title" name="title" placeholder="Введите заголовок новости">
                    </div>
                    
                    <div class="form-group">
                        <label for="description" class="control-label">Текст новости</label>
                        <textarea class="summernote form-control" id="description" name="description" rows="15" placeholder="Введите текст статьи"></textarea>
                    </div>
                    
                    <div class="form-group">
                        <label for="preview" class="control-label">Превью новости</label>
                        <div class="custom-file">
                            <input type="file" class="custom-file-input" id="preview">
                            <label class="custom-file-label" for="preview">Выбрать</label>
                        </div>
                    </div>
                    
                    <input type="submit" class="btn btn-info float-lg-right" value="Сохранить">
                </form>
            </div>
        </div>
    </div>
</div>
@endsection

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

Имена секций кода в push и stack должны, естественно, совпадать.

Лично я использовал данные хэлперы для того, чтобы, как вы видите, подключить скрипты, необходимые для работы WYSIWYG редактора SummerNote, который я решил использовать вместо редактора Bootstrap wysihtml5, поставляемого с Ela Admin template по умолчанию и баганутого, к тому же 🙂

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

Это, по сути, единственная моя существенная доработка шаблона. Для формирования остальных страниц мне вполне хватило стандартных элементов.

Не знаю как вы, а я нашёл Laravel Blade директивы stack/push невероятно похожими по принципу работы на yield/section. Единственная разница данного набора директив от используемого в описанной выше ситуации, как по мне, заключается только в их смысловом назначении, т.е., если первые используются для HTML кусков, задающих структуру страницы, то вторые нужны исключительно для интеграции различных фрагментов скриптов…

Тонкая грань, если честно. Но фанатам Laravel к данным ситуациям не привыкать 🙂 Одни только Laravel хэлперы asset и url чего стоят 🙂

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

<!DOCTYPE html>
<html lang="ru">
    
    @include('admin.layouts.htmlhead')
    
    <body class="fix-header fix-sidebar">
        <div class="preloader">
            <svg class="circular" viewBox="25 25 50 50">
            <circle class="path" cx="50" cy="50" r="20" fill="none" stroke-width="2" stroke-miterlimit="10" /> </svg>
        </div>
        <div id="main-wrapper">

            <div class="unix-login">
                <div class="container-fluid">
                    <div class="row justify-content-center">
                        <div class="col-lg-4">
                            <div class="login-content card">
                                <div class="login-form">
                                    <h4>Laravel Ela Admin</h4>
                                    <form method="POST" action="{{ route('login') }}">
                                        @csrf
                                        
                                        <div class="form-group">
                                            <label>Логин</label>
                                            <input type="text" id="login" class="form-control{{ $errors->has('login') ? ' is-invalid' : '' }}" name="login" value="{{ old('login') }}" placeholder="Логин" required autofocus>
                                            @if ($errors->has('login'))
                                                <span class="invalid-feedback">
                                                    <strong>{{ $errors->first('login') }}</strong>
                                                </span>
                                            @endif
                                        </div>
                                        <div class="form-group">
                                            <label>Пароль</label>
                                            <input id="password" type="password" class="form-control{{ $errors->has('password') ? ' is-invalid' : '' }}" placeholder="Пароль" name="password" required>
                                            @if ($errors->has('password'))
                                                <span class="invalid-feedback">
                                                    <strong>{{ $errors->first('password') }}</strong>
                                                </span>
                                            @endif
                                        </div>
                                        <div class="checkbox">
                                            <label>
                                                <input id="remember" type="checkbox" name="remember" {{ old('remember') ? 'checked' : '' }}> Запомнить
                                            </label>
                                        </div>
                                        <button type="submit" class="btn btn-primary btn-flat m-b-30 m-t-30">Войти</button>
                                    </form>
                                </div>
                            </div>
                        </div>
                    </div>
                </div>
            </div>

        </div>
        
        @include('admin.layouts.scripts')
        
    </body>
</html>

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

На этом самый, пожалуй, долгий и трудоёмкий этап установки шаблона Laravel custom admin panel в Laravel приложение завершён.

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

4. Перенос файлов статики шаблона в Laravel приложение

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

На данном этапе создания своей Laravel custom admin panel я решил не заморачиваться сборкой статики через Webpack, Gulp и прочие либы, а просто скопировал статические файлы в свой проект, рассортировав их по следующим директориям:

  • JS скрипты: /public/admin/js
  • CSS скрипты: /public/admin/css
  • Файлы изображений: /public/admin/images
  • Иконочные шрифты: /public/admin/icons

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

А также я хочу наладить сборку и минификацию статики через библиотеки-сборщики, самым прогрессивным из которых сегодня является Webpack. Но, поскольку для Laravel есть свой Webpack wrapper под названием Laravel Mix, то я буду использовать его, попутно знакомя вас с его API и возможностями, о чём я уже и говорил в самом начале статьи.

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

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

5. Формирование роутов и actions контроллеров

На данном этапе у нас всё готово: вёрстку админки мы в приложение перенесли, а также расширили её Blade директивами и Laravel хэлперами, а также скопировали всю необходимую статику.

В принципе, теперь на всё это можно смотреть в браузере и наслаждаться 🙂 Вопрос только — как? Как получить доступ ко всей нашей готовой красоте?

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

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

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

Для этого заходим в код контроллера /app/Http/Controllers/Auth/LoginController.php и переопределяем стандартный метод showLoginForm(), который как раз ответственен за отображение страницы логина, следующим образом:

public function showLoginForm()
{
    return view('admin.login');
}

Данный код обозначает, что в качестве страницы входа в систему будет использоваться содержимого Blade файла по пути /resources/views/admin/login.blade.php. Если у вас файл с формой входа в админку будет располагаться в другом месте, то, естественно, данный метод должен будет содержать другой путь (надеюсь, что по аналогии вы пропишите требуемый, иначе пишите о своих проблемах в комментариях).

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

В качестве стартового экрана я решил сделать страницу со списком постов. Поэтому для реализации текущей концепции своей Laravel custom admin panel я решил ограничиться одним контроллером /app/Http/Controllers/Admin/BlogController.php и двумя его методами для каждой из страниц, которые выглядят вот так:

<?php
namespace App\Http\Controllers\Admin;
use App\Http\Controllers\Controller;
use Request;
class BlogController extends Controller
{
    public function all()
    {
        $data = [];
        return view('admin.blog.list', ['posts' => $data]);
    }
    
    public function create()
    {
        return view('admin.blog.single');
    }
}

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

Route::middleware('auth')->namespace('Admin')->prefix('/admin')->group(function(){
    Route::get('/', 'BlogController@all');
    Route::prefix('/articles')->group(function(){
        Route::get('/', 'BlogController@all');
        Route::get('/create', 'BlogController@create');
    });
});

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

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

  • /admin и /admin/articles, при переходе на которые будет выполняться метод контроллера /app/Http/Controllers/Admin/BlogController.php под названием all();
  • /admin/articles/create, при переходе на которые будет выполняться метод контроллера /app/Http/Controllers/Admin/BlogController.php под названием create().

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

После создания Laravel routes и соответствующих методов контроллеров в своём приложении сайт готов к использованию. Для перехода в админку достаточно просто ввести в адресной строке браузера следующий адрес: http://доменное_имя_сайта/admin, и вашему взору откроется ваша супер-мега-классная Laravel custom admin control panel, которую мы с вами дружно сделали в ходе данной статьи.

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

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

Разочаровался, т.к. нашёл достаточно много багов. Одним из таких выступило поведение стандартного компонента File Browser (используется для добавление файлов на HTML форму), который после загрузки файла не показывает имя файла.

И больше всего в данной ситуации задражало то, что сами разработчики Bootstrap считают данный баг фичей (классика программирования 🙂 ), о чём и пишут в официальной документации, рекомендуя для такого достаточно тривиально действия, как отображение имени файла после его загрузки, подключать кастомный JavaScript код. Причём какой именно — не говорится 🙂

В общем, если кто-то столкнётся с похожей ситуацией, и вы захотите, чтобы при использовании компонента Bootstrap4 File Browser у вас в нём показывалось имя загружаемого файла, то просто добавьте на страницу либо в JS файл, подключаемый на этой странице, следующий JavaScript код:

$('.custom-file-input').on('change', function() { 
   let fileName = $(this).val().split('\\').pop(); 
   $(this).next('.custom-file-label').addClass("selected").html(fileName); 
});

При этом сам File Browser на странице вашего сайта должен быть оформлен следующим HTML кодом:

<div class="custom-file">
   <input id="logo" type="file" class="custom-file-input">
   <label for="logo" class="custom-file-label text-truncate">Choose file...</label>
</div>

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

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

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

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

Следующим этапом будет сборка статики через Laravel Mix или долгожданная работа с БД в Laravel приложении — я пока не определился 🙂 Пишите в комментах, чего больше ждёте. Возможно, мне поможет это в расстановке приоритетов 🙂

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

Laravel logging error: разбираемся с ошибкой логгирования

laravel-logging-errorВсем привет! 🙂

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

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

С одной из таких я совсем недавно столкнулся во время мониторинга логов одного из своих Laravel сайтов. Выглядела она следующим образом:

[2018-05-27 18:25:28] laravel.EMERGENCY: Unable to create configured logger. Using emergency logger. {"exception":"[object] (InvalidArgumentException(code: 0): Log [] is not defined. at C:\\OSPanel\\domains\\laravel.portfolio\\vendor\\laravel\\framework\\src\\Illuminate\\Log\\LogManager.php:181)
[stacktrace]

... Длинный-длинный листинг запросов, которые предшествовали возникновению ошибки ...

Причём, такая вот борода была после каждого логгируемого сообщения, генерируемого в коде Laravel приложения.

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

Я бы, наверное, и не заподозрил бы ничего неладного, если бы однажды не обратил внимание на размер файла логов Laravel, который превышал 200 мегабайт.

Кстати, если вдруг вы до сих пор не понимаете, о чём сейчас идёт речь, и где искать файлы логов Laravel приложения, то вам нужен файл storage\logs\laravel.log, который можно открыть в обычном текстовом редакторе (лучше всего использовать стандартный Блокнот, потому что IDE-шка может загнуться, если размер файла будет очень большим).

Хотя, если вы либо кто-то другой до вас серьёзно занимался настройкой Laravel logging system, то вместо данного единого файла у вас может быть несколько, как с другим названием, так и с другим местоположением.

Но сегодня разговор будет не о том, как это сделать, а о том, как побороть Laravel logging error, описанную выше.

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

Правда, в процессе Laravel update я не придал значение появившемуся в Laravel 5.6 конфигу logging.php, который был добавлен в фреймворк в связи с усовершенствованием системы логгирования.

Как раз-таки из-за отсутствия данного конфига в моём приложении и возникала указанная Laravel logging error.

Поэтому, первым делом я добавил файл config\logging.php в свой проект со следующим содержимым:

<?php
use Monolog\Handler\StreamHandler;
return [
    /*
    |--------------------------------------------------------------------------
    | Default Log Channel
    |--------------------------------------------------------------------------
    |
    | This option defines the default log channel that gets used when writing
    | messages to the logs. The name specified in this option should match
    | one of the channels defined in the "channels" configuration array.
    |
    */
    'default' => env('LOG_CHANNEL', 'stack'),
    /*
    |--------------------------------------------------------------------------
    | Log Channels
    |--------------------------------------------------------------------------
    |
    | Here you may configure the log channels for your application. Out of
    | the box, Laravel uses the Monolog PHP logging library. This gives
    | you a variety of powerful log handlers / formatters to utilize.
    |
    | Available Drivers: "single", "daily", "slack", "syslog",
    |                    "errorlog", "monolog",
    |                    "custom", "stack"
    |
    */
    'channels' => [
        'stack' => [
            'driver' => 'stack',
            'channels' => ['single'],
        ],
        'single' => [
            'driver' => 'single',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
        ],
        'daily' => [
            'driver' => 'daily',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
            'days' => 7,
        ],
        'slack' => [
            'driver' => 'slack',
            'url' => env('LOG_SLACK_WEBHOOK_URL'),
            'username' => 'Laravel Log',
            'emoji' => ':boom:',
            'level' => 'critical',
        ],
        'stderr' => [
            'driver' => 'monolog',
            'handler' => StreamHandler::class,
            'with' => [
                'stream' => 'php://stderr',
            ],
        ],
        'syslog' => [
            'driver' => 'syslog',
            'level' => 'debug',
        ],
        'errorlog' => [
            'driver' => 'errorlog',
            'level' => 'debug',
        ],
    ],
];

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

Ну, и следующим шагом моей запоздалой настройки системы логгирования, недостатки которой приводили к упомянутой Laravel logging error, стала коррекция файла настроек окружения .env.

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

APP_LOG_LEVEL=debug

Вместо него добавляем в конфиг окружения следующий:

LOG_CHANNEL=stack

В самом сэпле .env у Laravel 5.6 он располагается под APP_URL.

Вот и всё. После этого ошибка логгирования Laravel у меня исчезла из laravel.log, облегчив его, тем самым, процентов на 80.

А это, нужно сказать, весьма существенно. В моём случае, при размере файла в 200 Мб данное обстоятельство не было критичным, но при возникновении данной Laravel logging error в production окружении может привести к тому, что ваш файл логов банально съест всё дисковое пространство сервера, и ваш сайт приляжет отдохнуть.

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

Какова мораль всей этой истории и чему она меня научила?

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

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

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

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

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

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

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

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

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

Если вы столкнётесь с другими Laravel logging error — милости прошу делиться ими в комментариях, чтобы сообща докопаться до причины и решить её. А, возможно, это поможет вам навсегда вписать своё имя в историю Laravel framework, т.к. результатом решения фейла станет pull request в репозитории проекта на GitHub, кто знает…

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

Всем добра и до новых встреч 😉

Laravel база данных: настраиваем соединение

laravel-databaseВсем хэллоу! 🙂

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

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

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

Причём, первую минуту я создавал саму базу, а половину второй размышлял, какую СУБД всё-таки выбрать 🙂 Остальным же 30 секундам и будет посвящена дальнейшая информация, которой, как вы понимаете, сегодня много не будет.

Laravel DB connection: какие СУБД поддерживаются?

Из коробки Laravel позволяет использовать следующие реляционные СУБД:

  • MySQL
  • PostgreSQL
  • SQLite
  • SQL Server

Также Laravel поддерживает NoSQL СУБД Redis, который зачастую используют для хранения кэшированных данных благодаря высокой скорости записи и извлечения данных из неё, поэтому о настройках соединения с ним поговорим чуть позже, когда разговор дойдёт до описания методов работы с серверным кешом сайта.

Настройки соединения с Laravel database: способ первый

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

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

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

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

Так выглядит она по умолчанию, т.е. непосредственно после установки Laravel на сервер. Как видите по значением параметров конфигурации соединения, разработчики Laravel предполагают использование MySQL в качестве СУБД по умолчанию и Laravel Homestead для локальной разработки.

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

DB_CONNECTION — СУБД, которая будет использоваться для управления базой данных.
DB_HOST — адрес сервера БД. При локальной разработке (с использованием локального веб-сервера) в 90% случаев он будет таким, как по умолчанию — 127.0.0.1.
DB_PORT — номер сетевого порта, через который будет происходить соединение с сервером базы данных. Если вы не указывали его явно при настройке СУБД на сервере, то для MySQL по умолчанию он будет 3306, как и в примере выше, для PostgeSQL5432, для остальных поддерживаемых Laravel DB нужно смотреть, наизусть не помню 🙂
DB_DATABASE — собственно, имя базы данных, которая будет использоваться для хранения информации Laravel приложения.
DB_USERNAME — имя пользователя СУБД для доступа к данным, хранимым в БД. Пользователей, естественно, у вас может быть несколько, причём каждый из них может обладать своим набором прав. Действия по манимуляции юзеров из консоли MySQL описаны в статье по ссылке в начале данной публикации.
DB_PASSWORD — пароль пользователя СУБД для подключения к database из Laravel приложения.

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

Конфигурация соединения с Laravel базой данных: способ второй

Первый способ настройки связи сайта на Laravel с БД мы рассмотрели. Кроме него существует вариант расширенной конфигурации через файл корень_сайта\config\database.php.

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

'default' => env('DB_CONNECTION', 'mysql'),

Параметр default содержит название соединения (по умолчанию имеют названия, созвучные используемым СУБД), которое будет применяться по умолчанию для всех баз. Как видите, значение переменной берётся из .env DB_CONNECTION. Если она не будет указана, то используется mysql. Вы сами можете прописать жёстко значение, какое посчитаете нужным.

Под названием соединения, указываемого в параметре default, имеются ввиду элементы массива connections, который описан немного ниже:

'connections' => [
    'sqlite' => [
        'driver' => 'sqlite',
        'database' => env('DB_DATABASE', database_path('database.sqlite')),
        'prefix' => '',
    ],
    'mysql' => [
        'driver' => 'mysql',
        'host' => env('DB_HOST', '127.0.0.1'),
        'port' => env('DB_PORT', '3306'),
        'database' => env('DB_DATABASE', 'forge'),
        'username' => env('DB_USERNAME', 'forge'),
        'password' => env('DB_PASSWORD', ''),
        'unix_socket' => env('DB_SOCKET', ''),
        'charset' => 'utf8mb4',
        'collation' => 'utf8mb4_unicode_ci',
        'prefix' => '',
        'strict' => true,
        'engine' => null,
    ],
    'pgsql' => [
        'driver' => 'pgsql',
        'host' => env('DB_HOST', '127.0.0.1'),
        'port' => env('DB_PORT', '5432'),
        'database' => env('DB_DATABASE', 'forge'),
        'username' => env('DB_USERNAME', 'forge'),
        'password' => env('DB_PASSWORD', ''),
        'charset' => 'utf8',
        'prefix' => '',
        'schema' => 'public',
        'sslmode' => 'prefer',
    ],
    'sqlsrv' => [
        'driver' => 'sqlsrv',
        'host' => env('DB_HOST', 'localhost'),
        'port' => env('DB_PORT', '1433'),
        'database' => env('DB_DATABASE', 'forge'),
        'username' => env('DB_USERNAME', 'forge'),
        'password' => env('DB_PASSWORD', ''),
        'charset' => 'utf8',
        'prefix' => '',
    ],
],

Здесь, как вы видите, содержатся как раз настройки подключения к серверу Laravel базы данных, разбитые на разные секции, которые создатели Laravel нарекли «подключениями» для каждой из поддерживаемых фреймворком СУБД, которые были перечислены в начале статьи.

Думаю, какое подключение какой СУБД соответствует, пояснять не нужно. Значения многим параметрам, как вы видите, можно задавать в файле .env. Некоторых используемых в данном файле переменных, кстати, даже нет в .env по умолчанию (например, DB_SOCKET из секции настроек MySQL соединения), наверное, из-за отсутствия необходимости их использования в большинстве случаев.

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

DB_DATABASE=/абсолютный/путь/к/database.sqlite

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

По поводу данного блока настроек, есть ещё один нюанс… Он заключается в том, что код Laravel взаимодействует с базами данных через методы PHP PDO. А в данном блоке настроек у каждого массива сеттингов соединения с определённой СУБД есть параметр driver, значения которого соответствуют PHP PDO драйверам, которые должны быть установлены на вашем сервере для успешного взаимодействия с Laravel БД.

Поэтому, если вы указали все параметры соединения с Laravel DB верно, но фреймворк выдаёт ошибку соединения, скорее всего, проблема именно в драйвере PDO. Поставьте необходимый для вашей СУБД и проверьте его подключение в файле конфигурации php.ini. Нужно, чтобы он не был закомментирован:

;extension=php_pdo_firebird.dll

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

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

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

Настройки чтения и записи для одной Laravel БД

Иногда в процессе разработки появляется необходимость использовать одно подключение к БД для чтения информации (выполнять SELECT запросы), а другое — для модификации данных (INSERT, UPDATE и DELETE запросы). Laravel позволяет сделать данное разграничение легко и быстро на уровне рассматриваемого нами конфига database.php.

При этом необходимые вам соединения будут использоваться при отправке чистых (raw) запросов к БД, а также при использовании конструктора запросов Laravel (query builder) и Eloquent ORM.

Для разграничения сеттингов чтения и записи в настройки соединения с необходимой СУБД нужно добавить секции read и write в следующем формате:

'mysql' => [
    'read' => [
        'host' => ['192.168.1.1'],
    ],
    'write' => [
        'host' => ['196.168.1.2'],
    ],
    'sticky'    => true,
    'driver'    => 'mysql',
    'database'  => 'database',
    'username'  => 'root',
    'password'  => '',
    'charset' => 'utf8mb4',
    'collation' => 'utf8mb4_unicode_ci',
    'prefix'    => '',
],

Пример выше взят из официальной документации Laravel по работе с БД и подразумевает, что база данных находится на нескольких серверах (репликах), т.е. разделение настроек соединения с БД может быть полезно при репликации данных, что на Highload проектах встречается достаточно часто, но при запуске стартапов (если они не будут сразу проектироваться под высокие нагрузки, конечно) вы с этим не скоро столкнётесь 🙂

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

'mysql' => [
    'read' => [
        'username'  => 'user1',
        'password'  => 'secret'
    ],
    'write' => [
        'username'  => 'user2',
        'password'  => 'secret'
    ],
    'host' => '127.0.0.1',
    'sticky'    => true,
    'driver'    => 'mysql',
    'database'  => 'database',
    'charset' => 'utf8mb4',
    'collation' => 'utf8mb4_unicode_ci',
    'prefix'    => '',
],

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

Конфигурация Laravel базы данных: опция sticky

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

Данный параметр не является обязательным и может использоваться в случаях, когда нужно будет организовать немедленное чтение записей, которые были записаны в Laravel БД в рамках текущего запроса или цикла запросов. Принимает булевские значения, т.е. true/false.

Если sticky имеет значение true, и в рамках текущего цикла запроса была выполнена операция записи данных в БД, то любая операция чтения данных будет использовать write соединение.

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

Работа с несколькими Laravel DB

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

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

$users = DB::connection('mysql')->select('select * from users');

Имя используемого соединения с БД должно соответствовать одному из соединений, описанных в конфиге config\database.php.

Также вы можете получить чистый объект PHP PDO для произведения дальнейших действий с БД с помощью метода getPdo() следующим образом:

$pdo = DB::connection('pgsql')->getPdo();

Laravel database: выводы по поводу настроек связи

Вот мы с вами и рассмотрели основные настройки соединения Laravel c базой данных, которые, как выяснилось, могут быть указаны двумя способами: через главный конфиг config/database.php и через файл настроек окружения .env, расположенном в корне приложения.

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

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

Конфиг же config\database.php в репозиторий записывается, поэтому в нём необходимо указывать лишь общие для всех окружений настройки. Обратите на это, пожалуйста, особое внимание.

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

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

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

Laravel аутентификация: установка и использование в проекте

laravel-authПриветствую вас, друзья! 🙂

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

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

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

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

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

Поэтому данная статья будет посвящена Laravel auth (сокращённо от «authentication» — аутентификация), а точнее, её установке и настройке. Также я расскажу об основных методах фасада Laravel Auth и покажу, как их можно кастомизировать.

Поехали! 🙂

Работа с Laravel auth: начальные условия

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

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

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

Инструкции по Laravel version update вы можете найти в статье по ссылке выше.

И ещё одно уточнение. Описанный в сегодняшней статье механизм называется именно аутентификацией, а не авторизацией, которые все постоянно путают, включая меня самого 🙂 Как говорит всемогущая Википедия, аутентификация — это процедура проверки легальности данных или пользователя путём сверки предоставляемой информации с неким оригиналом (записи в БД или проверки цифровой подписи по ключу шифрования).

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

Как по мне, грань достаточно тонкая, но Laravel чётко разделяет эти понятия путём вынесения методов аутентификации в фасад Laravel Auth, который будет рассмотрен сегодня, а функции авторизации доступны через Laravel Gate facade.

Laravel регистрация пользователей и их аутентификация: установка

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

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

php artisan make:auth

Если всё прошло успешно, то вы увидите в консоли сообщение Authentication scaffolding generated successfully.

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

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

Для этого в Laravel по умолчанию есть базовые миграции для создания таблицы пользователей (по умолчанию называется users) и таблицы для хранения попыток сброса паролей (password_resets), которые расположены в каталоге корень_сайта\database\migrations и носят следующие названия:

  • 2014_10_12_000000_create_users_table.php
  • 2014_10_12_100000_create_password_resets_table.php

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

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

<?php

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('users', function (Blueprint $table) {
            $table->increments('id');
            $table->string('login')->unique();
            $table->string('email')->unique();
            $table->string('password');
            $table->rememberToken();
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('users');
    }
}

К числу дополнительных приготовлений также относится подготовка Laravel seeder для добавления в БД данных администратора. С этой целью я откорректировал базовый файл по пути корень_сайта\database\seeds\DatabaseSeeder.php следующим образом:

<?php

use Illuminate\Database\Seeder;

class DatabaseSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        DB::table('users')->insert([
            'login' => 'admin',
            'email' => 'admin@gmail.com',
            'password' => bcrypt('admin'),
            'created_at' => date('Y-m-d H:i:s'),
            'updated_at' => date('Y-m-d H:i:s'),
        ]);
    }
}

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

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

После этого всё, что осталось для того, чтобы создать таблицу в базе данных и наполнить её данными, — это запустить следующую Laravel artisan команду:

php artisan migrate --seed

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

Описанные выше действия были актуальны для запуска Laravel проекта с нуля, когда у вас нет ещё ни БД, ни пользователей.

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

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

По поводу структуры таблицы БД с данными пользователей, сами разработчики Laravel в официальной документации дают рекомендации использовать для хранения пароля строковый тип поля длиной не менее 60 символов и добавить в таблицу поле remember_token длиной в 100 символов (тип, естественно, строковый) и со значением NULL по умолчанию.

Последнее необходимо будет для длительного хранения сессии пользователя и восстановлении сеанса при повторном входе на сайт.

Laravel аутентификация: настройка

Итак, после того, как мы добавили необходимые для Laravel auth файлы в наш проект и создали таблицу для хранения пользователей, осталось только всё это дело связать, т.е. указать фреймворку, в какой именно таблице следует искать Laravel auth user данные при его аутентификации на сайте.

Чтобы это сделать, нужно заглянуть в соответствующий Laravel config файл (или конфиг, по-русски), в котором описаны все необходимые настройки, необходимые при настройке authentication — корень_сайта\config\auth.php. Данный файл, как и контроллеры, доступен в Laravel приложении также по умолчанию.

Он состоит из секций, описывающих guards (гвард) и providers (провайдер) для произведения Laravel user auth. Первые определяют действия, которые происходят в процессе аутентификации, а вторые — где хранятся данные пользователей.

По умолчанию в Laravel auth provider один — users, который выглядит так:


...

'providers' => [
    'users' => [
        'driver' => 'eloquent',
        'model' => App\User::class,
    ],

    // 'users' => [
    //     'driver' => 'database',
    //     'table' => 'users',
    // ],
],

...

Как видите, здесь представлены параметры, с помощью которых можно указать в качестве источника данных как имя таблицы БД, так и модель. По умолчанию указана дефолтная модель User, расположенная в файле корень_сайта\app\User.php и использующая в качестве источника таблицу БД users.

Если же таблица с данными пользователей у вас называется по-другому, то вам необходимо в данной секции конфига прописать свою модель или таблицу БД, выбрав необходимый драйвер — eloquent для использования модели или database для таблиц БД.

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

Секция настроек для конфигурирования guards выглядит же следующим образом:

'guards' => [
    'web' => [
        'driver' => 'session',
        'provider' => 'users',
    ],

    'api' => [
        'driver' => 'token',
        'provider' => 'users',
    ],
],

Laravel auth guards, доступные по умолчанию, имеют названия созвучные их областям применения. Web подходит для большинства стандартных сайтов, т.к. для аутентификации пользователей используются данные, хранящиеся в сессии на сервере (физически они могут быть оформлены как в виде файлов, так и таблицы в БД, но Laravel session будет посвящен отдельный разговор).

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

Драйвера для guards, задающие способ аутентификации, бывают двух типов: session и token, принцип работы которых был описан выше. Также для Laravel auth guards можно указывать providers, чтобы разграничивать хранилища данных для каждого гварда. В качестве провайдера указываются структуры, описанные в секции providers этого же конфига auth.php.

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

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

'passwords' => [
    'users' => [
        'provider' => 'users',
        'table' => 'password_resets',
        'expire' => 60,
    ],
],

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

Параметр expire позволяет указать время существования токена сброса. Другими словами, определяет время, в течении которого пользователь может сбросить свой пароль после оставления им заявки, при которой reset token и генерируется.

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

'defaults' => [
    'guard' => 'web',
    'passwords' => 'users',
],

Здесь указан дефолтный гвард и блок настроек для сброса пароля.

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

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

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

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

Кастомизация Laravel auth методов

После запуска Laravel artisan команды make:auth ваш проект был расширен следующими файлами (спасибо Git, что он есть и позволяет определять данные изменения), которые были скопированы из недр Laravel framework:

  • app\Http\Controllers\HomeController.php
  • resources\views\auth\login.blade.php
  • resources\views\auth\passwords\email.blade.php
  • resources\views\auth\passwords\reset.blade.php
  • resources\views\auth\register.blade.php
  • resources\views\home.blade.php
  • resources\views\layouts\app.blade.php

А также был обновлён файл маршрутизации (со списком Laravel routes, они же — правила маршрутизации или маршруты) routes\web.php, в который добавились следующие строчки:

Auth::routes();

Route::get('/home', 'HomeController@index')->name('home');

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

/**
 * Роуты аутентификации...
 */

//отображение формы аутентификации
Route::get('login', 'Auth\LoginController@showLoginForm')->name('login');
//POST запрос аутентификации на сайте
Route::post('login', 'Auth\LoginController@login');
//POST запрос на выход из системы (логаут)
Route::post('logout', 'Auth\LoginController@logout')->name('logout');

/**
 * Маршруты регистрации...
 */

//страница с формой Laravel регистрации пользователей
Route::get('register', 'Auth\RegisterController@showRegistrationForm')->name('register');
//POST запрос регистрации на сайте
Route::post('register', 'Auth\RegisterController@register');

/**
 * URL для сброса пароля...
 */

//POST запрос для отправки email письма пользователю для сброса пароля
Route::post('password/email', 'Auth\ForgotPasswordController@sendResetLinkEmail')->name('password.email');
//ссылка для сброса пароля (можно размещать в письме)
Route::get('password/reset', 'Auth\ForgotPasswordController@showLinkRequestForm')->name('password.request');
//страница с формой для сброса пароля
Route::get('password/reset/{token}', 'Auth\ResetPasswordController@showResetForm')->name('password.reset');
//POST запрос для сброса старого и установки нового пароля
Route::post('password/reset', 'Auth\ResetPasswordController@reset');

HTTP POST запросы отправляются, как правило, через HTML формы, поэтому, если по какой-то причине вы не знаете, как это делать, то эта статья как раз для вас.

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

В таком случае вам нужно будет просто удалить Auth::routes(); из routes\web.php, а вместо этого добавить в файл только те роуты, которые вам будут необходимы.

Таким же образом вы сможете изменить название самого Laravel auth url (маршрут) и его обработчик.

Если присмотреться к Laravel auth routes, то заметно, что для данных стандартных маршрутов аутентификации уже существуют и указаны не менее стандартные обработчики, которыми являются контроллеры из директории корень_сайта\app\Http\Controllers\Auth.

Данный каталог же находится в Laravel приложении по указанному пути сразу после установки фреймворка на ПК. Честно говоря не понимаю, почему разработчики Laravel не сделают его создание после выполнения консольной команды make:auth, которая переносит в приложение роуты Laravel аутентификации и другие необходимые файлы.

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

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

Например, судя по роутам, в файле app\Http\Controllers\Auth\LoginController.php должно быть три метода:

  • showLoginForm();
  • login();
  • logout();

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

public function showLoginForm()
{
    return 'Успех! Сработал мой кастомный обработчик маршрута http://site.com/login';
}

И, собственно говоря, результат в браузере:

laravel-auth-zaglushka

Если же всё оставить на своих местах, т.е. не писать кастомный обработчик, то при вводе URL в формате http://site.com/login на экране браузера вы увидите стандартную форму входа, файл которой был добавлены в приложение при запуске Artisan команды make:auth.

Данным файлом является resources\views\auth\login.blade.php. Решил уточнить на случай, если вы захотите её использовать в дальнейшем либо вам могут понадобиться какие-то её элементы для конструирования собственной.

У меня, правда, она выглядит совсем неказисто за счёт того, что использует стили и скрипты из стандартных статических файлов Laravel public\css\app.css и public\js\app.js соответственно, которые я уже давно и благополучно удалил 🙂

В итоге, выглядела она у меня так:

laravel-avtorizaciya-forma

Поэтому, если у вас форма логина выглядит похожим образом, держу в курсе, что это проблемы со стилями, точнее с их отсутствием по указанным в шаблоне путям. Так что, если вы действительно дорожите данной стандартной формой логина, то укажите правильные пути в файле resources\views\layouts\app.blade.php.

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

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

Для примера возьмём метод, который мы только что переопределяли — http://site.com/login.

При отсутствующем кастомном обработчике по умолчанию при переходе на данный URL в браузере выполняется метод showLoginForm() из файла по пути директория_сайта\vendor\laravel\framework\src\Illuminate\Foundation\Auth\AuthenticatesUsers.php, который выглядит следующим образом:

/**
 * Show the application's login form.
 *
 * @return \Illuminate\Http\Response
 */
public function showLoginForm()
{
   return view('auth.login');
}

Как видите, он как раз и ответственен за вывод на экран страницы с auth формой, код которой и хранится в уже упоминаемом нами файле resources\views\auth\login.blade.php.

Почему же при создании кастомного обработчика в контроллере LoginController.php он начинает вызываться вместо того, что указан выше? Всё просто. Приведённый выше метод является оригинальным методом core-класса фреймворка Laravel.

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

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

Если заглянуть в код файла Auth\LoginController.php, то в самом верху можно увидеть следующую строку, благодаря которой становится возможным использование кастомных врапперов:

use Illuminate\Foundation\Auth\AuthenticatesUsers;

Такая же строка присутствует во всех стандартных контроллерах из каталога app\Http\Controllers\Auth, которые являются наследниками базовых классов Laravel регистрации и аутентификации пользователей, благодаря чему в них можно описывать wrappers для всех public методов стандартных классов (найти их можно поиском по папке vendor, указывая имена методов из числа тех, что были приведены в начале статьи).

И по этому поводу держите ещё один лайфхак, связанный с кастомизацией Laravel auth методов 🙂

Если вы захотите переопределить базовые методы либо продублировать их, то достаточно создать контроллер и использовать в нём trait AuthenticatesUsers тем же способом, что был описан выше. Этот приём может быть полезен, если вам захочется сделать отдельные формы и механизмы Laravel аутентификации и регистрации для разных типов пользователей, которые будут храниться в разных таблицах БД.

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

Laravel аутентификация: практикум

О базовой установке, настройке и кастомизации Laravel регистрации и аутентификации я вам рассказал. Теперь пришло время поведать, как пользоваться Laravel auth.

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

Итак, что у нас есть на текущий момент?

Во-первых, форма логина, которая доступна по url http://site.com/login, и о которой я уже рассказывал и даже показывал 🙂

Кроме этого в мой проект добавилась форма Laravel регистрации, сброса пароля и тестовая страница, на которую редиректит после удачной аутентификации пользователя в системе и которая доступна по адресу http://site.com/home.

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

А также мне не нужен будет стандартный для Laravel сброс пароля.

Кроме того, мне не нужна тестовая страница, поэтому вместо неё я сделаю страницу-заглушку, которая будет доступна по адресу http://site.com/admin и на которую будет происходить редирект после удачной аутентификации. Также я хочу сделать редирект на страницу логина Laravel при выходе пользователя из системы (logout).

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

План действий составлен — за дело 🙂

Первым делом я удаляю Laravel Blade шаблоны страниц сброса пароля и регистрации, которые находятся в каталоге корень_сайта\resources\views\auth\passwords и файле корень_сайта\resources\views\auth\register.blade.php соответственно.

Теперь нужно удалить их роуты. Для этого я убираю в файле routes\web.php строку с обозначением стандартных Laravel роутов маршрутизации Auth::routes(); и заменяю её на одинарные правила маршрутизации для отображения формы логина, самого запроса на логин в системе и удаления сессии пользователя при logout:

//Кастомные правила маршрутизации
Route::get('login', 'Auth\LoginController@showLoginForm')->name('login');
Route::post('login', 'Auth\LoginController@login');
Route::post('logout', 'Auth\LoginController@logout');

После этого при переходе на страницу логина я получил следующую ошибку:

laravel-autentifikaciya-oshibka

Причина её заключается в том, что роут и шаблон формы регистрации я удалил, а вызов роута в коде приложения остался, поэтому для устранения ошибки необходимо удалить из файла корень_сайта\resources\views\auth\login.blade.php следующую строку:

<a class="btn btn-link" href="{{ route('password.request') }}">
    {{ __('Forgot Your Password?') }}
</a>

После этого подобная ошибка возникла снова, теперь уже из-за вызова в шаблоне Laravel auth формкорень_сайта\resources\views\layouts\app.blade.php роута регистрации, ссылку на который я тоже удалил:

<li><a class="nav-link" href="{{ route('register') }}">{{ __('Register') }}</a></li>

Вывод: если вы используете вызов именованных роутов в коде Laravel сайтов, то при удалении их из файла маршрутизации во избежание описанных фейлов не забывайте удалять ссылки на них в коде, особенно из blade-шаблонов, которые на этапе компиляции в обычный HTML код будут сыпать errors 🙂

После произведения вышеописанных действий при обращении к url http://site.com/register сайт стал отдавать 404 ошибку HTTP запроса, чего я и добивался.

Также попутно я удалил все контроллеры из каталога корень_сайта\app\Http\Controllers\Auth, оставив только LoginController.php, который по умолчанию содержит все необходимые для моего сайта роуты.

Следующим действием с Laravel auth стало изменения данных для аутентификации на сайте. Вместо email я решил логинить пользователя по его login.

Для этого я в контроллере корень_сайта\app\Http\Controllers\Auth\LoginController.php добавил следующую функцию, которая переопределяет стандартный метод username(), возвращающий название поля таблицы БД с пользователями, по которому нужно проверять юзеров на сайте:

public function username()
{
    return 'login';
}

Также вносим коррективы в файл формы входа, чтобы настроить поле email HTML формы для ввода в него логина. Для этого в login.blade.php меняем данный код:

<div class="form-group row">
    <label for="email" class="col-sm-4 col-form-label text-md-right">{{ __('E-Mail Address') }}</label>

    <div class="col-md-6">
        <input id="email" type="email" class="form-control{{ $errors->has('email') ? ' is-invalid' : '' }}" name="email" value="{{ old('email') }}" required autofocus>

        @if ($errors->has('email'))
        <span class="invalid-feedback">
            <strong>{{ $errors->first('email') }}</strong>
        </span>
        @endif
    </div>
</div>

На следующий:

<div class="form-group row">
    <label for="login" class="col-sm-4 col-form-label text-md-right">{{ __('Login') }}</label>

    <div class="col-md-6">
        <input id="login" class="form-control{{ $errors->has('login') ? ' is-invalid' : '' }}" name="login" value="{{ old('login') }}" required autofocus>

        @if ($errors->has('login'))
        <span class="invalid-feedback">
            <strong>{{ $errors->first('login') }}</strong>
        </span>
        @endif
    </div>
</div>

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

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

На английском языке этот механизм называется Login Throttling (дословно по-русски это звучит примерно как «подавление попыток аутентификации»), который в Laravel реализован кодом трейта Illuminate\Foundation\Auth\ThrottlesLogins, используемым по умолчанию в дефолтном контроллере Laravel аутентификации app\Http\Controllers\Auth\LoginController через используемый в нём trait Illuminate\Foundation\Auth\AuthenticatesUsers.

По умолчанию попытки входа блокируются на 1 минуту при вводе неверных кредов 5 раз подряд. Думаю, не стоит говорить, зачем Laravel Throttling нужен? Если всё таки не догадались — для блокирования попыток автоматического ввода данных пользователей с целью подбора реальных комбинаций для взлома сайта.

Блокировка уникальная для набора данных пользователя, состоящего из логина/email адреса и IP адреса, с которого происходит вход.

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

Идём дальше.

Следующим этапом является создание заглушки для админки, которую будут видеть прошедшие аутентификацию пользователи. Сделать я её решил на базе шаблона корень_сайта\resources\views\home.blade.php, который переименовал в admin.blade.php, внутри которого разместил следующий код:

@extends('layouts.app')

@section('content')
Добро пожаловать в админку, {{ Auth::user()->login }}
@endsection

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

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

Route::get('/home', 'HomeController@index')->name('home');

А стало таким:

Route::get('/admin', 'AdminController@index')->name('admin');

Также, вслед за роутом и шаблоном, я переименовал и контроллер с HomeController на AdminController. Код его я приводить не буду, т.к. он, за исключением имени класса и названия вызываемого в методе index() шаблона, не изменился.

И ещё, единственное, я решил удалить использование Laravel Middleware в контроллере и вынести его в файл маршрутизации. Для этого я удалил метод __construct() из контроллера AdminController, а для роутов админки создал группу в web.php, включив в неё пока что единственный маршрут для главной страницы админки:

Route::group(['middleware' => 'auth'], function(){
    Route::get('/admin', 'AdminController@index')->name('admin');
});

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

Здесь же, кстати, можно применять и создаваемые Laravel auth guards, указывая их следующим образом:

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

Или при указании Laravel auth middleware в контроллере можете использовать аналогичный вариант:

public function __construct()
{
    $this->middleware('auth:api');
}

Если описанное выше действие было субъективным и, в принципе, необязательным (я говорю о создании группы роутов), то следующий шаг необходим для редиректа на созданный «админский» роут после успешного входа в систему, который заключается в изменении стандартного Laravel Middleware RedirectIfAuthenticated.

Описан он в файле корень_сайта\app\Htpp\Middleware\RedirectIfAuthenticated.php.

В нём необходимо подкорректировать главный метод handle(), указав в нём роут admin вместо home:

public function handle($request, Closure $next, $guard = null)
{
    if (Auth::guard($guard)->check()) {
        return redirect('/admin');
    }

    return $next($request);
}

Также для уверенности указываем наш новый роут свойству redirectTo класса LoginController (хотя на практике достаточно всего одного из указанных способов):

protected $redirectTo = '/admin';

Тестим: всё шик 🙂 То, что я хотел, получилось — после аутентификации на сайте автоматически происходит перенаправление на url http://site.com/admin.

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

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

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

//Перенаправление на страницу логина после выхода пользователя из системы
public function logout()
{        
    Auth::logout();
    return redirect('/login');
}

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

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

По умолчанию Laravel возвращает ответ в формате JSON с 401 кодом при AJAX запросах и редиректит на страницу с url http://site.com/login.

Чтобы изменить данное поведение, нужно будет добавить функцию unauthenticated в файл корень_сайта/app/Exceptions/Handler.php и прописать в ней необходимые сценарии поведения примерно таким образом:

<?php

use Illuminate\Auth\AuthenticationException;

protected function unauthenticated($request, AuthenticationException $exception)
{
    return $request->expectsJson()
                ? response()->json(['message' => $exception->getMessage()], 401)
                : redirect()->guest(route('custom_url'));
}

Все описанные выше изменения вы традиционно можете найти в репозитории проекта, разрабатываемого в рамках данного цикла статей о Laravel, в коммите с хэшом 84e3efbf05000953db017a6f0c48e8e43b66b995.

И вот на этой ноте я плавно подошёл к завершающему блоку сегодняшней статьи — к обзору методов фасада Laravel Auth и соответствующих им хэлперов (Laravel helpers), которые пригодятся при работе с данными аутентифицированных пользователей в коде приложения.

Методы фасада Laravel Auth и хэлперы аутентификации

Фасад Laravel Auth, как и все остальные facades, — это классы, которые предоставляют статические интерфейсы для методов других классов. Следовательно, для корректного вызова методов фасада Auth в коде пользовательского класса необходимо в самом начале класса добавить следующий код:

use Illuminate\Support\Facades\Auth;

Использовать перечисленные далее методы можно по единому сценарию:

Auth::method_name();

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

И, естественно, что все перечисленные методы будут public, а не protected или private, т.к. при таких условиях использовать их за пределами класса не получится. Описание методов будет приведено в формате тип_возвращаемых_данных имя_метода(тип входных параметров имя_параметра [, …]).

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

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

  • директория_сайта\vendor\laravel\framework\src\Illuminate\Auth\TokenGuard.php
  • директория_сайта\vendor\laravel\framework\src\Illuminate\Auth\SessionGuard.php

А также при использовании каждого из гвардов доступны базовые методы, описанные в трейте Illuminate\Auth\GuardHelpers, который используют перечисленные классы Laravel guards.

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

Authenticatable|null user()

Возвращает объект с данными текущего аутентифицированного пользователя. Если пользователь не залогинен, то происходит его аутентификация. В session Laravel Auth guard фреймворк сначала пытается аутентифицировать пользователя по его идентификатору сессии, а если таковой не будет найден, то по его зашифрованному идентификатору из cookies браузера.

При использовании token гварда же authentication сначала происходит по токену. Дальнейший сценарий идентичен Laravel auth session guard.

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

bool validate(array $credentials = [])

Метод проверяет корректность учётных данных (креды, credentials) пользователей.

Authenticatable authenticate()

Аналог user().

bool check()

Нужен для проверки аутентификации в Laravel приложении текущего пользователя. Функция Laravel Auth check() возвращает true или false в зависимости от возвращаемого функцией user() значения.

bool guest()

Аналог user().

int|null id()

Возвращает ID текущего аутентифицированного пользователя.

$this setUser(Authenticatable $user)

Устанавливает текущего пользователя, данные которого можно будет потом получить через user() и authenticate(). Не является аналогом Laravel Auth login()!

UserProvider getProvider()

Возвращает объект Laravel Auth provider для текущего гварда с целью использования его в коде.

void setProvider(UserProvider $provider)

Метод позволяет задавать Auth провайдер текущему гварду из кода.

$this setRequest(Request $request)

Инициализирует текущий запрос данными переданного в метод объекта. Также для использования в коде.

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

string getTokenForRequest()

Возвращает токен для текущего запроса.

Ну, а при использовании session Auth гварда помимо перечисленных выше методов вам также будут доступны следующие методы:

Authenticatable|null getUser()

Возвращает текущего закэшированного пользователя. Упрощённая версия user().

bool viaRemember()

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

string getRecallerName()

Возвращает имя переменной cookie, используемой для хранения «recaller».

string getName()

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

Authenticatable getLastAttempted()

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

void attempting(mixed $callback)

Используется для регистрации слушателя (listener) события с попыткой аутентификации.

$this logoutOtherDevices(string $password, string $attribute = 'password')

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

Для использования данного метода ваше Laravel приложение должно использовать AuthenticateSession middleware. Добавлять его нужно в группу web массива $middlewareGroups файла корень_сайта\app\Http\Kernel.php следующим образом:

'web' => [
    // ...
    \Illuminate\Session\Middleware\AuthenticateSession::class,
    // ...
],

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

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

void logout()

Разлогинивает пользователя в вашем Laravel приложении.

void login(Authenticatable $user, bool $remember = false)

Аутентифицирует (логинит) пользователя на Laravel сайте. При указании значения второму параметру true для пользователя будет генерироваться remember_token, который в дальнейшем будет записываться в cookie и использоваться для автоматической аутентификации до тех пор, пока пользователь не сбросит cookie браузера или не разлогинится самостоятельно.

Authenticatable loginUsingId(mixed $id, bool $remember = false)

Аутентифицирует пользователя в Laravel приложении по его id из таблицы БД с пользователями.

bool attempt(array $credentials = [], bool $remember = false)

Делается попытка аутентификации пользователя по его учётным данным (credentials). Данный метод можно использовать при реализации ручной аутентификации в Laravel без использования стандартного метода фасада Laravel Auth login(), если он вам по каким-то причинам не будет подходить либо если вы захотите заменить стандартный LoginController на полностью свой кастомный.

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

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;

class LoginController extends Controller
{
    public function authenticate(Request $request)
    {
        $credentials = $request->only('login', 'password');

        if (Auth::attempt($credentials)) {
            // Authentication passed...
            return redirect()->intended('dashboard');
        }
    }
}

Смысл его кода прост: при вызове метода выделяем из объекта запроса $request значения полей, по которым происходит Laravel аутентификация пользователя в системе, и передаём их в качестве входных параметров методу Laravel attempt().

Если аутентификация данных удалась (attempt() вернул true, а не false), то происходит редирект на url, на который пытался перейти пользователь, но был перенаправлен на страницу входа с помощью Auth middlewarte, посредством метода intended().

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

В метод Laravel Auth attempt(), кстати, можно передавать не только непосредственно значения полей, по которым происходит аутентификация , но и другие поля таблицы БД пользователей для формирования дополнительных условий входа.

Например, если у вас в таблице БД users есть поле is_deleted типа boolean (true/false) для «мягкого удаления» (soft delete) пользователей, то при аутентификации через Laravel Auth attempt() вы сможете проверять, был ли удалён юзер или нет следующим образом:

if (Auth::attempt(['email' => $login, 'password' => $password, 'is_deleted' => false])) {
    // действия, происходящие при успешной аутентификации
}

Следовательно, даже если у пользователя введённые им креды будут соответствовать содержащимся в БД, но при этом он будет удалённым (is_deleted = true), то он не будет аутентифицирован на сайте.

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

bool once(array $credentials = [])

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

bool onceUsingId(mixed $id)

Логинит пользователя на Laravel сайте по его id из таблицы БД с пользователями без использования cookies и сессий. Как понятно из названия, — симбиоз loginUsingId() и once().

Response|null basic(string $field = 'email', array $extraConditions = [])

Попытка входа на сайт с использованием базовой HTTP аутентификации (HTTP Basic Auth). Она заключается в том, что для Laravel аутентификации пользователя на сайте используется не кастомная форма входа, имеющая отдельный url, а стандартная браузерная форма, которая выглядит вот так:

laravel-basic-http-auth

Для того, чтобы настроить вход пользователя на сайт посредством данного типа аутентификации, в Laravel уже есть всё необходимое. Достаточно применить Laravel middleware auth.basic к роуту или их группе в файле маршрутизации. По умолчанию для базовой HTTP authentication в Laravel используется поле email.

Если вы используете PHP FastCGI, то HTTP Basic аутентификация может неправильно работать по умолчанию. В таком случае вам нужно будет добавить в файл .htaccess следующие строки:

RewriteCond %{HTTP:Authorization} ^(.+)$
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Главное, добавить код в нужный .htaccess, т.к. после установки Laravel в приложении их целых два. Нам нужен тот, что находится в директории public, а точнее, на одном уровне с index.php (если вы вдруг изменили свою файловую структуру проекта).

Response|null onceBasic(string $field = 'email', array $extraConditions = [])

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

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

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

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

Ну, и последнее, что я хотел сегодня вам рассказать, это — познакомить с Laravel helper auth(), который позволяет получать экземпляр фасада Laravel Auth без прямого его подключения. Это очень удобно особенно в Blade шаблонах.

Использовать его очень просто. Следующая конструкция позволит вам получить данные аутентифицированного пользователя:

auth()->user();

А следующая позволит вам узнать, аутентифицирован ли пользователь в системе с использованием Laravel Auth гварда guard:

auth('guard')->check();

Также хотелось бы добавить, что данные аутентифицированного в Laravel приложении пользователя вы всегда можете получить через объект класса Illuminate\Http\Request в своём коде, например:

<?php

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

class UserController extends Controller
{
    public function update(Request $request)
    {
        $request->user(); //всё равно, что вызов auth()->user, к примеру
    }
}

Вот мы и рассмотрели все public методы фасада Laravel Auth и Laravel helpers, которые позволяют манипулировать данными аутентифицированных пользователей, а также производить принудительную аутентификацию и выход из системы юзеров в коде приложения.

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

  • Кратковременная через переменные сессии на сервере (доступны через суперглобальный массив PHP $_SESSION), которая по умолчанию в PHP длится 1440 секунд или 24 минуты (задаётся в переменной session.gc_maxlifetime главного PHP конфига php.ini);
  • Долгосрочная через cookies браузеров клиентов, в которые записывается значение remember_token, генерируемого при аутентификации клиента на сайте с определёнными настройками;
  • Разовая без записи cookies и session по кредам пользователя, которая годится только для выполнения отдельных запросов, требующих аутентификации.

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

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

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

Удачи и до новый встреч 😉

Spring must go on! Скидки до 70% на TemplateMonster шаблоны

templatemonster-shablony-majskie-skidkiВсем привет! 🙂

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

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

Среди них знакомые всем WordPress, OpenCart, Magento и другие монстры индустрии.

Так же, как велик ассортимент TemplateMonster шаблонов, так же велико и количество различных акций и скидок на них.

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

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

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

Заключается оно в том, что с 14 по 17 мая 2018 года действует скидка до 70% на все шаблоны, доступные у них на сайте, в зависимости от CMS, для которой они разработаны, а также типа самого шаблона (темы для landing page, шаблоны рассылок и т.д.)

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

  • WordPress — 25%
  • Landingpage — 5%
  • Magento — 45%
  • Shopify — 45%
  • PrestaShop — 45%
  • OpenCart — 15%
  • Joomla — 30%
  • Drupal — 30%
  • ZenCart — 70%
  • VirtueMart — 70%
  • MotoCMS3 — 40%
  • Website Templates — 30%
  • WooCommerce — 45%
  • Moto eCommerce — 40%
  • Все остальные типы — 35%

Самая маленькая в 5% на TemplateMonster шаблоны для лендинг пейдж обусловлена невысокой стоимостью данных тем (всего 19$ без акции) и простотой их разработки.

Самая же высокая скидка в 70%, как вы видите, предоставляется для CMS ZenCart и VirtueMart (плагин Joomla для создания Интернет-магазина). Кто сегодня запускает Интернет магазины на Virtuemart? А о ZenCart вы вообще слышали? Это, кстати, тоже eCommerce движок 🙂

Уверен, что таких немного.

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

Настал ваш звёздный час! По другому сложившуюся ситуацию и не прокомментируешь, т.к. благодаря текущей акции от TemplateMonster вы можете купить для своего магазина новенькую тему всего за 42$ вместо 140$ до акции.

Данный момент может даже послужить стимулом для создания Интернет магазина именно на Virtuemart или ZenCart, т.к. шаблоны для других CMS Интернет-магазинов (Magento, например) стоят на порядок дороже…

Ну, а средненькие скидки в 15-30% на WordPress и OpenCart шаблоны обусловлены популярностью данных движков и невысокую стартовую стоимость. Резким исключением из данного правила является Magento со скидкой в 45%, несмотря на то, что движок достаточно популярен.

Так что, как видите, всё честно, и не нужно искать какого-то подвоха 🙂

Лучше вместо этого поторопиться и выбрать себе новый шаблон от TemplateMonster для создания своего сайта или редизайна существующего.

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

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

Помните только, что на всё про всё TemplateMonster даёт вам 4 дня, так что долго тянуть резину не советую.

Скажите жене, что у вас много работы, мужу — что хотите похудеть к лету и записались на фитнес, детям… (им, пожалуй, лучше не врать и не подавать дурной пример 🙂 ) — и все на онлайн-шопинг!

Как говорит народная мудрость, к зиме (т.е. к сезону продаж) нужно готовиться летом…

Вперёд ! 🙂

Netpeak Spider: возможности и польза при SEO аудите сайта

netpeak-spiderВсем привет! 🙂

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

Итак, о чём сегодня будет идти речь?

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

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

Поехали! 🙂

Что такое Netpeak Spider?

О том, для чего нужна данная SEO программа, можно узнать, расшифровав её название.

Если вы интересуетесь SEO, то, наверняка, вам знакома компания Netpeak, т.к. статьи её блога находятся в ТОПе поисковой выдачи по многим запросам (даже по запросу SEO, обходя Википедию), а также её продукты, о которых часто упоминается на сторонних ресурсах, занимающих ТОП по другим запросам.

Так что, как ни крутите, если в SEO вы не первый день, то о Netpeak вы просто обязаны были слышать 🙂 Но, если быть точными, разработчиками Netpeak Spider является Netpeak Software, которая является частью Netpeak Group.

Ну, а Spider — это, в переводе с английского, «паук». Паук плетёт паутину или сеть, другими словами. А поскольку Интернет — это тоже сеть, то спайдерами часто называют программы, которые занимаются поиском информации и дальнейшей обработкой собранных в Интернете данных.

Такая вот игра слов 🙂

Какую же информацию собирает в сети Нетпик Спайдер?

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

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

  1. Технический SEO аудит сайта: поиск битых ссылок, ошибок в коде, плохо настроенных редиректов, дублей контента и метаданных, title, description и др.
  2. Анализ ссылочной массы веб-сайта в общем (внешней и внутренней), а также для каждой его отдельной страницы.
  3. Проверка сайта на SEO ошибки, отрицательно влияющих на его позиции в поисковой выдаче и usability: битые картинки, ссылки на несуществующие страницы (возвращающие код 404 HTTP запроса к таким страницам) и т.д.
  4. Установка причины неработоспособности сайта (бесконечный редирект) или отдельных его страниц (404, 500, 503 код ответа сервера).
  5. Анализ SEO оптимизации сайта, проведённой сторонними исполнителями, для контроля её качества.

Собственно говоря, необходимость проведения очередного SEO аудита и свела меня с Netpeak Spider, который, как уверяют его разработчики, учитывает больше параметров при анализе (54) и позволяет выявить большее количество ошибок (62) по сравнению с конкурентами, обращая внимание даже на незаметные с первого взгляда мелочи.

Скажу честно, что я поддался громкой рекламе. А вот оправдались ли мои ожидания или нет — об этом далее…

SEO аудит с помощью Нетпик Спайдер

Протестировать возможности данной программы SEO анализа я решил, естественно, на примере текущего сайта — http://cccp-blog.com.

Чтобы это сделать, для начала нужно Netpeak Spider скачать. Для этого, в свою очередь, нужно завести Netpeak аккаунт путём регистрации на официальном сайте и скачать Launcher, через который уже и можно будет скачать Netpeak Spider и прочие продукты данной компании.

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

А это, кстати, весомое преимущество над другими SEO инструментами, например Serpstat, функционал которого на пробном периоде весьма ограничен: анализировать можно только один сайт, количество запросов ограничено и т.д.

После установки программы на свой ПК (использовать Netpeak Spider можно как на Windows машинах, так и на Mac OS) единственное, что нужно сделать для запуска SEO анализа сайта, это ввести URL сайта в адресную строку:

netpeak-spider-pomoschnik-seo-optimizatora

При вводе доменного имени сайта в строку поиска, анализ ресурса происходит с учётом HTTPs протокола по умолчанию. Поэтому, если у вас ресурс работает по HTTP (как у меня), то указывайте протокол явно.

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

seo-analiz-sajta-s-netpeak-spider

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

Для запуска самого сканирования ресурса нужно нажать на кнопку Старт, расположенную рядом с полем для ввода URL сайта.

После SEO анализа ресурса на предмет ошибок (прошёл он, кстати, достаточно быстро — за 4 с копейками минуты, при том что на сайте больше 150 страниц) я получил следующую картину на вкладке Отчёты, на которую устанавливается фокус после запуска сканирования:

netpeak-spider-seo-prodvizhenie-sajta-samostoyatelno

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

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

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

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

Однако, помимо реальных, пропущенных мною редиректов, были и какие-то «левые» следующего формата:

netpik-spajder-programma-seo-analiza-sajta

Что самое интересное, эти фейковые «битые» редиректы были разные при различных сканированиях 🙂

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

Например, Netpeak Spider для некоторых страниц показал 503 код ошибки, хотя по факту они доступны и индексируются:

netpik-spajder-analiz-seo-optimizacii-sajta

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

netpeak-spider-oshibka-v-seo

Разгадка данного поведения Netpeak Spider оказалась весьма банальной и заключалась в обширных настройках SEO программы и, в частности, в количестве потоков сканирования, которых по умолчанию было 10:

nastrojka-programmy-seo-analiza-sajta-netpeak-spider

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

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

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

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

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

Естественно, я это исправил, тем более, что программа отнесла данное упущение к ошибкам в SEO средней критичности.

Очередным резонным замечанием в адрес моего сайта была работа по протоколу HTTP, в то время как уже несколько лет Google рекомендует (чуть ли не требует) от сайтов работу по защищённому HTTPs протоколу.

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

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

Остальные же ошибки, найденные Netpeak Spider на моём сайте, были вызваны особенностями CMS WordPress, на базе которой он и разработан. Они касались множества лишних ссылок формата http://url_статьи/feed и http://url_статьи?replytocom=123, которые я закрыл от индексации, но физически они на сайте присутствовали.

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

Теперь пару слов об ошибках, которые можно обнаружить на своём сайте с помощью Netpeak Spider, но с которыми я не столкнулся, поэтому и не упомянул о них:

  • дубли страниц (url), контента и мета-данных;
  • страницы сайта с большим количеством редиректов (включая бесконечный);
  • битые изображения;
  • страницы без внутренних ссылок (нарушают естественное распределение ссылочного веса);
  • несколько одноимённых meta тэгов (title, description, h1) в рамках одной страницы;
  • страницы с малым контентом, длинными url, большим временем загрузки, слишком тяжёлыми изображениями;
  • url сайта, заблокированные в robots.txt (да, Netpeak Spider может его считывать и анализировать), а также автоматически проводится проверка наличия данного файла на сайте;
  • страницы с одинаковым title и description (оказывается, это тоже грех в мире SEO), а также имеющие слишком длинные/короткие их значения.

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

Встроенные SEO инструменты Netpeak Spider

В самой программе для SEO анализа сайта их можно найти в пункте главного меню Инструменты. Эх, никакой интриги 🙂

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

netpeak-spider-seo-instrument-analiza-stranicy

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

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

Речь идёт о PageRank Checker — инструменте, позволяющем проверить PageRank, т.е. относительный вес страницы сайта, который выглядит следующим образом:

netpeak-spider-proverit-pagerank-sajta

Формула расчёта представлена вверху экрана.

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

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

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

Следующим интересным SEO инструментом из комплекта Netpeak Spider является валидатор XML Sitemap карты сайта, который выглядит следующим образом:

netpeak-spider-proverit-xml-sitemap-kartu-sajta

С его помощью можно проанализировать XML карту сайта на предмет ошибок и соответствия её требованиям поисковых систем (Google, Bing, Яндекс). Также здесь имеется возможность сообщить поисковикам о наличии на сайте карты.

Ну, а для тех, у кого карты ещё нет, Netpeak Spider как раз имеет подходящий инструмент, позволяющий сделать карту сайта XML, который выглядит так:

netpeak-spider-generator-xml-karty-sajta

Мелочь, но всё же приятно, когда генератор XML карты сайта под рукой, и не нужно тратить силы на его поиски в Интернете 🙂

Кроме всего перечисленного, Netpeak Spider позволяет экспортировать собранные в процессе SEO аудита данные в Excel документы для предоставления их клиентам, начальству для отчётности или просто для себя любимого, чтобы вернуться к анализу собранных программой данных позже.

Работа с Netpeak Spider: выводы

Несмотря на некоторые недостатки и спорные моменты при работе с программой, работой с Netpeak Spider я остался доволен.

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

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

Если оценивать данный продукт по 10-бальной шкале, то Netpeak Spider, как по мне, заслуживает 8-ку.

Один бал я срезал за технические моменты, а второй за то, что продукт коммерческий. Хотя для студий, занимающихся SEO продвижением профессионально, да и обычным веб-мастерам, которые хотят сэкономить и произвести SEO оптимизацию сайта самостоятельно, 120$ в год или 14$ в месяц вряд ли нанесут серьёзный урон кошельку.

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

Также стоит отметить, что рассмотренные в данной статье возможности характерны для Netpeak Spider 3.0, релиз которой состоялся сравнительно недавно. Так что если вы ещё пользуетесь предыдущими версиями, данная новость — отличный повод скачать свежачок и оценить новые функции.

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

Напомню, что скачать Netpeak Spider вы можете здесь. При скачивании по данной ссылке вы дополнительно получите скидку в 10%, как участник партнёрской программы. Поэтому не нужно жадничать и выдумывать способы обхода реферальных ссылок 🙂

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

Провели SEO анализ своего сайта — помогите сделать его и своим товарищам! Уверен, что лишним он точно не будет, как и в моём случае, когда я думал, что мой сайт по SEO идеален 🙂

Удачи всем и до новых встреч! 🙂

Laravel админка: 8 готовых решений

laravel-admin-panelПриветствую вас, друзья! 🙂

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

Честно скажу, что не планировал делать его таким долгим. Изначально в планах был месяц и 2-3 статьи о капче, принципами работы и заработком на которой я тогда увлёкся. Да и от Laravel я на тот момент тоже устал, т.к. на протяжении нескольких месяцев писал только о нём.

В итоге, запланированный месяц затянулся на 6, а 2-3 статьи на 22 публикации на посторонние темы. Естественно, всё это привело к тому, что я жутко соскучился по Laravel, т.е. цель отпуска была достигнута в полной мере 🙂

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

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

Поэтому для того, чтобы определиться, я решил рассмотреть сегодня существующие Laravel admin panel packages: их возможности, преимущества и недостатки.

Поехали! 🙂

Обзор Laravel admin panel: особенности

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

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

Устаревшие пакеты, которые у меня не запустились, вы увидите в конце статьи.

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

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

И отсюда следует последняя особенность — все рассматриваемые в данной статье решения являются opensource, т.е. бесплатными и с открытым кодом. Коммерческим продуктам типа BackPack я решил не уделять внимание.

Визуальные конструкторы Laravel admin panel

Основной особенностью данной категории решений для Laravel административных панелей является максимальная визуализация рабочего процесса. Они очень похожи на те, которые доступны из коробки в популярных CMS: WordPress, OpenCart, Magento и др.

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

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

Laravel Voyager

Рейтинг на Github: 5875 звёзд

Исходный код: https://github.com/the-control-group/voyager

Официальный сайт: https://laravelvoyager.com/

Установка простая и состоит из 3 шагов: установки пакета через Composer, создание пустой БД и установки данных пакета (зависимости, запуск миграций и т.д.).

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

При установке данных пакета можно воспользоваться опцией —with-dummy, чтобы установить админку с набором демо-данных (dummy data). В них входит 1 аккаунт администратора (если до сих пор у вас не было пользователей в БД в таблице users), 1 демо страница, 4 поста, 2 категории и 7 настроек.

После установки данная Laravel админка доступна по адресу site.url/admin, при переходе на который вы увидите слегка экстравагантную форму входа:

laravel-voyager-admin-panel

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

В итоге, после установки Laravel Voyager admin и входа я увидел следующее:

laravel-voyager-nastrojka

После я приступил к настройке Laravel Voyager и изучению её особенностей.

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

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

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

Также у Voyager Laravel admin panel есть своя система хуков, с помощью которой существует возможность расширять функционал админки и сайта дополнительными возможностями. На данный момент Voyager hooks не очень много, с полным перечнем которых вы можете познакомиться здесь — https://larapack.io/.

Из самых интересных — WordPress import и возможность проводить опросы на сайте.

Ну, и несомненная изюминка Voyager Laravel admin panel — это наличие менеджера БД и BREAD builer, которые позволяют иметь прямо в админке упрощённый аналог phpMyAdmin.

Менеджер базы данных позволяет редактировать структуру БД и таблиц, а BREAD builder — по сути, обыкновенный CRUD генератор для заполнения таблиц БД данными через админку, только вместо привычных Create, Read, Update, Delete создатели Voyager решили почему-то зашифровать иные действия: Browse, Read, Edit, Add, Delete.

Видимо, маркетологи и различные брендмейкеры в их команде тоже имеются 🙂

Должен сказать, что встроенный в админку менеджер БД — штука очень полезная, особенно, когда заказчики не дают доступ к базе, но хотят её структуру поменять 🙂 Либо используют shared хостинг без SSH доступа, что делает невозможным запуск Laravel миграций в консоли сервера.

Сам уже однажды с такой ситуацией столкнулся, и наличие Voyager Laravel admin panel на сайте клиента меня тогда сильно спасло.

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

Проще говоря, Voyager Laravel admin panel позволяет задавать значения различным полям (названия товаров, тексты постов) на разных языках с возможностью быстрого их переключения.

Единственное, что мне не понравилось в Voyager, — это документация, которая доступна по этой ссылке — https://voyager.readme.io/docs.

Несмотря на то, что составлена она весьма недурно, в ней описаны далеко не все моменты, возникающие при работе с данной Laravel admin panel. Про ту же самую мультиязычность пришлось читать на GitHub — https://github.com/the-control-group/voyager/pull/561

В прочем, разработчики и сами признают этот недостаток, указав на стартовом экране доки приписку still in development.

Ну, и не по душе мне пришлась повёрнутось авторов Voyager Laravel admin panel на морской теме админки, которая может не каждому понравится. Так что готовьтесь к тому, что её, возможно, придётся кастомизировать по требованию заказчика.

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

Laravel QuickAdmin

Рейтинг на Github: 438 звёзд

Исходный код: https://github.com/LaravelDaily/quickadmin

Официальный сайт: https://quickadminpanel.com/

Установка Laravel QuickAdmin прошла реально быстро (судя по переводу названия), просто и понятно.

Документация составлена достаточно подробно и описывает все основные моменты, возникающие при работе с админкой, начиная от её установки, заканчивая настройкой — http://laraveldaily.com/packages/quickadmin/. Правда, исчерпывающей её также нельзя назвать.

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

laravel-quickadmin-package-dashboard

Что же я увидел из возможностей?

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

Правда, после создания CRUD контроллера ни удалять его, ни редактировать набор полей нельзя. Единственный вариант: удалить и создать снова или сделать всё вручную путём ручного прописывания в БД и модели.

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

В-третьих, есть возможность добавления новых элементов в меню админки с возможностью их Drag-and-drop позиционирования с изменением уровней вложенности.

laravel-quickadmin-package-menyu-generator

Правда, пункты меню удалять нельзя, только вручную через БД.

В отличие от Voyager админки, мне понравилась удобная кастомизация генерируемого админкой кода. Все контроллеры и модели создаются в директориях Laravel по умолчанию (app/Http/Controllers/ и app/, соответственно). Не нужно их искать по всему проекту.

Теперь о том, что мне не понравилось в Laravel QuickAdmin. Прежде всего, это будущие проблемы при добавлении на сайт мультиязычности сущностей (в отличе от упоминавшегося уже Laravel Voyager admin).

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

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

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

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

Генераторы Laravel админок

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

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

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

Однако, это обстоятельство предъявляет к ним серьёзные требования относительно чистоты и понятности кода. Если CRUD-классы будут плохо структурированы, а процесс генерации Laravel админ панели будет запутан, то использование данных продуктов может, наоборот, только увеличить сроки реализации.

Z-Song Laravel admin

Рейтинг на Github: 3201 звезды

Исходный код: https://github.com/z-song/laravel-admin

Официальный сайт: http://laravel-admin.org/

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

После логина в админке я сразу увидел, что она разработана на основе популярного AdminLTE admin template:

laravel-admin-panel-generator-zsong

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

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

Пакет предоставляет набор artisan команд для генерации контроллеров моделей, model-grid (страниц со списком сущностей с возможностью кастомизации её внешнего вида), model-form (страниц редактирования атрибутов отдельной сущности) и роутов для доступа ко всему этому.

Всё, что вам потребуется сделать самостоятельно, — это создать таблицу БД (проще всего с помощью Laravel миграций) и сгенерировать для неё модель.

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

В общем, данный Laravel admin generator реально очень крутой и произвёл на меня положительное впечатление. Не зря им пользуются тысячи Laravel разработчиков, судя по звёздам на GitHub 🙂

InfyOm Laravel Generator

Рейтинг на Github: 1817 звёзд

Исходный код: https://github.com/InfyOmLabs/laravel-generator

Официальный сайт: http://labs.infyom.com/laravelgenerator/

Достаточно мощный Laravel package со слоганом «Получите ваше API и панель администрирования за считанные минуты», которым создатели делают акцент, в первую очередь, даже на генерацию API, а не на admin panel.

В состав данного Laravel пакета входит целых 3 генератора, использовать которые можно как в комплекте, так и поодично в рамках одного проекта:

  1. генератор API;
  2. генератор Laravel admin panel;
  3. генератор Swagger документации для API.

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

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

А ещё InfyOm Laravel Generator позволяет создавать тестовые данные с помощью Faker для тестирования генерируемых API методов.

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

class BookController extends AppBaseController
{
    /** @var  BookRepository */
    private $bookRepository;

    public function __construct(BookRepository $bookRepo)
    {
        $this->bookRepository = $bookRepo;
    }

    /**
     * Display a listing of the Book.
     *
     * @param Request $request
     * @return Response
     */
    public function index(Request $request)
    {
        $this->bookRepository->pushCriteria(new RequestCriteria($request));
        $books = $this->bookRepository->all();

        return view('books.index')
            ->with('books', $books);
    }

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

Единственное, что мне не понравилось при работе с данной админкой, — это её лёгкая замудрённость. Для её установки и запуска с минимальными настройками лично у меня ушло раза в 3 больше времени, чем при использовании Z-Song Laravel Admin, к примеру.

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

Laravel Sleeping Owl Admin

Рейтинг на Github: 486+496 (для старой версии) = 982 звёзды

Исходный код: https://github.com/LaravelRUS/SleepingOwlAdmin

Официальный сайт: https://sleepingowladmin.ru

Старая версия с саппортом Laravel до версии 5.1 включительно доступна здесь — https://github.com/sleeping-owl/admin

Одна из самых древних генераторов админок, которая за историю своего существования успела даже сменить репозиторий. Старая версия с саппортом Laravel до версии 5.1 включительно доступна здесь — https://github.com/sleeping-owl/admin

А также Sleeping Owl Laravel admin generator — это первый package админки, с которым мне пришлось поработать.

Дело было года 2 назад. Я тогда пришёл работать в компанию, у которой был корпоративный сайт на Laravel 4.2. Поскольку фирма делала первые шаги, и заказов было немного, мне было поручено заняться саппортом данного творения.

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

Sleeping Owl Admin тогда идеально подошла под мои требования (особенно порадовало, что это отечественный продукт с обширной докой и даже статьями на Хабре от создателей), после чего я стал с ней разбираться. Скажу честно, что с задачей я справился спустя неделю мучений 🙂

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

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

Ещё одной серьёзной проблемой, которую не решал Sleeping Owl Laravel Admin, была невозможность организации мультиязычности хранимых в БД данных. Кроме того, на многие вопросы я не мог найти ответы в официальной документации, не смотря на то, что она довольна обширна — https://sleepingowladmin.ru/docs.

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

laravel-sleepingowl-admin-package

Честно говоря, эффекта «Вау» я не испытал. Заметил лишь, что админка достаточно серьёзно изменилась на фронте: её переписали под Vue.js, в качестве графического темплейта, похоже, использовали знакомую AdminLTE. Но на бэке всё осталось как в доке по старой, используемой мною 2 года назад версии.

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

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

Laravel CRUD Generator от AppzCoder

Рейтинг на Github: 777 звезд

Исходный код: https://github.com/appzcoder/crud-generator

Официальный сайт: отсутствует

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

Данный Laravel admin генератор позволяет сделать всё вышеперечисленное в консольном режиме с помощью команд следующего формата:

php artisan crud:api-controller Api\\PostsController --crud-name=posts --model-name=Post

От вас потребуется только указать значения параметров или путь к JSON-файлу с соответствующим содержимым.

По примеру выше видно, что данный Laravel пакет позволяет генерировать не только модели и контроллеры для действий с БД через UI сайта, но и с доступом через REST API.

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

Полная документация с перечнем возможностей доступна здесь — https://github.com/appzcoder/crud-generator/tree/master/doc (поскольку проект не коммерческий, на отдельный сайт автор решил не раскошеливаться).

Помимо рассмотренного генератора админки Laravel у его разработчика есть в наличии также и полноценный визуальный конструктор, доступный в данном репозитории — https://github.com/appzcoder/laravel-admin

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

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

Однако, после установки меня ждал фейл 🙂

Данная админка использует для своей работы Laravel Bootstrap файлы (public/css/app.css и public/js/app.js), которые я на данный момент успешно удалил. Таким образом, использовать данную Laravel admin panel в моём случае, равно как и на любом другом существующем проекте, не получится.

Можно было бы, конечно, заморочиться изменением файловых путей, но это дополнительные телодвижения, вместо которых можно просто использовать другой Laravel пакет 🙂

Поэтому я решил её даже детально и не рассматривать, а также не рекомендую прикручивать её к готовому коду, впрочем, ваше дело…

Laravel админка: забракованные решения

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

Laraadmin

Рейтинг на Github: 926 звёзд

Исходный код: https://github.com/dwijitsolutions/laraadmin

Официальный сайт: http://laraadmin.com/

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

В то время, как комменты коммитов репозитория проекта говорят о том, что добавлена поддержка Laravel 5.4 (при том, что активная версия фреймворка на данный момент 5.6), по факту вы не установите данную Laravel admin panel на версию движка старше 5.2, т.к. инсталлятор выдаст вам ошибку об отсутствии файла маршрутизации app/Http/routes.php.

Ну, и помимо данного фейла вы получите ещё много интересных error messages 🙂

FrozenNode Laravel-Administrator

Рейтинг на Github: 1954 звезды

Исходный код: https://github.com/FrozenNode/Laravel-Administrator

Официальный сайт: http://frozennode.com

Некогда достаточно популярная и одна из самых древних визуальных конструкторов Laravel админок. На GitHub описана процедура установки для Laravel 3 (!!!), который увидел свет в далёком, по меркам IT мира, 2012 году. Судя по скринам, выглядит неплохо и обладает достаточно обширной функциональностью.

Но она уже на протяжении 2 лет не поддерживается, официальный сайт недоступен, и поэтому рассчитывать на совместимость с новыми версиями Laravel глупо.

Я всё же решился на авантюру, попытавшись установить её на свой проект под Laravel 5.5, но в процессе получил сообщение об использовании deprecated метода, поэтому не стал особо и пытаться её воскресить.

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

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

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

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

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

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

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

Опять 35… или скидка на шаблоны сайтов TemplateMonster неизбежна

skidka-na-shablony-sajta-templatemonsterВсем привет 🙂

По названию статьи становится понятно, что на страницах cccp-blog.com намечается очередная минутка рекламы в качестве информера об акциях наших партнёров.

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

Итак, в чём суть акции?

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

Всё максимально просто и прозрачно: в период 9 по 11 апреля 2018 года предоставляется скидка 35% на все доступные у них на сайте шаблоны. Таким образом, у вас будет 3 дня на то, чтобы определиться с необходимым для вашего сайта шаблоном, вдоволь им попользоваться, вернуть обратно и даже купить новый, если первый вариант вас чем-то не устроит.

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

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

Особенно — работникам фриланса, а также аутсорсинговых студий и компаний, причём, независимо от способа создания сайтов. Среди шаблонов сайтов у TemplateMonster есть решения на все случаи жизни — как для CMS, так и написанные на HTML+CSS+JS, которые подойдут для ресурсов на базе любой платформы (того же самого Laravel, о котором скоро возобновятся публикации).

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

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

Поэтому на этом сегодняшний новостной пост подошёл к концу, и я побежал на TemplateMonster присматривать себе шаблончик, чего и вам желаю 🙂

Настройка и установка CS-Cart для запуска реального магазина

nastrojka-cs-cart-internet-magazinaДоброго времени суток, друзья 🙂

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

Для этого я по традиции, начатой при обзоре OpenCart и WordPress, расскажу вам, где скачать и как установить CS-Cart в виде подробной пошаговой инструкции, а также как его настроить и на какие параметры нужно будет обратить особое внимание.

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

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

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

Сами видите, что материал вас ожидает объёмный и увлекательный, поэтому устраивайтесь поудобнее, запасайтесь попкорном и — в путь! 🙂

Установка CS-Cart

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

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

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

Итак, скачать CS-Cart бесплатно (не смотря на то, что данный продукт платный) можно здесь — https://www.cs-cart.ru/download.html

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

По поводу системных требований могу сказать, что CS-Cart в этом плане весьма неприхотлив. К необходимому минимуму относятся наличие установленных PHP и MySQL на компьютере. Для удобства разработки на локальном Windows компьютере лично я рекомендую использовать WAMP сборки и, в частности, OpenServer, которому я остаюсь верен на протяжении уже более 3 лет 🙂

С полным списком всех системных требований, необходимых для стабильной работы магазина (пригодится при размещении сайта на хостинге), рекомендую ознакомиться на официальном сайте производителя — https://www.cs-cart.ru/docs/4.7.x/install/system_requirements.html

После этого я создал новый сайт в каталоге OpenServer domains под названием cscart.test (по данному адресу сайт будет доступен в браузере), скопировал туда архив, распаковал его и перезапустил сервер, чтобы он воспринял новый сайт, а затем перешёл на него в своём веб-браузере.

В итоге, я увидел на экране следующее сообщение:
kak-ustanovit-cs-cart-cherez-brauzer

Вариантов дальнейших действий, как вы видите, немного — нужно нажать на ссылку install, после чего запустится инсталлятор:

cs-cart-ustanovka-shag-pervyj

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

cs-cart-baza-dannykh-nastrojki-soedineniya

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

Как вы понимаете, для того, чтобы данный шаг завершился успешно, БД у вас уже должна быть. Если же вы испытываете трудности при её создании, то в качестве инструкции можете воспользоваться рекомендациями по созданию БД через phpMyAdmin из комплекта OpenServer, которые изложены, например, в статье о создании блога на WordPress.

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

cs-cart-ustanovka-nastrojka-administrirovaniya

Однако, я решил установить CS-Cart без данной опции, т.к. всё равно демо товары, категории и фильтры перед запуском реального проекта, процесс создания которого я решил вам продемонстрировать, придётся удалять.

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

cs-cart-licenziya-vybor-pri-ustanovke

Вариантов, как видите, два: либо ввести приобретённый ключ, либо воспользоваться 30-дневным пробным периодом. Естественно, я выбрал второй вариант, т. к. в мои планы входило исключительно ознакомление с возможностями CS-Cart 🙂

После нажатия на кнопку «Выбрать» и выполнения всех необходимых действий инсталлятором в автоматическом режиме вас должно будет перенаправить на следующий экран:

cs-cart-ustanovka-zavershayushchij-etap

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

Настройка CS-Cart с помощью мастера

В принципе, после того, как вы увидели экран с сообщением об успешной установке CS-Cart, вы можете приступать к настройке магазина, введя в адресную строку браузера http://доменное_имя_сайта/admin.php или нажав на соответствующую кнопку на завершающем экране установки движка.

Однако, не спешите это делать и закрывать текущую страницу 🙂

Дело в том, что на ней находится ещё одна «фишка» CS-Cart – это кнопка запуска мастера настройки, которого я не встречал ни у каких-либо других CMS и движков.

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

Выглядит всё это дело следующим образом:

cs-cart-nastrojka-cherez-master

Благодаря мастеру вы сможете произвести следующие CS-Cart настройки, которые разделены на 5 шагов:

  • конфигурация учётной записи админа (может ли пароль содержать символы и цифры, возможность смены пароля при первом входе и т. д.);
  • настройки CS-Cart для HTTPs соединения с сайтом (можно проверить правильность установки SSL сертификата на сервере и включить защищённую передачу данных как для админки, так и для витрины магазина отдельно);
  • выбор редактора HTML кода (TinyMCE, Redactor, Redactor 2) и инструмента просмотра фотографий (LightBox, MagnificPopup и т. д.);
  • валюта (доступны рубли, доллары США, евро и фунты стерлингов);
  • языки по умолчанию, формат даты и времени;
  • информация о компании (название, адрес, сайт, контакты);
  • возможность быстрой регистрации;
  • включение необходимых модулей, имеющихся в CS-Cart по умолчанию, и их отключение

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

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

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

Создание категорий товаров в CS-Cart

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

cs-cart-internet-magazin-posle-ustanovki

По той простой причине, что нам ещё нечего продавать, т.к. в магазине на данный момент нет ни одного товара 🙂

Ну что ж, пора исправить этот недостаток… Начнём с создания категорий в CS-Cart, в которые мы будем группировать наши товары.

Для этого в админке открываем пункт меню Товары > Категории и нажимаем на кнопку с плюсиком в правом верхнем углу экрана, после чего откроется форма добавления новой категории в CS-Cart магазин:

cs-cart-kategorii-tovarov-novaya

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

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

cs-cart-menyu-kategoriya

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

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

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

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

cs-cart-menyu-novyj-element

Для добавления ссылки на только что созданную категорию мне пришлось вводить всю информацию вручную, что жутко неудобно, если честно. По каким-то причинам добавлять готовые CS-Cart категории в меню можно только в подпункты создаваемого элемента, а в корень — нет 🙁

Зато имеется возможность добавления CSS класса создаваемому пункту.

Итак, сохраняем изменения, после чего наше главное меню витрины CS-Cart магазина примет следующий вид:

cs-cart-vitrina-menyu

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

Наполнение CS-Cart товарами

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

Рассмотрим оба.

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

cs-cart-tovary-import

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

cs-cart-opcii-tovara-pri-massovoj-zagruzke

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

Для эксперимента я быстренько набросал простенький файлик в обычном текстовом редакторе (подойдёт обычный Блокнот, но лично я люблю Notepad++) с названием import.txt следующего вида:

Product code;Language;Category;Product id;Product name;Price;Quantity
tovar1;ru;Спортивное питание;1;Протеин Optimum Nutrition 1кг;100;10
tovar2;ru;Спортивное питание;2;Креатин Scitec Nutition 0,5кг;200;20

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

В качестве категории я указал только что созданную. Если же данное поле оставить пустым, то автоматически будет создана CS-Cart категория Products, в которую будут добавлены загружаемые товары.

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

cs-cart-tovary-uspeshnyj-import

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

Данные возможности рассортированы по вкладкам, доступным в самом верху страницы.

После импорта товаров в CS-Cart из текстового файла я решил проверить, что же мне CS-Cart понасоздавал. Самый простой способ сделать это — обновить страницу категории товаров на витрине магазина:

cs-cart-kategoriya-s-tovarami-na-vitrine

Вуаля! 🙂 Товары появились на витрине с теми атрибутами, которые были им указаны в файле. Чтобы просмотреть их список в административной панели CS-Cart, достаточно выбрать пункт меню Товары > Товары.

cs-cart-nastrojka-tovarov-v-adminke

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

Среди самых интересных мне удалось обнаружить следующие:

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

В итоге, после всех моих правок карточка товара CS-Cart магазина на витрине приняла следующий вид:

cs-cart-kartochka-tovara

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

Прочие настройки витрины CS-Cart

Первая из них — фильтры CS-Cart товаров, которые добавлять проще простого.

Для этого в главном меню админки CS-Cart переходим на страницу Товары > Фильтры, которая по умолчанию пустая, и нажимаем на кнопку с плюсиком для добавления нового фильтра. После этого перед нами появится следующее окно:

cs-cart-nastrojka-filtrov

Как видите, по умолчанию в CS-Cart фильтров у вас много добавить не получится. Есть возможность фильтрации по цене, наличию и доставке. Для начала я решил сделать фильтр по цене.

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

cs-cart-filtr-tovara-na-vitrine

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

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

Чтобы в CS-Cart добавить новые характеристики товара, необходимо перейти в админке на страницу Товары > Характеристики и нажать кнопку с плюсиком вверху страницы, после чего появится следующее окно:

cs-cart-kharakteristiki-tovara

Вводим необходимые для вас значения (я решил сделать характеристики Для набора массы и Вкус, чтобы продемонстрировать разные варианты фильтров) и сохраняем, после чего при добавлении нового CS-Cart фильтра мы увидим добавленные характеристику в списке параметров фильтрации:

cs-cart-filtr-po-kharakteristikam-tovara

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

Для этого заходим в карточку товара CS-Cart и переходим на вкладку Характеристики, где выбираем необходимые:

cs-cart-nastrojka-kharakteristik-tovara

Для протеина я указал значения вкуса, а для креатина то, что он нужен для увеличения силы. В результате, фильтр у нас получился такой:

cs-cart-filtr-po-kharakteristikam-na-vitrine

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

Лично мне данное решение понравилось намного больше стандартного фильтра OpenCart за счёт своего удобства.

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

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

В итоге, карточка товара в моём CS-Cart магазине приняла следующий вид:

cs-cart-kartochka-tovara-itog

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

Оформление заказа в CS-Cart и связанные настройки

По умолчанию CMS предоставляет два способа оформления заказа:

  1. стандартный, с добавлением товара в CS-Cart корзину и дальнейшим заполнением подробной информации о заказе;
  2. быстрый с вводом минимального количества информации.

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

odnoshagovoe-oformlenie-zakaza-v-cs-cart

После этого данный заказ можно будет увидеть в панели администрирования CS-Cart на странице Заказы > Обратный звонок в следующем виде:

cs-cart-obratnyj-zvonok-nastrojka

Всё, что вам останется, как администратору, — это связаться с покупателем по указанному email или телефону, чтобы выяснить, как клиент будет оплачивать покупку, куда и как её доставить.

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

cs-cart-korzina

После нажатия на кнопку Оформить заказ клиент должен будет ввести свои контактные данные (список полей, кстати, редактируется в админке) и указать способ доставки, а также оплаты.

По умолчанию в CS-Cart доставка может осуществляться следующими способами:

  • самовывоз;
  • обсуждение способа с менеджером по телефону;
  • международное почтовое отправление;
  • EMS (Почта России);
  • курьером «до двери»;
  • Почта России.

Первые два способа доступны всегда, остальные же подбираются CS-Cart на основании введённых клиентом контактных данных:

cs-cart-dostavka-pri-zakaze

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

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

Управлять способами доставки в CS-Cart можно в админке на странице Администрирование > Доставка и налоги > Способы доставки. При добавлении нового способа доставки, если выбрать расчёт тарифа в режиме реального времени, появится список доступных в системе служб доставки:

cs-cart-sposob-dostavki-dobavlenie

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

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

cs-cart-sposoby-oplaty-zakaza

Кроме представленного на скриншоте выше есть ещё варианты оплаты с помощью электронных денег (WebMoney, Qiwi, Яндекс.Деньги), квитанциями от Сбербанка, переводом денег с мобильного счёта и т.д., которые находятся на соседних вкладках Интернет платежи и Другие варианты оплаты.

Настройка способов оплаты в CS-Cart производится в панели администрирования на странице Администрирование > Способы оплаты. Для добавления нового способа нужно нажать на привычную кнопочку с плюсиком и заполнить следующую форму:

cs-cart-nastrojka-sposobov-oplaty

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

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

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

cs-cart-detali-zakaza-dlya-klienta

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

Ну, и возможность печати заказа, сохранения в PDF и открытия переписки с менеджером именно по данному заказу также не может не радовать 🙂

Для вас же, как для администратора магазина, детали заказа будут выглядеть так:

cs-cart-status-zakaza-dlya-administratora

Тут, кроме всего прочего есть даже отображение адреса доставки на Яндекс.Картах, а также возможность изменения в CS-Cart статуса заказа и перевода его на определённого менеджера.

Список же всех совершенных через магазин заказов можно посмотреть в админке CS-Cart на стартовой странице (дашборде) и на Заказы > Все заказы.

Расширение функционала CS-Cart

Итак, настройки CS-Cart для наполнения магазина товарами и комфортного произведения заказов клиентами, а также возможности, которые при этом становятся доступными, мы рассмотрели.

Настало время рассказать, как их теперь расширять 🙂

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

Далее я рассмотрю, как оба эти процесса производятся в CS-Cart, где модули и темы можно раздобыть и сколько они стоят.

Установка модулей в CS-Cart

Итак, где можно найти и скачать CS-Cart модули?

Прежде всего, в официальном каталоге дополнений, который доступен по адресу http://marketplace.cs-cart.com/add-ons.html.

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

На данный момент здесь доступно 1287 модулей, совместимых с различными версиями CS-Cart. Цены начинаются от 1$ до 2000$ за модуль Gold Marketplace.

Наиболее крупными производителями CS-Cart аддонов на данный момент являются следующие:

  1. https://store.cart-power.ru/cs-cart-add-ons/ — есть бесплатные CS-Cart модули, цены от 57 до 53541 российских рублей — скорее всего, цены привязаны к курсу, поэтому могут меняться;
  2. http://www.alt-team.ru/cs-cart-modules.html — бесплатных нет, цены от 9$ до 545$, для некоторых есть возможность ввода своей цены;
  3. https://cs-cart.alexbranding.com/ru/ — премиум-партнёр CS-Cart, разработки которого включены даже в официальное демо, есть бесплатные модули, на платные цены начинаются от 30$ и доходят до 299$;
  4. https://www.ecom-labs.ru/cs-cart-multi-vendor-moduli — есть бесплатные CS-Cart модули, цены доходят до 3639 рублей;
  5. https://sweetcart.ru/addons/ — есть бесплатные, цены доходят до 10300 рублей за модуль синхронизации с Авито;

Для демонстрации процесса установки я решил установить бесплатный модуль, добавляющий кнопку «Вверх» на страницы сайта, при нажатии на которую страница пролистывается к самому началу. Качал отсюда — https://marketplace.cs-cart.com/add-ons/customer-experience/cs-cart-up-button-add-on.html?sl=ru

Чтобы добавить модуль в CS-Cart магазин, заходим в админку на страницу Модули > Управление модулями и нажимаем знакомый крестик, после чего откроется следующее окно добавления модуля:

cs-cart-moduli-dobavlenie-novogo

CS-Cart addons должны быть файлами с расширением .tgz, .gz или .zip, которые можно загрузить с диска, сервера магазина (если он туда уже был загружен) или вообще по ссылке.

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

cs-cart-moduli-spisok-v-adminke

И, вместе с этим, на витрине CS-Cart Интернет-магазина появилась обещаемая кнопка «Вверх», которая выглядит так:

cs-cart-addons-na-vitrine

У данного модуля CS-Cart куча настроек, которые я не буду рассматривать, т.к. статья посвящена не ему 🙂 Лучше всего его скачать вам самостоятельно и посмотреть на них своими глазами.

В целом, что я могу сказать по поводу процесса установки модулей CS-Cart? Всё предельно просто и понятно. Если сравнивать данный процесс с установкой модулей OpenCart, то у CS-Cart существует явное преимущество за счёт отсутствия необходимости вникать в нюансы всевозможных VQmod, ocMod и думать каким же из 4 способов нужно устанавливать конкретный аддон.

Установка темы CS-Cart

С установкой CS-Cart тем ситуация во многом похожая с модулями. Наибольший ассортимент CS-Cart themes также представлен официальным каталогом, где на данный момент 374 темы. Среди них есть как бесплатные CS-Cart шаблоны, так и платные. Цены от $10 до $499.

Посмотреть весь список можно здесь — https://marketplace.cs-cart.com/themes.html

Также скачать CS-Cart шаблоны можно на следующих сайтах:

  1. https://store.cart-power.ru/cs-cart-themes/ — уже знакомый по списку ресурсов для скачивания модулей отечественный CS-Cart партнёр и разработчик собственных решений. Цены от 5693 до 11443 российских рублей.
  2. https://themeforest.net/category/ecommerce/cs-cart — оказывается, CS-Cart темы можно найти даже на ThemeForest. Цены в районе $49-63
  3. http://cscarttemplates.com/cs-cart-templates — на данный момент 33 CS-Cart шаблона, цены на все 69 евро
  4. https://www.ecom-labs.ru/temy/ — ассортимент ограничен 4 темами, но, возможно, кому-то подойдёт именно данные варианты. Цены в российских рублях.

Для демонстрации установки я также выбрал бесплатный CS-Cart шаблон, который качал отсюда — https://marketplace.cs-cart.com/themes/cs-cart-theme-free-shoes-orange.html

Обращайте, кстати, особое внимание на версию CS-Cart, с которой совместимы скачиваемые вами шаблоны, иначе все ваши труды и деньги будут напрасны.

Итак, для добавления CS-Cart theme нужно перейти в панели управления на страницу Дизайн >  Темы, нажать на кнопочку с крестиком вверху страницы и через открывшуюся форму загрузить архив с темой.

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

Уж не знаю, чья эта вина — то ли разработчиков CS-Cart, то ли создателей темы, но после установки файлы темы у меня оказались не по пути cscart_каталог/var/themes_repository/, а cscart_каталог/var/themes_repository/var/themes_repository/. В общем, кто-то накосячил с путями 🙂

Для решения проблемы я просто перенёс файл темы в нужную директорию, после чего CS-Cart template появился у меня в админке:

cs-cart-shablony-spisok

После активации необходимого скина (стиля) темы изменения вступят в силу и на витрине ваши покупатели увидят только что установленную вами CS-Cart theme:

cs-cart-temy-na-vitrine

Подкорректировать её, конечно, ещё нужно, но зато моя оранжевая кнопочка «Вверх» идеально вписалась под оранжевые цвета темы 🙂

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

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

Данный подход применим также и к CS-Cart модулям.

Перенос CS-Cart на хостинг

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

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

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

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

По поводу требований к хостингу для CS-Cart магазинов могу сказать, что здесь нет ничего особенного. Подойдёт практически любой из ныне существующих, главное, чтобы они поддерживали PHP, Apache и MySQL. Для выяснения деталей рекомендую обратиться к техническим характеристикам CS-Cart, ссылку на которые я указывал в начале статьи.

Для демонстрации процесса я решил развернуть CS-Cart магазин на поддомене своего сайта — cscart.cccp-blog.com.

Итак, переезд CS-Cart с одного сервера на другой начинается с копирования файлов сайта по FTP/SSH (для ускорения можете запаковать их в архив, если на удалённом сервере есть деархиватор). Лично я пользуюсь старым-добрым FileZilla.

После завершения копирования, пока FTP-клиент у нас ещё открыт, меняем права на директории design, images и var с 755 на 777, а для файла config.local.php устанавливаем 666 вместо 644.

Далее нам нужно будет сделать дамп БД на нашем локальном сервере и развернуть из него базу на хостинге.

Если вы будете испытывать с этим какие-то сложности, то рекомендую к просмотру следующее видео, где помимо упомянутого момента рассматриваются другие детали установки CS-Cart на хостинг:

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

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

У моего хостинг-провайдера TheHost, например, он выглядит так:

cs-cart-nastrojki-perenosa-na-hosting

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

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

cs-cart-hosting-nastrojki

Сохраняемся и после этого заходим в панель администратора CS-Cart магазина уже на новом сайте. По идее, если вы всё сделали верно, вы увидите форму авторизации.

С витриной у CS-Cart дела обстоят немного сложнее. Несмотря на все введённые нами ранее настройки, при входе в витрину сайта на хостинге перед нами будет следующая ошибка:

cs-cart-perenos-magazina-na-hosting

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

Чтобы исправить эту ошибку, идём в панель администрирования на страницу Администрирование > Магазины, выбираем наш текущий магазин и меняем значения в полях URL витрины и безопасный URL витрины, указывая в них новое доменное имя вашего магазина.

Также эти значения можно поменять напрямую в БД. Как это сделать, подробно описано на видео, которое я приводил в тексте статьи ранее.

В итоге, после всех манипуляций сайт будет доступен по новому URL. В моём случае это, напомню, cscart.cccp-blog.com, которым вы можете насладиться, пока не закончилась моя 30-дневная пробная лицензия 🙂

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

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

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

Если материала в статье вам оказалось мало, и вы хотите большего, то рекомендую вам принять участие в отличном проекте, организованном командой CS-Cart — CS-Cart eCommerce reality show, более подробно о котором вы можете узнать, а также получить доступ ко всем его выпускам здесь — https://www.cs-cart.ru/ecomshow

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

Лично я считаю, что идея очень интересная, увлекательная (аплодисменты маркетологам CS-Cart) и весьма полезная с практической точки зрения, особенно для начинающих предпринимателей.

Ведущим проекта выступил опытный eCommerce предприниматель Александр Верес, который в ходе шоу поделился своим опытом и организовал проект — bokal.ru, успешно функционирующий по сегодняшний день.

О том, кто это такой и что он планирует рассказывать в рамках ecomshow, вы можете узнать из следующего видео:

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

Всем удачного запуска и крупных продаж!

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

the_posts_pagination(array( 'mid_size' => 3, 'prev_text' => __('« Предыдущая'), 'next_text' => __('Следующая »') ));