Роман Журавлев

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

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

К тому же, ещё один день из 7-ми отведённых вам, можно потратить на чтение десятка подобных вопросов, десятка статей рассказывающих преимущества и достоинства данных фреймворков.

Или вы хотите, чтобы кто-то за вас принял решение? Так давайте я приму -- начинайте проект на Yii2.

если сторонний сайт разрешает (CORS) либо имеет апишку с JSONP то можно. Но лучше такое (раз уж данные надо забирать единовременно и с какой-то периодичностью) делать это на сервере через curl.

Google Forms, не?

Адаптивный макет и резиновый - это разные вещи.
А ваш макет рожден быть фиксированным. Хотите адаптивный, то думайте об этом перед созданием дизайна.

Шаблонизатор шаблонизатору рознь. Но в целом следует выделить общие задачи. которые должны решать за вас шаблонизаторы. С blade не работал и не вижу смысла есть есть twig.

Безопасность. Это пожалуй можно поднять на верх. Типичная картина в шаблонах на php - <?= $someUserInput; ?>. Частенько это можно встретить в выводе инпутов, при формировании ошибок поиска (мол "по запросу $userInput ничего не найдено. То есть вставляем в инпут подключение наших js скриптиков, если это форма поиска - делимся с "другом" и забираем его сессию. Ну или еще какие забавные штуки можно делать. А ведь все очень просто решается. Ставим какую-то функцию, которая по умолчанию будет фильтровать XSS инъекции при выводе, и не будет этого делать только если мы попросим. Если писать просто на php - появляются отвратные функции, которые можно просто забыть вызвать. А с шаблонизаторами мы пишем красивые {{ someUserInput }} и можем спать спокойно.

Помогают соблюдать принцип DRY. Современные средства шаблонизации (twig например), предоставляют вам возможность разделять шаблоны на блоки, переиспользовать их несколько раз, выделять макросы, наследовать шаблоны... словом все что угодно. лишь бы вы могли реюзать куски html а не копипастить их.

Ограничивают полет фантазии разработчика. Далеко не новость что разработчики ленивые засранцы. Особенно молодые. Если им в шаблоне внезапно понадобились какие-то данные из БД, или данные связанные с запросом, большинство не будет париться и зафигачит нужный код прямо в темплейте. Так же некоторые грешат тем что часть бизнес логики размазывают по шаблонам. Так же встречал проекты отданные на суппорт, где чуваки в шаблонах разбирали через xpath ответы от сторонней апишки (которая использовалась вместо базы данных. То есть это дело было размазано по всему проекту). Рефакторинг в случае изменения апишки будет болью.

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

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

Так как за все эти приятные вещи мы по сути ничего не платим (шаблонизатор должен компилировать все это в нативный php так что оверхэда просто не будет), почему бы не пользоваться?

Геракли — yii2 — специалисты, как тут использовать ajax-запрос?

решили измором брать?

Вы понимаете что принципиальной разницы между ajax и не ajax авторизацией в принципе и нету? Меняется только метод отправки данных. Данные же на сервере обрабатываются так же.

То есть стэпы решения задач:
1) учимся вместо отправки формы отправлять ajax запрос
2) учимся обрабатывать данные присланные нам через POST
3) учимся авторизовывать пользователя
4) учимся отвечать пользователю в зависимости от того, какой запрос нам сделали, ajax или не ajax. Или делаем на клиенте унифицированное решение отлавливая редирект.

Зачем простой сайт делать с помощью фреймворка на js? Как можно написать cms на front-end фреймворке? Честно говоря, очень странный и несвязный у вас вопрос : с одной стороны вам нужна cms для сайта, а с другой вы говорите про js-фреймворки

На Bootstrap это делается стандартным navbar чуваки. Если не умеем искать, то берем готовое из родных примеров фреймворка. getbootstrap.com/examples/navbar

если делать прототип и потом выкидывать и переписывать с нуля - то однозначно Yii (ибо сэкономите).

в противном случае вы не сэкономите даже если на разработку было убито меньше денег (я не к тому что Yii плохой а к тому что реализация проекта на Django и на Laravel каком будет не сильно различаться в цене по хорошему. Стало быть вам либо повезло с разработчиком либо все будет делаться в ущерб качества архитектуры и гибкости в будущем).

Если вы не разработчик, то отдайте этот выбор на откуп исполнителя. Просто пропишите в требованиях обязательное наличие интеграционных и UI тестов (юнит тесты не обязательно, достаточно на Behat/Cucumber тесты написать (вне зависимости от выбора, PHP, Ruby, Python), причем тут вы можете поучавствовать). А еще лучше после какого-то этапа (допустим проект готов на 20%-30%) закажите код ревью небольшое и в частности ревью тестов.

http://toster.ru/search?q=книги+по+CSS
Показать запрос в Google?

Простой способ — GreaseMonkey. Написали скрипт, который будет вызывать событие click на нужных элементах.

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

Также есть самый доступный способ — в адресную строку написать javascript: и нужный нам код (не забываем про возврат false). Весь этот код лучше сохранить в закладку (и получится букмарклет).

Вам не нужно иметь в одном дата провайдере несколько моделей, вам нужно разобраться со связями объектов и грамотно их выстроить.

Как-то так.

$dataProvider = Event::getEventsForDate(new \DateTime('28.08.2014'));
foreach ($dataProvider->getData() as $event) {
    $venue = $event->venue;
}

я не думаю что вам будет понятнее такой код:

класс ПростойКласс {
    приватно:
        свойство строка названиеПеременной
    публично конструктор (строка названиеПеременной) {
         контекст.названиеПеременной = названиеПеременной;
    }
    // ...
}

ПростойКласс[] массивКлассов = создать ПростойКласс[10];
пока (беззнаковое целое итератор = 0; итератор < 10; итератор++) {
    массивКлассов[итератор] = создать ПростойКласс("строка передаваемая в конструктор);
}

Вообще все эти понятия типа "функция может возвращать значение" (точнее наоборот, она обычно возвращает значение но может и не возвращать) родом из математики, и там никто не ноет что "почему все называют эти все штуки буквами греческого алфовита". Никто не кричит "почему синус принято обозначать sin а не син" и т.д.

Тут так же. Знание самого языка не поможет вам понять смысла конструкций типа for.

Вы немного не разобрались в документации.

AMQPQueue::consume() - блокирующая функция, т.е. она будет держать поток выполнения до тех пор, пока не вернется сообщение.

Blocking function that will retrieve the next message from the queue as it becomes available and will pass it off to the callback.

AMQPQueue::get() - неблокирующая, т.е. если задания нет - сразу же вернет FALSE.

Retrieve the next available message from the queue. If no messages are present in the queue, this function will return FALSE immediately.

Т.е. все, что вам нужно сделать, выглядит примерно следующим образом:

while(true) {
    $q->consume("rcv_msg");
}

That's it. Заблокировав выполнение и дожидаясь RabbitMQ ничего не будет выполняться, с другой стороны сообщение моментально влетит в функцию выполнения, как только кролик пнет его в нужном направлении.