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

Автор: | 12.05.2017

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

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

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

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

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

Поехали :-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

openserver-zapusk-konsoli

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

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

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

laravel-breadcrumbs-perehodim-v-katalog-sajta

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


php artisan --version

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

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


php artisan --list

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


php artisan make:middleware

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

Sozdanie-laravel-middleware-cherez-artisan

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


<?php

namespace App\Http\Middleware;

use Closure;

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

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

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


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

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


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

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

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

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

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

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

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


<?php

namespace App\Http\Middleware;

use Closure;

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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


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

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


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

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

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


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

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


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

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

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

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


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

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

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


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

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


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

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


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

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

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

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

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

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


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

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

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

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

laravel-breadcrumbs-hlebnye-kroshki-pokazyvayutsya-nepravilno

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

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

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

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

laravel-breadcrumbs-finalnyj-variant

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. 5
  2. 4
  3. 3
  4. 2
  5. 1
5 голосов, в среднем: 5 из 5

4 комментария к статье "Laravel middleware: разрабатываем Laravel breadcrumbs"

  1. Edred

    Странное дело… Параллельно чтению урока делаю все сам на хостинге. И тестирую. Получаю ошибку, что класс Breadcrumbs не существует, начинаю разбираться и понимаю, что класс создавался BreadCrumbs, а в Kernel.php вписан Breadcrumbs. Просто в уроке неточно написано. Поправил, ошибка о несуществующем классе пропала. Правда, вместо «хлебных крошек» выводится просто черная полоса, но это сейчас еще буду разбираться, пишу же не об этом.

    Я решил скачать с Гитхаба проект, чтобы посмотреть как там назван класс Breadcrumbs — с заглавной C или с маленькой. А там в точности как здесь, в уроке — класс назван BreadCrumbs, а в Kernel.php прописан как Breadcrumbs. И поэтому вопрос: то ли названия классов только у меня регистрозависимые, то ли на Гитхабе лежит нерабочий проект. И вообще странно, что за четыре месяца никто не написал комментарий о ошибке в регистре букв названия класса…

    1. Pashaster Автор

      Ну, видимо народ не делает сайт по изложенной инструкции, раз не заметили :-) А так спасибо за уточнение, лучше поменяю в коде от греха подальше, т.к. большинство современных хостингов использует сейчас Linux-сервера. Ну, лишь за исключением, когда хостить нужно C# .Net сайты, которые к Windows привязаны намертво.

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

  2. Edred

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

    1. Pashaster Автор

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *