Что такое middleware laravel
Middleware
Introduction
Middleware provide a convenient mechanism for inspecting and filtering HTTP requests entering your application. For example, Laravel includes a middleware that verifies the user of your application is authenticated. If the user is not authenticated, the middleware will redirect the user to your application’s login screen. However, if the user is authenticated, the middleware will allow the request to proceed further into the application.
Additional middleware can be written to perform a variety of tasks besides authentication. For example, a logging middleware might log all incoming requests to your application. There are several middleware included in the Laravel framework, including middleware for authentication and CSRF protection. All of these middleware are located in the app/Http/Middleware directory.
Defining Middleware
To create a new middleware, use the make:middleware Artisan command:
This command will place a new EnsureTokenIsValid class within your app/Http/Middleware directory. In this middleware, we will only allow access to the route if the supplied token input matches a specified value. Otherwise, we will redirect the users back to the home URI:
It’s best to envision middleware as a series of «layers» HTTP requests must pass through before they hit your application. Each layer can examine the request and even reject it entirely.
All middleware are resolved via the service container, so you may type-hint any dependencies you need within a middleware’s constructor.
Middleware & Responses
Of course, a middleware can perform tasks before or after passing the request deeper into the application. For example, the following middleware would perform some task before the request is handled by the application:
However, this middleware would perform its task after the request is handled by the application:
Registering Middleware
Global Middleware
Assigning Middleware To Routes
Once the middleware has been defined in the HTTP kernel, you may use the middleware method to assign middleware to a route:
You may assign multiple middleware to the route by passing an array of middleware names to the middleware method:
When assigning middleware, you may also pass the fully qualified class name:
Excluding Middleware
When assigning middleware to a group of routes, you may occasionally need to prevent the middleware from being applied to an individual route within the group. You may accomplish this using the withoutMiddleware method:
You may also exclude a given set of middleware from an entire group of route definitions:
The withoutMiddleware method can only remove route middleware and does not apply to global middleware.
Middleware Groups
Out of the box, Laravel comes with web and api middleware groups that contain common middleware you may want to apply to your web and API routes. Remember, these middleware groups are automatically applied by your application’s App\Providers\RouteServiceProvider service provider to routes within your corresponding web and api route files:
Middleware groups may be assigned to routes and controller actions using the same syntax as individual middleware. Again, middleware groups make it more convenient to assign many middleware to a route at once:
Sorting Middleware
Middleware Parameters
Middleware can also receive additional parameters. For example, if your application needs to verify that the authenticated user has a given «role» before performing a given action, you could create an EnsureUserHasRole middleware that receives a role name as an additional argument.
Terminable Middleware
Sometimes a middleware may need to do some work after the HTTP response has been sent to the browser. If you define a terminate method on your middleware and your web server is using FastCGI, the terminate method will automatically be called after the response is sent to the browser:
The terminate method should receive both the request and the response. Once you have defined a terminable middleware, you should add it to the list of routes or global middleware in the app/Http/Kernel.php file.
When calling the terminate method on your middleware, Laravel will resolve a fresh instance of the middleware from the service container. If you would like to use the same middleware instance when the handle and terminate methods are called, register the middleware with the container using the container’s singleton method. Typically this should be done in the register method of your AppServiceProvider :
Laravel Framework Russian Community
Prologue
Getting Started
Architecture Concepts
The Basics
Frontend
Security
Digging Deeper
Database
Eloquent ORM
Testing
Official Packages
Middleware
Introduction
Middleware provide a convenient mechanism for filtering HTTP requests entering your application. For example, Laravel includes a middleware that verifies the user of your application is authenticated. If the user is not authenticated, the middleware will redirect the user to the login screen. However, if the user is authenticated, the middleware will allow the request to proceed further into the application.
Additional middleware can be written to perform a variety of tasks besides authentication. A CORS middleware might be responsible for adding the proper headers to all responses leaving your application. A logging middleware might log all incoming requests to your application.
There are several middleware included in the Laravel framework, including middleware for authentication and CSRF protection. All of these middleware are located in the app/Http/Middleware directory.
Defining Middleware
To create a new middleware, use the make:middleware Artisan command:
This command will place a new CheckAge class within your app/Http/Middleware directory. In this middleware, we will only allow access to the route if the supplied age is greater than 200. Otherwise, we will redirect the users back to the home URI:
It’s best to envision middleware as a series of «layers» HTTP requests must pass through before they hit your application. Each layer can examine the request and even reject it entirely.
All middleware are resolved via the service container, so you may type-hint any dependencies you need within a middleware’s constructor.
Before & After Middleware
Whether a middleware runs before or after a request depends on the middleware itself. For example, the following middleware would perform some task before the request is handled by the application:
However, this middleware would perform its task after the request is handled by the application:
Registering Middleware
Global Middleware
Assigning Middleware To Routes
Once the middleware has been defined in the HTTP kernel, you may use the middleware method to assign middleware to a route:
You may also assign multiple middleware to the route:
When assigning middleware, you may also pass the fully qualified class name:
When assigning middleware to a group of routes, you may occasionally need to prevent the middleware from being applied to an individual route within the group. You may accomplish this using the withoutMiddleware method:
The withoutMiddleware method can only remove route middleware and does not apply to global middleware.
Middleware Groups
Out of the box, Laravel comes with web and api middleware groups that contain common middleware you may want to apply to your web UI and API routes:
Middleware groups may be assigned to routes and controller actions using the same syntax as individual middleware. Again, middleware groups make it more convenient to assign many middleware to a route at once:
Sorting Middleware
Middleware Parameters
Middleware can also receive additional parameters. For example, if your application needs to verify that the authenticated user has a given «role» before performing a given action, you could create a CheckRole middleware that receives a role name as an additional argument.
Terminable Middleware
Sometimes a middleware may need to do some work after the HTTP response has been sent to the browser. If you define a terminate method on your middleware and your web server is using FastCGI, the terminate method will automatically be called after the response is sent to the browser:
# Middleware
If we look at an incoming HTTP request, this request is processed by Laravel’s index.php file and sent through a series of pipelines. These include a series of (‘before’) middleware, where each will act on the incoming request before it eventually reaches the core of the application. A response is prepared from the application core, which is post-modified by all registered ‘after’ middleware before returning the response.
That’s why middleware is excellent for authentication, verifying tokens, or applying any other check. Laravel also uses middleware to strip out empty characters from strings and encrypt cookies.
# Creating Middleware
There are two types of middleware: 1) acting on the request before a response is returned («Before Middleware»); or 2) acting on the response before returning («After Middleware»).
Before discussing the two types of middleware, first create a new Middleware folder in the package’s src/Http directory.
# Before Middleware
A before middleware performs an action on the request and then calls the next middleware in line. Generally, a Before Middleware takes the following shape:
As an illustration of a before middleware, let’s add a middleware that capitalizes a ‘title’ parameter whenever present in the request (which would be silly in a real-world application).
# Testing Before Middleware
Although we haven’t registered the middleware yet, and it will not be used in the application, we want to make sure that the handle() method shows the correct behavior.
Add a new CapitalizeTitleMiddlewareTest.php unit test in the tests/Unit directory. In this test, we’ll assert that a title parameter on a Request() will contain the capitalized string after the middleware ran its handle() method:
# After Middleware
The «after middleware» acts on the response returned after passing through all other middleware layers down the chain. Next, it modifies, and returns the response. Generally, it takes the following form:
# Testing After Middleware
Similar to before middleware, we can unit test after middleware that operate on the Response for a given request and modify this request before it is passed down to the next layer of middleware. Given that we have an InjectHelloWorld middleware that injects the string ‘Hello World’ in each response, the following test would assert correct behavior:
Now that we know the handle() method does its job correctly, let’s look at the two options to register the middleware: globally vs. route specific.
# Global middleware
Global middleware is, as the name implies, globally applied. Each request will pass through these middlewares.
If we want our capitalization check example to be applied globally, we can append this middleware to the Http\Kernel from our package’s service provider. Make sure to import the Http Kernel contract, not the Console Kernel contract:
This will push our middleware into the application’s array of globally registered middleware.
# Route middleware
In our case, you might argue that we likely don’t have a ‘title’ parameter on each request. Probably even only on requests that are related to creating/updating posts. On top of that, we likely only ever want to apply this middleware to requests related to our blog posts.
However, our example middleware will modify all requests which have a title attribute. This is probably not desired. The solution is to make the middleware route-specific.
Therefore, we can register an alias to this middleware in the resolved Router class, from within the boot() method of our service provider.
Here’s how to register the capitalize alias for this middleware:
We can apply this middleware from within our controller by requiring it from the constructor:
# Middleware Groups
To do so, tell the router to push the middleware to a specific group (in this example, web ):
The route middleware groups of a Laravel application are located in the App\Http\Kernel class. When applying this approach, you need to be sure that this package’s users have the specific middleware group defined in their application.
# Feature Testing Middleware
Regardless of whether we registered the middleware globally or route specifically, we can test that the middleware is applied when making a request.
Add a new test to the CreatePostTest feature test, in which we’ll assume our non-capitalized title will be capitalized after the request has been made.
With the tests returning green, we’ve covered adding Middleware to your package.
Вступление
Промежуточное программное обеспечение предоставляет удобный механизм фильтрации HTTP-запросов, поступающих в ваше приложение. Например, Laravel включает промежуточное программное обеспечение, которое проверяет подлинность пользователя вашего приложения. Если пользователь не аутентифицирован, промежуточное программное обеспечение перенаправит пользователя на экран входа в систему. Однако, если пользователь аутентифицирован, промежуточное программное обеспечение позволит запросу продолжить работу в приложении.
Дополнительное промежуточное программное обеспечение может быть написано для выполнения различных задач, помимо аутентификации. Промежуточное программное обеспечение CORS может отвечать за добавление правильных заголовков ко всем ответам, покидающим ваше приложение. Промежуточное программное обеспечение может регистрировать все входящие запросы к вашему приложению.
В инфраструктуру Laravel включено несколько промежуточных программ, в том числе промежуточное ПО для аутентификации и защиты CSRF. Все эти промежуточные программы находятся в каталоге. app/Http/Middleware
Определение промежуточного программного обеспечения
Чтобы создать новое промежуточное программное обеспечение, используйте команду Artisan: make:middleware
Эта команда поместит новый CheckAge класс в ваш каталог. В этом промежуточном программном обеспечении мы будем разрешать доступ к маршруту только в том случае, если он превышает 200. В противном случае мы перенаправим пользователей обратно на URI: app/Http/Middleware age home
Лучше всего представить промежуточное ПО, поскольку ряд «слоев» HTTP-запросов должен пройти до того, как они попадут в ваше приложение. Каждый уровень может изучить запрос и даже полностью отклонить его.
До и после промежуточного программного обеспечения
Работает ли промежуточное программное обеспечение до или после запроса, зависит от самого промежуточного программного обеспечения. Например, следующее промежуточное программное обеспечение будет выполнять некоторую задачу перед обработкой запроса приложением:
Тем не менее, это промежуточное программное обеспечение будет выполнять свою задачу после обработки запроса приложением:
Регистрация Middleware
Назначение промежуточного программного обеспечения для маршрутов
После того, как промежуточное ПО было определено в ядре HTTP, вы можете использовать middleware метод для назначения промежуточного ПО для маршрута:
Вы также можете назначить несколько промежуточных программ для маршрута:
При назначении промежуточного программного обеспечения вы также можете передать полное имя класса:
Группы промежуточного программного обеспечения
Из коробки поставляется Laravel web и api группы промежуточного программного обеспечения, которые содержат общее промежуточное программное обеспечение, которое вы можете применить к своим веб-интерфейсам и маршрутам API:
Группы промежуточного программного обеспечения могут быть назначены маршрутам и действиям контроллера с использованием того же синтаксиса, что и отдельное промежуточное программное обеспечение. Опять же, группы промежуточного ПО делают более удобным назначение сразу нескольких промежуточных программ для маршрута:
Параметры промежуточного программного обеспечения
Промежуточное программное обеспечение также может получать дополнительные параметры. Например, если вашему приложению необходимо проверить, что прошедший проверку пользователь имеет заданную «роль» перед выполнением заданного действия, вы можете создать CheckRole промежуточное программное обеспечение, которое получает имя роли в качестве дополнительного аргумента.
Завершаемое промежуточное ПО
Иногда промежуточному программному обеспечению может потребоваться выполнить некоторую работу после подготовки ответа HTTP. Например, промежуточное программное обеспечение сеанса, включенное в Laravel, записывает данные сеанса в хранилище после полной подготовки ответа. Если вы определяете terminate метод в своем промежуточном программном обеспечении, он будет автоматически вызываться после того, как ответ будет готов к отправке в браузер.
terminate Метод должен получить как запрос и ответ. После того, как вы определили промежуточное промежуточное ПО, вы должны добавить его в список маршрутов или глобального промежуточного ПО в файле. app/Http/Kernel.php
Laravel middleware: разрабатываем Laravel breadcrumbs
Всем привет! 🙂
Мы продолжаем создание сайта на Laravel, и сегодняшняя статья будет посвящена знакомству с Laravel middleware.
Я не просто расскажу, что это за штука такая, но и приведу пример её использования, создав с помощью данной конструкции Laravel breabcrumbs («хлебные крошки» по-русски), в которых так нуждается наш сайт.
Ну, и по ходу написания материала я пройдусь по всему нашему сайту целиком, попутно исправляя ошибки фронтэнда, чтобы закончить с визуальной составляющей и перейти к функционалу: созданию контроллеров, админки, моделей, миграций, чему будут посвящены будущие публикации.
Поэтому подписывайтесь на обновления проекта, чтобы быть в курсе новых публикаций.
Знакомимся с Laravel middleware
Итак, что такое Laravel middleware?
По сути, данная конструкция служит для фильтрации HTTP-запросов, поступающих приложению. Middleware является промежуточным звеном (в переводе с англ. middleware — «промежуточный слой») между запросом к приложению и действием, которое должно происходить при приёме его фреймворком.
Таким образом, Laravel middleware можно использовать для проведения различных проверок подлинности url перед выполнением соответствующего действия, авторизации пользователей, ролей пользователей для совершения действий, в зависимости от результатов проверки.
Использование Laravel middleware для проверки авторизации пользователя я обязательно вам продемонстрирую в дальнейшем. Сегодня же я решил с помощью данного механизма реализовать хлебные крошки, которые будут основаны на распарсивании текущего url.
Честно говоря, для данной задачи middleware – не самое лучшее решение, т.к. передача итогового массива с «хлебными крошками» в представление (view) потребует от нас определённых танцев с бубном 🙂
Более простым и аккуратным с точки зрения чистоты кода были бы способы реализации с помощью контроллеров и конструкции View::composer. Но, несмотря на это, я решил прибегнуть к middleware, как говорится, в академических целях, чтоб познакомить вас с этим функционалом, который появился в Laravel, кстати, совсем недавно – в 5 версии.
Так что, использовать следующие куски кода в реальных проектах вовсе не обязательно, и если вы знаете что-то получше, то поделитесь этим в комментариях под статьёй со мной и со всеми остальными.
Ну что же, начинаем.
Создание и настройка Laravel middleware
Для начала нам необходимо создать сам файл middleware. Можно, конечно сделать его вручную на основе существующих образцов, которые идут в Laravel по умолчанию, но правильнее будет воспользоваться Laravel artisan.
Laravel artisan — это консоль Laravel, в которой можно манипулировать движком путём запуска специальных команд. С помощью Laravel artisan можно создавать контроллеры, модели, middleware, миграции, а также очищать кэш, совершать различные действия с БД и т.д.
Для того, чтобы запустить artisan, необходимо перейти в каталог Laravel проекта в консольном режиме, для чего сперва запускаем консоль на вашем локальном или удалённом сервере.
Если вы не в первый раз читаете мой блог, то могли обратить внимание, что я работаю под Windows и являюсь сторонником WAMP-сборки OpenServer. Следовательно, в моём случае, запуск консоли на сервере будет происходить следующим образом:
Если же вы пользуетесь другой WAMP, LAMP, MAMP сборкой или XAMPP, то для запуска консоли в данном случае изучайте соответствующие официальные руководства. Ну, а если вы используете чистые Apache/Nginx + PHP + MySQL, установленные на вашей локальной или виртуальной машине/хостинге, то вам достаточно запустить системную консоль.
Допустим, у вас всё получилось.
Далее переходим в каталог вашего Laravel сайта с помощью команды консоли cd:
Ну, и теперь мы можем пользоваться artisan. Для начала проверим, работает ли он у вас (ввиду различных причин artisan может не запуститься) и вводим команду
Если всё в порядке, то вы увидите версию Laravel, на базе которой вы создали своё проект. Если нет, то первым делом проверьте список требований, необходимых для работы Laravel, а если с требованиями всё «ОК», а проблема существует, то пишите о ней в комментариях — постараюсь вам помочь.
Кстати, для просмотра всех команд, доступных в artisan, достаточно запустить следующую:
В дальнейшем мы воспользуемся большей их частью, а сейчас же, для создания файла middleware, ограничимся следующей:
Для просмотра доступных параметров команды достаточно добавить в конце —help. У данной команды всего один аргумент — это имя Laravel middleware, которое в моём случае будет BreadCrumbs:
Если у вас возникли какие-то проблемы на данном этапе (а это вполне возможно), также не стесняйтесь делиться ими в комментариях. В итоге, у нас автоматически создался файл app/Http/Middleware/BreadCrumbs.php со следующим базовым кодом:
Из коробки у Laravel уже есть, кстати, группы web и api, так что перед созданием своей группы проверьте, возможно, всё необходимое вам уже есть 🙂
Всё, необходимые приготовления мы сделали. Теперь займёмся кодом самого Laravel middleware.
Созданию хлебных крошек на PHP я уже посвятил отдельную статью по приведённой ссылке. Поэтому всё, что нам нужно сделать, — это скопировать итоговый код оттуда и вставить в наш созданный Laravel middleware.
Принцип создания «хлебных крошек» там заключался в разбивке текущего url на сегменты (по слэшам) и сборке итоговой навигационной цепочки, заменяя название сегмента на подготовленное название.
Названия сегментов url хранятся в обычном массиве PHP, хотя, лучше бы было, конечно, хранить и брать их из БД. Сейчас у нас нет записей в БД для отдельных страниц сайта, поэтому мы ограничимся текущим способом. В дальнейшем, возможно, я модифицирую код.
В итоге, наш Laravel middleware должен принять следующий вид:
Поскольку я планирую постепенно, по мере наполнения контентом, переводить сайт на русский, то наименования в хлебных крошках я решил сделать на русском.
В будущем, по вашим пожеланиям, я также могу подготовить мультиязычную версию сайта, сделав возможность выбирать пользователям язык интерфейса самостоятельно.
Так что пишите в комментариях, стоит ли мне этим заниматься или нет.
Использование Laravel middleware и breadcrumbs в коде
Итак, мы создали и зарегистрировали Laravel middleware, теперь самое время воспользоваться им 🙂
Пользоваться ими можно тремя различными способами.
Способ 1: применение middleware к отдельным правилам роутинга Laravel
Прежде всего, Laravel позволяет применять middleware к отдельным правилам роутинга, описанным в файле routes/web.php (в версиях до Laravel 5.3 это app/Http/routes.php). Производится это с помощью следующей конструкции:
Способ 2: применение middleware к группам роутов
Данный способ позволяет применять один, несколько Laravel middleware или целые их группы сразу к нескольким правилам роутинга, оформленным в виде группы. Для этого необходима данная конструкция:
Указывая middleware для группы роутов, можно также указывать префикс для данных роутов и прочие параметры, которые можно найти в официальной документации.
Способ 3: использование middleware в контроллерах
О манипуляциях с контроллерами Laravel я ещё расскажу вам в дальнейшем, но о том, как использовать в них middleware, решил сейчас, раз уж затронул эту тему.
Итак, помимо роутов, middleware можно применять как ко всем методам контроллера, так и к определённым, указывая это в конструкторе контроллера, внутри «магического метода» __construct следующим образом:
Из всех приведённых способов для хлебных крошек нам вполне будет достаточно первого, т.к. роут для всех страниц сайта у нас один (кроме главной, для которой нам Laravel breadcrumbs и не надо), следовательно, для него мы и будем применять наш middleware:
Следовательно, передача «хлебных крошек» будет происходить посредством записи их в атрибуты запроса с помощью следующего кода:
Код прописываем в самом конце файла app/Http/Middleware/BreadCrumbs.php, перед функцией возврата итогового значения:
Поскольку middleware является, по сути, фильтром запроса, который накладывается до или после его обработки (в нашем случае — до), то мы теперь можем извлечь наш массив с «хлебными крошками» из атрибутов запроса ещё до того, как он обработается и вернёт результат на экран.
В итоге, наше правило роутинга для страниц сайта, кроме главной, примет следующий вид:
Теперь, благодаря автоматическому формированию «хлебных крошек», мы наконец сможем придать их выводу на странице человеческий вид 🙂 Напомню, что сейчас у нас на каждой странице сайта определена секция «breadcrumbs» в виде:
Содержимое секций подставляется на место директивы blade шаблонизатора @yield в файле resources/views/layouts/breadcrumbs.blade.php:
А сам шаблон «хлебных крошек» подключается в главном макете _layout.blade.php перед блоком контента:
Поскольку у нас теперь в наличии массив с «хлебными крошками», который может быть доступен из любого шаблона, наиболее правильным решением будет:
Этим мы и займёмся.
Если же url не указан – значит, проверяемый элемент соответствует текущей странице, поэтому его в ссылку не оборачиваем.
Итак, если вы всё сделали правильно, то можно открывать любую страницу сайта в браузере и любоваться плодами своих трудов 🙂 К примеру, блок «хлебных крошек» на странице «Портфолио» примет следующий вид:
Хм… что-то тут явно не так. Почему-то элементы у нас одинакового цвета – и текущий и предыдущие, которые оформлены ссылками. При наведении на ссылочный элемент курсор меняется – значит, ссылка есть.
Для выделения сделаем его текст подчёркнутым, чтобы пользователи сайта не ломали голову над тем, как пользоваться такими «хлебными крошками».
Для этого открываем файл style.css и в блоке свойств для селектора #inner-headline ul.breadcrumb li a дописываем свойство text-decoration: underline. Если интересно, как я нашёл css-селектор требуемого элемента, то читайте об этом в статье «Меняем интерфейс сайта самостоятельно».
После данный манипуляций «крошки» станут более привлекательными:
Вот, собственно говоря, и всё. Осталось только «размножить» наши обновлённые «хлебные крошки» для других страниц сайта, но это я рассматривать не буду, т.к. всё будет происходить по аналогии с вышеописанным примером.
И вся работа, по сути, будет заключаться в банальном удалении секций «хлебных крошек» из шаблонов страниц сайта, поэтому данные действия снова остаются вам на домашнее задание.
Ну, а в завершение данной статьи я решил ещё раз пройтись по страницам нашего будущего сайта в целях поиска багов и недоработок, чтобы в дальнейшем сконцентрироваться исключительно на бэкэнд-коде.
Отдельной статьёй эти правки я решил не оформлять, но и не описать ход действий тоже не смог, чтобы у вас в дальнейшем не возникало вопросов «Почему у него всё работает, а у меня поломанное, хотя делал всё по статье?» 🙂 Меня самого сильно раздражают такие ситуации, когда всё делаешь по мануалам, а потом получаешь не тот результат, что у автора, потому что он не описал какую-то важную мелочь.
Я решил не уподобляться и привести весь порядок действий.
Итак, что же мне удалось обнаружить?
Фронтэнд доработки Laravel шаблона
В первую очередь, я обратил внимание, что в данной теме не работает подсветка активного пункта меню. Я решил исправить этот баг, используя код из статьи по ссылке выше.
Если вы её раньше читали, то могли обратить внимание, что принцип подсветки активного пункта меню с помощью jQuery заключался в проверке текущего url страницы и ссылок в главном меню. Если они совпадали, то пункт, содержащий ссылку на текущую страницу, выделялся.
Для этого, первым делом, нам нужно как-то найти пункты главного меню в JS-коде. Самый простой способ это сделать — добавить меню какой-то уникальный идентификатор.
Для этого идём в файл resources\views\layouts\header.blade.php нашего Laravel проекта, ищем там ul navbar-nav» и добавляем ему какой-нибудь уникальный идентификатор. И ещё я решил прописать адреса ссылок в виде абсолютных url, воспользовавшись Laravel хэлпером url();
Также, попутно я решил перевести элементы меню на русский язык. В моём случае получилось следующее меню:
Теперь нам нужен JavaScript-код для подсветки активного пункта. По своей старой привычке, я решил сделать файлик app.js, в котором обычно хранится JS-код сайта, да только в Laravel такой файл есть по умолчанию с минифицированными и скомпонованными Bootstrap и jQuery.
Поскольку данные компоненты идут вместе с шаблоном, я решил очистить стандартный файл app.js и хранить в нём свой пользовательский код, т.к. новые версии компонентов могут не сочетаться с кодом шаблона, поэтому лучше использовать те библиотеки, которые идут в комплекте с шаблоном.
Следовательно, в шаблоне resources/views/layouts/scripts.blade.php, в котором у нас содержится список скриптов, которые мы подключаем, добавляем следующую строчку:
Лучше всего прописать это в самом конце документа, т.к. он использует jQuery, который подключается в самом начале, следовательно, наш код должен идти после него.
Файл public/css/app.css, который содержит минифицированный Bootstrap, я решил пока что вовсе удалить, т.к. в нём также нет надобности.
Итак, вставляем код из статьи о выделении активного пункта меню с помощью jQuery в файл app.js, поменяв id главного меню и имя класса активного элемента на наши значения.
А также я внёс небольшие правки для того, чтобы сделать наш сайт более SEO-дружелюбным: убрал циклические ссылки, т.е. ссылки со страницы на саму себя. Для этого я просто удалил ссылку с текущего элемента.
Ну, и поскольку адреса ссылок в нашем меню — это абсолютные url, то пришлось написать функцию, формирующую их в JavaScript.
В итоге, получился следующий код:
После установки всё будет работать за исключением небольшого бага – при загрузке страницы у нас пункт меню “Home” подсвечивается голубым, а потом подсветка исчезает и выделяется текущий пункт меню.
Этот «прыгающий эффект» присутствует из-за того, что у главного пункта меню в шаблоне прописан класс «active», поэтому удаляем его. Теперь текущий пункт меню становится активным без всяких «прыжков».
Отлично, с этим моментом разобрались.
Из оставшихся багов были следующие, код которых я приводить не буду:
Данные правки я не стал детально описывать, т.к. необходимость их внесения чисто моя субъективная, вы же в праве обойтись и без них. Ну, и чтобы не захламлять текст статьи лишним кодом, который вы и так можете посмотреть на GitHub 🙂
Кстати, напоминаю, что код создаваемого нами Laravel сайта находится на GitHub, а сегодняшние правки вы можете найти на нём в виде второго и третьего коммитов.
В качестве критики сегодняшней статьи многие могут возразить, что в масштабах нашего веб-ресурса пользы от программных «хлебных крошек», которыми я решил заморочиться, вообще нет, т.к. они будут содержать одну-единственную ссылку на главную страницу — вполне можно было бы обойтись хардкодом (т.е. прописать на каждой странице вручную).
Но, стоит только на сайте появиться ещё одному уровню вложенности страниц (подкатегория или отдельная страница, открываемая со страницы категории), так сразу наши старания станут заметными, особенно для поисковиков 🙂
Кстати, в ближайшем будущем данное событие намечается, т.к. впереди у нас по плану создание блога, встроенного в наш сайт-визитку, и придание функциональности нашей контактной форме.
Поэтому подписывайтесь на обновлениями проекта, всё самое интересное вас ждёт впереди 🙂
Также не забывайте делиться записью со своими друзьями в социальных сетях – не знаю как им, а мне точно будет это приятно, т.к. данным образом вы окажете поддержку нашему проекту, существование которого держится на моём полном энтузиазме.
На этом сегодня я с вами прощаюсь, удачи вам в начинаниях и до новых встреч 🙂
P.S.: если вам нужен сайт либо необходимо внести правки на существующий, но для этого нет времени и желания, могу предложить свои услуги.
Более 5 лет опыта профессиональной разработки сайтов. Работа с PHP, OpenCart, WordPress, Laravel, Yii, MySQL, PostgreSQL, JavaScript, React, Angular и другими технологиями web-разработки.
Опыт разработки проектов различного уровня: лендинги, корпоративные сайты, Интернет-магазины, CRM, порталы. В том числе поддержка и разработка HighLoad проектов. Присылайте ваши заявки на email cccpblogcom@gmail.com.
И с друзьями не забудьте поделиться 😉