Поэтапная разработка сайта на Laravel 4: урок №3

И снова здравствуйте!

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

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

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

Если быть более конкретным, то на этом и следующем уроках мы рассмотрим:

  • Конфигурация приложения и различные среды окружения (environments)
  • Создание миграций
  • Некоторые базовые вещи шаблонизатора Blade, включая вспомогательный фасад Form, предназначенный для генерации элементов форм
  • Создание модели планеты
  • Основы работы с Eloquent ORM (добавление, выборка)
  • Валидация (проверка) входящих данных при добавлении планеты
  • Кто-то, возможно, так же как и я относительно недавно, откроет для себя такую полезную штуку, как Bootstrap, позволяющую создавать относительно красивые страницы без каких-либо дизайнерских навыков

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

Starbound

Игра Starbound представляет из себя так называемую «песочницу». Наверняка многие из вас знают такие игры, как Minecraft и Terraria. Так вот Starbound является, с позволения сказать, логическим продолжением Террарии. Игрок бегает по планете, может «выкапывать» абсолютно любые блоки, из которых состоит планета, и строить из них что угодно. Но в отличие от того же Mincraft’а, здесь игрок может прокачиваться, исследуя новые технологии, открывая новые звездные карты, что дает возможность создавать или находить более совершенные оружие и броню.

Также, важным отличием от названных игр является то, что в Starbound не один большой мир (или планета), а почти бесконечное их множество. Игрок, имея достаточное количество топлива, может перемещаться с планеты на планету из разных секторов, например, в поисках различных технологий или легендарного оружия. Все эти планеты генерируются процедурно (случайно), но важно знать одно: хоть вся вселенная и генерируется «на лету», у всех игроков она абсолютно (с небольшими нюансами) одинаковая за счет использования одного сида (seed) для генератора случайных чисел. То есть, например, какой-нибудь Вася, попав на какую-то планету «X Rotanev 309 III» из сектора X и найдя на ней что-то интересное, может записать ее координаты и поделиться ими с каким-нибудь Петей, который как раз ищет то, что нашел Вася.

Собственно отсюда и родилась идея создания сайта sbshare.ru — дать возможность игрокам делиться координатами найденных интересных планет.

Планеты

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

В Starbound вселенная состоит в первую очередь из секторов. Всего их в игре (по крайней мере на данный момент) пять: Alpha, Beta, Gamma, Delta и X. В каждом секторе находится огромное количество звезд, и у каждой звезды есть свои координаты X и Y. Каждая звезда имеет свое уникальное название. В примере выше это «X Rotanev 309» (название звезды начинается с названия сектора). Далее, вокруг почти каждой звезды вращается некоторое количество систем, названия которых «наследуют» название звезды, добавляя римскую цифру, например «X Rotanev 309 III». И уже в каждой системе есть некоторое количество непосредственно планет, названия которых также «наследуют» название «предка», но на сей раз добавляя латинскую букву, например «X Rotanev 309 III c».

Тем, кто имеет определенный опыт проектирования баз данных, может предложить использовать отдельные сущности для звезд, систем и планет (такая база называется нормализованной). Но в нашем случае этот подход будет не очень удобным, так как при отображении планет нужно выводить координаты звезды, что потребует каждый раз дополнительно извлекать ее данные из отдельной таблицы. Поэтому я предлагаю сделать базу немного денормализованной, то есть иметь всего одну сущность: «Планета», которая в себе будет содержать и название звезды, и название системы, и, что важнее, непосредственно координаты. Хотя тут конечно кто-то подумает, что можно было бы как-то это упростить и не хранить в сущности планеты эти названия, ведь в названии самой планеты фактически содержатся названия и системы, и звезды, и даже сектора. Но так исторически сложилось, что когда на форумах игры люди делились координатами, они приводили подробное описание планеты, то есть по порядку: «Сектор X, звезда X Rotanev 309, система X Rotanev 309 III, планета X Rotanev 309 III c, …». Поэтому мы не будем отходить от традиций и сделаем вывод информации о планете в таком же стиле.

Далее каждая планета имеет свой уровень сложности (или, если переводить буквально, уровень угрозы): от 1 до 10. В секторе Alpha есть только планеты с уровнем сложности 1, в Beta — 2, и так далее до Delta. В секторе же X содержатся планеты с уровнем сложности от 5 до 10. Опять же, дабы не изменять традициям, уровень будет хранится и выводится даже для первых четырех секторов, несмотря на то, что всем и так понятно, что в секторе Gamma будет только 3й уровень сложности.

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

Говоря об одинаковости вселенной, я уточнил, что есть нюансы. Их два. В разных версиях игры вселенная менялась. То есть, например, в предыдущей версии, которая называлась Furious Koala, могла быть одна вселенная, в то время как в последней, Enraged Koala, вселенная стала другой. Поэтому в данных о планете должно храниться, в какой версии она была найдена. Так как в старую версию никто не играет, на данный момент выбрать пользователь сможет только Enraged Koala, но этот механизм позволит не попасть впросак, когда выйдет новая версия.

Второй нюанс заключается в операционной системе, на которой играет пользователь. Сама вселенная ничем не отличается, но вот содержимое планеты может варьироваться в зависимости от того, под какой ОС она была найдена. Поэтому нужно предоставить пользователю возможность указывать ОС при добавлении планеты, будь то Windows, Linux, или Mac OS.

Структура таблицы

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

  • id — уникальный идентификатор планеты в нашей базе
  • x, y — координаты планеты
  • level — уровень сложности планеты
  • sector — сектор планеты; это будет enum поле из 5 элементов: alpha, beta, gamma, delta, x.
  • star — название звезды
  • system — название системы
  • planet — само название планеты
  • biome — биом планеты; это будет enum поле из следующих элементов:
    • arid
    • asteroid
    • desert
    • grasslands
    • jungle
    • magma
    • moon
    • svannah
    • snow
    • tentacle
    • tundra
    • volcano
  • version — версия игры; на данный момент это enum с одним элементом enraged_koala
  • os — ОС, под которой найдена планета; enum из трех пунктов: windows, linux, mac
  • comment — комментарий о планете, то есть описание, которое нужно оставить, добавляя планету
  • user_id — id пользователя, добавившего планету; тут немного забегаю вперед конечно, пока это поле всегда будет пустым, так как никаких зарегистрированных пользователей на сайте пока нет
  • views — счетчик количества просмотров планеты; просто чтобы иметь представление, сколько раз смотрели ту или иную планету
  • служебные поля created_at и updated_at, хранящие даты создания и изменения планеты

Создание миграции

Создание новой базы данных

Прежде чем создавать таблицу для планет, нам сперва нужно создать пустую базу данных и настроить наше приложение для работы с ней. Сделать это можно несколькими способами: как при помощи стороннего приложения, так и прямо из консоли. Я больше предпочитаю работать с базой, используя SQLYog (под Windows) — https://www.webyog.com/. В нем есть все, что мне нужно для работы, но он платный. Среди бесплатных могу посоветовать разве что только dbForge — http://www.devart.com/ru/dbforge/sql/studio/. Полнофункциональная версия dbForge тоже стоит денег, но у него есть и бесплатный тарифный план, включающий основные функции. В общем решать, конечно, вам, но я все же рекомендую обзавестись какой-нибудь программкой для управления базой данных. Хоть нам это и не потребуется на протяжении уроков, наличие под рукой нужного софта сможет значительно облегчить жизнь, если потребуется вручную внести какие-то небольшие изменения в базу.

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

В Homestead же есть небольшой нюанс. Чтобы подсоединиться к серверу MySQL из-под родной системы, то нужно использовать не стандартный 3306 порт, а 33060. Дело в том, что внутри виртуальной машины MySQL то слушает стандартный порт 3306, но для связи внешнего мира с виртуальной машиной vagrant делает перенаправление портов, о чем, кстати говоря, он сообщал при запуске бокса. Конкретно для MySQL, как я уже сказал, нужно соединяться с localhost по 33060 порту.

По умолчанию в Homestead для соединения с базой используется пользователь homestead и пароль secret.

Соединившись с сервером, нужно создать базу с именем sbshare. Если же вы решили не заморачиваться с установкой дополнительного софта для работы с БД, то базу можно создать вручную. Для этого нужно войти через ssh в homestead (vagrant ssh) и выполнить следующую команду:

Конфигурация приложения и среды окружения

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

Как было сказано в предыдущем уроке, вся конфигурация приложения находится в папке app/config в многочисленных файлах .php. Конкретно настройки базы данных находятся, как можно догадаться, в файле database.php. Можно его открыть и посмотреть, но не спешите вносить в него изменения. Дело в том, что файлы, лежащие непосредственно в папке config являются конфигурацией для среды окружения «по умолчанию». Или если говорить проще, это та конфигурация, которая будет использоваться уже на финальном сервере, когда проект будет готов к развертыванию (деплою (deploy)).

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

В Laravel эта проблема решается за счет поддержки разных сред окружения (environment). Если взглянуть, то в папке config уже имеется несколько других папок (не считая packages): это local и testing. В этих папках должны содержаться «переопределения» конфигов по умолчанию для соответствующей среды. Так вот, к примеру, local содержит переопределенные конфигурационные файлы из основной папки config для среды «local» (будем считать, что local — это среда разработки). Изначально там только один файл — app.php, определяющий значение debug равным true.

Соответственно нам нужно переопределить для локальной среды настройки базы данных. Для этого нужно создать файл database.php в папке local со следующим содержимым:

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

Осталось только понять, каким образом Laravel определяет, в какой среде он запущен? Для этого уже придумано несколько способов, но мы воспользуемся стандартным, который предусмотрен Laravel’ом, что называется, «из коробки».

Откройте файл bootstrap/start.php и найдите там (в начале файла) строки:

Вообще говоря, тут вроде все понятно, но я поясню. Эту запись на русский язык можно перевести так: если имя текущей машины — «your-machine-name», то Laravel будет считать, что текущая среда — «local». Соотв-но в массиве помимо «your-machine-name» может быть сколько угодно других имен — это для случая, если над проектом работают несколько разработчиков, и у каждого, соответственно, машина называется по-разному, но тем не менее у всех при разработке должна быть среда local.

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

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

  • Для пользователей Mac и Linux узнать имя можно, выполнив команду «hostname» в консоли
  • В Windows имя компьютера можно узнать в свойствах компьютера: быстрее всего нажать клавиши Windows + Pause Break и внизу увидеть соответствующую информацию.

Примечание: важно не путать имя машины и домен, под которым будет работать приложение. То есть ни localhost, ни sbshare.localhost не подойдут. Дело в том, что приложение не всегда будет запускаться посредством веб-сервера (то есть по запросу пользователя из броузера), бывают и служебные консольные команды (artisan-команды, с которыми мы скоро начнем работать), в этом случае такого понятия, как «домен» вообще не существует и соответственно Laravel не сможет правильно определить среду окружения и будет считать, что он работает в среде «production» (среда по умолчанию).

Теперь можно еще чуть-чуть поиграться с маршрутами и проверить, правильно ли Laravel определяет среду окружения. Для этого давайте пропишем такой временный маршрут в файле routes.php:

Теперь откройте в броузере http://sbshare.localhost:8000/env: вы должны увидеть «local».

Миграции

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

Миграции пишутся не в виде SQL-команд, а в виде отдельных инструкций, использующих так называемый Schema Builder Laravel’а. Таким образом достигается независимость от используемого драйвера БД, будь то MySQL или Postgres.

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

Создание таблицы planets

Приступим сразу к делу и создадим миграцию для создания таблицы «planets». Перейдите в консоли в корневую папку проекта и выполните следующую команду:

В результате, в папке app/database/migrations будет создана новая миграция с уникальным именем, включающем «create_planets_table» и временнýю метку, позволяющую впоследствии определять порядок выполнения миграций. В моем случае файл миграции называется «2014_06_07_183117_create_planets_table.php«.

Опция «—create=planets» необязательна, она лишь позволила нам сделать миграцию с уже прописанными некоторыми инструкциями для создания таблицы planets — мы могли это сделать и вручную, но зачем? 🙂

Открыв созданный файл миграции можно увидеть, что миграция в Laravel — это класс, наследующий Migration, и имеющий два метода: «up» и «down». «up» используется при выполнении миграции, «down» соответственно при откате этой миграции. В нашем случае artisan уже прописал несколько инструкций в эти методы. Метод down трогать не надо, весь откат данной миграции заключается в удалении таблицы planets. А вот с методом up мы и будем работать.

Разберем для начала имеющиеся инструкции в методе up:

Инструкция «$table->increments(‘id’)» создает в таблице авто-инкрементное поле id, которое также будет являться первичным ключом таблицы.

Инструкция «$table->timestamps()» создаст в таблице два timestamp-поля: created_at и updated_at. Это служебные поля (хоть и необязательные вообще говоря), которые Eloquent заполняет автоматически при создании/обновлении записи в таблице.

Надеюсь тут все ясно. Теперь давайте пропишем инструкции для оставшихся столбцов таблицы. Для добавления в структуру таблицы отдельного поля, у объекта $table имеется множество различных методов. Например, для добавления INT-поля (число) есть метод $table->integer(«…»). С полным списком доступных методов можно ознакомится в официальной документации: http://laravel.com/docs/schema#adding-columns. В таблице planets довольно много полей, и соответствующий код для добавления оставшихся полей выглядит так:

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

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

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

Если у вас есть сторонний софт наподобие SQLYog’а, то можете посмотреть на созданную таблицу.

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

Макет сайта и главная страница

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

На страницах сайта мы будем использовать Bootstrap (http://getbootstrap.com/). Я не претендую на роль учителя по Bootstrap’у и тем более по HTML/CSS, поэтому приведенный в итоге листинг для макета можно будет просто скопировать. Ну а кому интересно — может вникнуть в содержимое. Но все же на кое-какие моменты, относящиеся к шаблонизатору, я обращу внимание. Кто-то возможно захочет сделать собственный макет, не обязательно с использованием Bootstrap’а.

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

В большинстве случаев все страницы сайта имеют одинаковые куски HTML-разметки. Как правило это заголовок с навигацией и «футер» (footer), то есть нижняя часть страниц. И понятное дело, что копировать эти части из шаблона в шаблон неразумно. Поэтому в различных шаблонизаторах имеются разные способы решения этой проблемы. Где-то используюся «инклюды» (includes), то есть, например, в начале шаблона прописывается инструкция вида «include(header)» («вставить» header), потом идет содержимое страницы, а в конце «include(footer)». И не смотря на то, что Blade тоже поддерживает инклюды, для решения этой проблемы в нем используется наследование шаблонов.

Как это выглядит? Есть базовый шаблон, содержащий «основную» разметку всех страниц, то есть все те же header с навигацией и footer. Такой шаблон обычно называют лэйаутом (layout). А в нужных местах, например в том месте, где должно быть содержимое конкретной страницы, используются инструкции «вставки» содержимого из того шаблона, который этот лэйаут наследует.

Рассмотрим на примере. Допустим, у нас есть такой лэйаут:

Обратите внимание на строки 3 и 13. В них используется инструкция «@yield», которая говорит шаблонизатору, что в этих местах нужно подставить соответствующие секции из наследующего шаблона. Вот каким мог бы быть сам шаблон для заглавной страницы при условии, что лэйаут сохранен в файле layout.blade.php:

В первой строке мы указываем, что этот шаблон наследует, или, если переводить буквально, «расширяет» шаблон layout (layout.blade.php).

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

Теперь, когда теория разъяснена, можно создать уже нормальный макет для нашего сайта. Он может быть таким (файл app/views/layout.blade.php):

А сам шаблон для главной страницы сайта пока совсем простой (index.blade.php):

Индексный контроллер и маршрут

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

Итак, давайте создадим контроллер IndexController (файл app/controllers/IndexController.php) с единственным методом getIndex:

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

Теперь можно переопределить корневой маршрут в routes.php:

Или же, для полноты картины, можно его еще и обозвать как «home». Тогда определение будет выглядеть так:

Если кто помнит, в предыдущем уроке я говорил, что везде на сайте буду использовать записи вида «Route::controller(‘IndexController’)». Но данный конкретный контроллер в этом не нуждается, так как у него всего один метод, и генерировать для него маршруты посредством «Route::controller» — это как из пушки по воробьям 🙂

Ну что же, остается только проверить работоспособность нашего, пока небогатого, приложения. Открыв главную страницу по ссылке http://sbshare.localhost:8000/ вы должны увидеть что-то такое (если конечно делали все также, как у меня):

SBShare Index page

На этой ноте третий урок можно считать законченным.

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

Всем успехов! 🙂

Поделиться в соц. сетях

28 thoughts on “Поэтапная разработка сайта на Laravel 4: урок №3

  1. Михаил:

    два если
    ——
    Если если быть более конкретным, то на этом и следующем уроках мы рассмотрим:

  2. Разгневанный читатель:

    Ещё не начав читать третий урок, обратил внимание, что четвертого нет…
    Дело так не пойдёт, скорее приступайте к его написанию! И огромное Спасибо!
    Очень интересно читать!

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

  3. Tramp1357:

    Спасибо за статьи, все понятно и без лишней воды.

    У меня возник вопрос: стоит openserver, laravel 4.2.
    До инструкции
    php artisan migrate
    все было нормально, а на ней появилось сообщение
    [PDOException]
    could not find driver

    На этой системе я спокойно поднимаю сайты на MODX REVO, т.е. pdo_mysql включен. В чем может быть проблема?
    Я понимаю, что можно и вручную создать таблицы, но хотелось бы по-правильному

    1. Никогда не работал с openserver, но возможно дело в том, что php для командной строки использует другой php.ini нежели тот, что используется веб-сервером, и как раз в нем pdo_mysql может быть отключен. Можно проверить это выполнив в ком. строке php --ini — php выведет используемый ini-файл, и проверить этот файл на наличие pdo_mysql.

  4. moroznoeytpo:

    Для соединения с MySQL на homestead в настройках нужно прописать ‘host’ => ‘localhost:33060’.
    И еще, laravel не захотел переопределять настройки DB в /config/local/database.php, пришлось прописывать настройке в production.

    1. Значит где-то косяк с определением среды в файлах Laravel, у меня всегда прокатывает вариант, как описан в статье, то есть array('homestead');

  5. etalord:

    Спасибо за серию статей, очень интересно и познавательно!

    У меня проблема. dbForge не хочет подключаться к БД:

    При установлении соединения с SQL Server произошла ошибка, связанная с сетью или с определенным экземпляром. Сервер не найден или недоступен. Убедитесь,
    что имя экземпляра указано правильно и что на SQL Server разрешены удаленные соединения. (provider: Поставщик именованных каналов, error: 40 — Не удалось
    открыть подключение к SQL Server)

    Пробовал указывать
    localhost:33060
    127.0.0.1:33060
    192.168.10.10:33060 (ip вирт. машины)

    firewall на убунте отключил, не помогло 🙁 ОС — W7

    1. Прошу прощения за долгий ответ. Я так понимаю Вы пытаетесь использовать dbForge для работы с SQL-сервером? А нужна то версия для MySQL.

  6. softua:

    Александр, огромное спасибо за статьи — очень полезно.

    Несколько моментов:
    1) Что касается менеджера БД, то я уже давно ушел с phpadmin и пользуюсь HeidiSQL. Очень удобная вещь, кстати она идет в сборке OpenServer.

    2) В статье проблема с ссылкой на документацию: «http://laravel.com/docs/schema#adding-columns». Она ведет не на внешний ресурс, а имеет путь относительно текущей страницы.

  7. Анатолий:

    Александр, очередной раз спасибо за статью! Я начал изучать Laravel с просмотра серий видео-уроков на Ютуб, но только после прочтения твоих статей я начинаю вникать и все больше влюбляюсь в этот фреймворк!!!

  8. Oleg:

    по вашему примеру все делал точно так же до Статьи «Миграции», но когда начал прописывать «php artisan migrate» в консоле, то выдавал ошибку
    [PDOException]
    SQLSTATE[28000] [1045] Access denied for user ‘forge’@’localhost’ (using password
    : NO)
    С логином паролем проблем у меня нет.

    И еще один вопрос, у меня текущая среда — «production», вместо «local»? Это хорошо или плохо?

    1. Вот как раз в среде и проблема: ларавел берет не те настройки соединения с базой. Вы из под homestead работаете? Если да, то странно, ибо по умолчанию все должно работать. Если нет, то соотв-но проблема с определением среды исполнения.

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

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

    Еще раз, огромное спасибо за прекрасную работу.

  10. Narayan:

    Конфигурация такая: PhpStorm 8.0.1+laravel 4.0.11
    При выполнении команды
    php artisan migrate:make create_planets_table —create=planets
    консоль выдает ошибку «The «—create» option does not accept a value». Справка в консоли выдаёт команду create без параметров. Подскажите, что не так?

    1. Надо полагать, что у Вас старая версия Laravel, в которой синтаксис команды был другой. В 4й ветке сейчас последняя версия 4.2.

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

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

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.