antimind

Я не смог придумать язвительный ответ...
Никак.

https://github.com/chiraggude/awesome-laravel - большая пополняемая подборка материалов по Laravel.
Есть ещё большая пополняемая подборка больших пополняемых подборок :)

three.laravel.su/index.php/docs?language=ru

Видеокурсы:
simple-training.com/category/laravel
www.youtube.com/watch?v=I6EJCgy0KiI&list=PLDI5V3o4...
https://www.youtube.com/playlist?list=PLoonZ8wII66...

дальше искать программиста, который реализует функционал по вашему техническому заданию. Объявление приблизительно звучит так: "Необходимо создать сайт-портал по туризму. Возможность выбора отеля, отзывы, личный кабинет пользователя и т.д. Верстка готова (куплен шаблон ссылка). Техническое задание предоставлю." То есть осталось вам своими словами составить ТЗ. Пример ТЗ посмотрите. Только побольше скриншотов можно. Без ТЗ многие профессионалы не хотят беседовать или повышают цену, ибо придется все выпытывать у вас.

jsfiddle.net/wumnazc0 Если не нужен IE<9

Посмотрели фильм "социальная сеть" ?

Моя команда уже успешно реализовала пару соц.сетей.
Поэтому могу ответить на несколько вопросов.

1. Цена на разработку. Инвестиции были в размере ~6 миллионов, если на рубли пересчитать. Проект делался порядка 16 месяцев.
2. Вы о чем?
3. Нормальная соц. сеть не делается на CMS. За основу можно взять фреймворк. В нашем случае это Symfony2 и целый зоопарк.
4. Выделенный сервер и не один.

Первое - соц. сети не нужны людям, их и так как ... ну вы поняли.
Людям нужен узкоспециализированный проект с оригинальной идеей.
Не должно быть аналогов и/или ваш проект должен превосходить уже имеющийся.
Вы придумали идею и не нашли аналогов? Тогда стоит подумать, поспрашивать - а нужна ли ваша идея людям.
Если все ок, то садитесь/нанимаете человека для создания наиподробнейшего ТЗ.
В крайнем проекте было 234 А4 листа. По мере реализации проекта, листов стало больше а нервов меньше =)
Ну вот, у вас есть отличная идея, есть ТЗ и продуманный план работ. Вы постарались учесть большинство подводных камней. Нашли средства на проект, нашли команду.
Ура, разработка проекта стартовала!

А теперь все по новой... ну в плане идеи, ТЗ =)

Еще хотите делать соц. сеть? Если да, то у вас должно получиться.

P.S.
izi.travel данный проект до беты, делался почти 2 года.
То собирали команду по всему миру, то распускали, то инвестиции заканчивались и т.д.
Хотя реальной работы было на месяца 4.

Итак, займемся переводом для начала

на главной создаю объект:

В точке входа/во фронт контроллере. Объект этот завется маршрутизатор или раутер. Имеет отношение к MVC - нет.

вот что в файле hello.class.php:

Такое именование файлов и классов было модным во времена php4. Отройте для себя PSR0 (и еще отдельно про PSR-4 можете почитать).

Т.е. при обращении по url: site.localhost/hello я вижу hello!!!! на экране.

Поздравляю вас с первым контроллером... хоть и убогим слегка. Читаем про контроллеры в контексте GRASP

ну в htaccess я прописал нужную конструкцию

Верни мне мой 2007-ой, когда все было круто и все хвастались своими ЧПУ на модреврайтах. Подумайте в сторону единой точки входа и перенаправления всех запросов, для которых не нашлось файлов на эту точку входа. Но это так... просто... совет. Это упростит жизнь при миграции скажем на nginx или черокки какой.

Вот я и поплыл в этих терминах.

Заходим на википедию и выплываем.

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

Советую почитать полную статью и пройтись по ссылкам. Особенно по части модели данных. Это должно прояснить для вас такой момент что модель это модель данных. То есть у вас есть данные, например блог-пост, есть его модель (просто класс Post который имеет поля id, title, body и т.д.). Проще говоря модель это представления данных в приложении. А view - это слой который занимается тем что переводит данные из формата модели в формат запрашиваемый пользователем. Причем вам не запрещается работать из контроллера с базой. Ну то есть как, есть такие вещи как сервисный слой и тонкие контроллеры, но мы же пока только учимся да?). В любом случае модель не должна знать ничего о том где и как она хранится.

Теперь по поводу view. Давайте вспомним что такое запрос в контексте WEB-приложений. Это старый добрый HTTP запрос. У запроса есть заголовок - Accept который говорит что хочет получить пользователь (пользователи могут быть не живыми и хотеть что-то другое, например JSON). Через него браузер говорит что хочет получить. Например он говорит "хочу text/html" и мы должны выполнить следующие стэпы:
- вызвать контроллер
- контроллер достает из закрамов модельки которые хочет пользователь и отдает их во view.
- view переводит данные из формата приложения в формат который хочет увидеть пользователь.

В очень грубой форме view может быть таким:

PostView {
    
    private $post;    

    public function __construct(Post $post) {
        $this->post = $post;
    }

    public function renderTitle() {
         return sprintf("<h1>%s</h1>", $this->post->getTitle());
    }
    // и еще пара методов    
    public function render() {
         $this->renderTitle();
         $this->renderBody();
    }
}

И по одному таком классу на каждую модель и в каждом классе придется реализовывать сложную логику по формированию вьюшек для наших моделей. Согласитесь, это не удобно. Потому придумали фигачить все в шаблонах и разруливать это движками для шаблонизации (да, одна единственная функция render которая просто инклудит php файл это тоже движек шаблонов).

Практическое задание:
Если все что делает контроллер это отдает отрендренный шаблон без какой либо переменной в нем.... Это MVC? Где тут модель?

В MySQL можно сделать так: в одной таблице хранить сущности (ID сущности, название, ...), в другой таблице все атрибуты (ID, название), в третьей значения атрибутов (ID сущности, ID атрибута, значение). Если нужно, то добавить еще две таблицы: виды сущностей (ID вида, название, ...) и связи видов сущностей с атрибутами (ID вида, ID атрибута). Такая схема позволяет менять кол-во атрибутов без переделки структуры таблиц и нет таблиц с 50 столбцами).

нет у меня не сработает так как нгинкс и никакого апача в помине нет