Физическое наступление. Нюансы и настройки.

Mar 20, 03:14 am Категория:

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

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

Кстати, сосредоточение всех файлов проекта в одном месте иногда провоцирует создать здесь директорию-другую для складирования всякого мусора не отходя от кассы. Серьёзных противопоказаний к таким действиям я не встречал. Разумеется, если эти временные файлы не отправлять в git репозиторий или на продуктовый сервер. Но ведь не получится, да? А значит правильнее в директорию проекта лишнее не нести.

Настройки Laravel сосредоточены в двух местах: файл .env и директория config. Логика такая: в config идут “постоянные” настройки, не зависящие от места запуска. А в .env хранятся локальные, относящиеся к конкретному серверу настройки. Далее локальные настройки используются фреймворком, если они заданы. А если нет, то используются умолчания. Вот пример задания опции debug в файле config/app.php

'debug' => env('APP_DEBUG', false),

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

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

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

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

[polygon@ihhi ihhi.dev]$ ./artisan migrate
Migration table created successfully.
Migrated: 2014_10_12_000000_create_users_table
Migrated: 2014_10_12_100000_create_password_resets_table

Команда ./artisan migrate выполнена успешно, Laravel связался с базой, создал таблицу миграций и “накатил” две миграции, идущие с фреймворком в комплекте.

[polygon@ihhindex ihhi.dev]$ ./artisan make:auth
Created View: /www/dev/ihhindex/ihhi.dev/resources/views/auth/login.blade.php
Created View: /www/dev/ihhindex/ihhi.dev/resources/views/auth/register.blade.php
Created View: /www/dev/ihhindex/ihhi.dev/resources/views/auth/passwords/email.blade.php
Created View: /www/dev/ihhindex/ihhi.dev/resources/views/auth/passwords/reset.blade.php
Created View: /www/dev/ihhindex/ihhi.dev/resources/views/auth/emails/password.blade.php
Created View: /www/dev/ihhindex/ihhi.dev/resources/views/layouts/app.blade.php
Created View: /www/dev/ihhindex/ihhi.dev/resources/views/home.blade.php
Created View: /www/dev/ihhindex/ihhi.dev/resources/views/welcome.blade.php
Installed HomeController.
Updated Routes File.
Authentication scaffolding generated successfully!

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

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

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

Хостер не даёт доступа к консоли. Меняем хостера. То же самое, если не получается установить Composer, ограничиваются исходящие соединения и т.п. Хостеров много, а времени мало. Не тратим его. Проходим дальше, проходим.

Панель создаёт директорию проекта и его внутреннюю структуру, но не позволяет в эту директорию установить Laravel с помощью Composer или родного установщика. Необходимо загрузить свежую версию с GitHub, разархивировать в директорию проекта и последовательно выполнить две команды.

composer update
php artisan key:generate

Панель управления хостингом назначает корнем сайта директорию типа public_html, htdocs, web и т.п. Есть два пути решения проблемы. Самый простой, создать символическую ссылку корня сайта с именем public в директории проекта. Второй путь, изменить настройки Laravel и в файле config/filesystems.php указать корень сайта панели. При любых вариантах нужно отработать процесс деплоя приложения на боевой сервер, чтобы в будущем не снести рабочий сайт ненароком. И если такая возможность будет, то её рано или поздно кто-нибудь реализует.

Laravel ставился системой автоматической установки. Да. Именно это проблема. После установки нужно проверить, что, куда и как было вкрячено и, скорее всего, поправить. Например популярный Softaculous Script Installer, часто подключаемый к не менее популярной cPanel имеет опцию “Установить Laravel”. И даже устанавливает, но в корень сайта с заморочками и редиректом. Это неправильно, хоть первый запуск и проходит. Для приведения вселенной в порядок нужно перенести все файлы из корня сайта на “один этаж выше”, а в корень поместить содержимое директории public. Ну и выполнить все необходимые танцы по согласованию корня сайта панели и Laravel.

Всё получилось? Ну ОК.

Теги этой статьи:

 

Комментарии

2017-08-18 8:34 pm , Оставь комментарий