Laravel по-русски

можно попробовать удалить всю папку vendor, чтобы она сформировалась заново.

1. Не валидировать модели, а валидировать пользовательский ввод (https://github.com/laracasts/Validation)
2. Сделать в модели две переменные с правилами валидации - $createRules или $updateRules например, и изменить валидирующий код соответственно.

Laravel4+ way - это фреймворк-агностик путь, назад к корням, голому php - приложение пишется на классах, которые доступны из контроллера будучи переданными в него в аргументах конструктора (Dependency Injection) и при помощи фасадов. К сожалению, в документации это не отражено должным образом, за этим нужно идти к книгам "From Apprentice To Artisan" или "Implementing Laravel".  Или к циклам про SOLID-принципы или Command-Oriented Architecture у Джеффри на https://laracasts.com/how-do-i . Последнее - весьма интересное решение по разгрузке контроллеров от кода, но очень замороченное, не для всех проектов подойдет.

Конкретно в описанном случае можно написать класс, который будет принимать на вход экземпляр модели, получать оттуда данные и возвращать переменную(ые), которую контроллер потом передает в view. Хранить этот класс в неймспейсе, который определить в composer.json (http://laravel.ru/forum/viewtopic.php?id=473), подавать аргументом в конструкторе. Но если не заморачиваться с тестируемостью и доступе к этому функционалу из командной строки, можно разместить сей функционал прямо в BaseController.

Решение не костыльное, но если классов планируется юзать много, можно зарегистрировать свой неймспейс и писать свои классы там, держа их в понятной иерархии папок. Неймспейс регистрируется в composer.json добавлением секции psr-0 или psr-4:

"autoload": {
		"classmap": [
			"app/commands",
			"app/controllers",
			"app/models",
			"app/database/migrations",
			"app/database/seeds",
			"app/tests/TestCase.php"
		],
		"psr-4": {
			"Myapp\\": "app/Myapp"
		}

Чтобы изменения подхватились надо дать команду composer dump-autoload .

Теперь в папке Myapp вы можете располагать свои классы и обращаться к ним из контроллеров/моделей/сервиспровайдеров по соответствующему неймспейсу.
Подробности гуглятся по laravel namespace , у Джеффри на http://laracasts.com все пишется в неймспейсе, можно посмотреть, вообще, можно держать там весь код приложения. В следующей версии laravel весь апплекейшн будет в неймспейсе принудительно.

А почему бы не поставить php5-cli ? Все убунту-серверы работают с несколькими php в системе - cli, fpm и apache - и ничего, все равно всё обновляется одной командой, конфиги тоже одинаковые можно сделать. Проблема уйдет.

PS не уверен насчет целесообразности lamp-сборок под линухом, в убунте все ставится апт-гетом: https://www.digitalocean.com/community/ … untu-14-04 . Но не настаиваю, каждый сам кузнец своего счастья.

1. Документация по ОРМ к счастью, в одном месте. Заходим http://laravel.com/docs/eloquent , Ctrl+F 'created_at' и под первым же вхождением видим: "If you do not wish to have these columns automatically maintained, set the $timestamps property on your model to false."

2. А как можно валидацию сделать проще ?
    $validator = Validator::make(Input::all(), $rules);
    if ($validator->fails())
    {
        return Redirect::to('url')->withErrors($validator);
    }
Если же хочешь, чтобы модели у тебя автовалидировались при сохранении (имхо, стремный момент, но практикуется), то повесь валидацию на эвент: http://www.laravel-tricks.com/tricks/au … validation

Blade нужен исключительно своими директивами @extends , @section , @yield и т.п. -  с помощью них компонуется лейаут в laravel-style компоновки приложения, они практически незаменимы. Плюс очень удобный @include  - он вставляет внешнюю вьюху и, о чудо и счастье, туда не надо передавать переменные, все переменные, которые объявлены на данный момент будут переданы туда автоматом. Юзать остальные фичи blade типа {{}} имхо нет смысла - нет автодополнения, автовыделения в IDE, ну и действительно, просто зачем, когда есть прекрасный шаблонизатор php.

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

Phpstorm на фреймворке из коробки действительно помогает мало, но стоит поставить https://github.com/barryvdh/laravel-ide-helper , то все магическим образом преображается. Работает автодополнение по всем классам и фасадам, Ctrl+B работает везде и на всем, можно смотреть исходники вглубь не залезая в документацию. Плюс генерится phpdoc для твоих моделей, так, что становится возможным даже автодополнение названия их полей - они берутся из БД. Мне лично с laravel работать в phpstorm очень удобно.

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

PHP лочит файл с сессиями на время запроса, поэтому в хайлоаде хранить сессии в файлах настоятельно не рекомендуют.

Универсальной структуры нет, иначе бы кроме неё ничего не существовало. Но общие принципы назвать, наверное, можно.

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

Если вы планируете использовать тесты (а для хороших больших приложений они все-таки необходимы, хотя я лично так и не могу себя заставить их писать), постарайтесь не юзать фасады и оператор new - используйте DI в виде передачи параметров в конструктор и App::make().

Работу с моделями по возможности (но без фанатизма) выносите в репозитории. Т.е. контроллер вызывает метод репозитория, в котором вызывается модель (или несколько) с нужными параметрами и, если надо, результат кэшируется. Об этом можно прочитать, например, в "From apprentice to artisan" Тейлора.

Интересный метод избавления контроллера от кода предложил Джеффри Вей в своем цикле "Commands and Domain Events": https://laracasts.com/series/commands-and-domain-events , https://laracasts.com/lessons/introduci … -commander. Также в рамках этой парадигмы он пишет пример соцсеточки Larabook - https://laracasts.com/series/build-a-la … om-scratch .

Также многие рекомендуют разделять классы в приложении не по функциональности низкого уровня (в этой папке у нас контроллеры, в этой модели, тут правила валидаторов), а по логическому разделению на более высоком уровне (в этой папке у нас все, что относится к пользователям, в этой - все, что к постам, тут - к заказам, тут - к счетам, а это - общее). Пример такой архитектуры можно видеть здесь: https://github.com/Siliconsoul/FusionIn … FI/Modules . Хотя папка Modules имхо лишняя, проще все в коренном неймспейсе размещать, т.е. в данном случае FI.
Я сделал пакет, который генерит подобные модули внутри неймспейса, чтобы руками каждый раз не создавать кучу папок и прописывать все в сервис-провайдере: https://github.com/slider23/laravel-modulator
Но польза от такого разделения кода немного сомнительна. Например, роуты неудобно держать по модулям, проще все в одном файле. Но если они в разных файлах, то можно переносить модули из приложения в приложение. В общем, все это субъективно.

Также полезным времяпрепровождением будет чтение и конспектирование http://refactoring.guru

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

А класс InvalidException у тебя есть ? Во фреймворке его нет. Попробуй кидать и ловить просто Exception.

У вас в config/app.php не включен Debug Mode, включите, текст ошибки будет предметнее.