Виталий Хоменко

Что именно может ускорить разработку сайта, ведь весь функционал я могу и сам написать?

Если ваша цель - писать то, что уже есть, причем оттестировано огромным количеством народу, на куче разнообразнейших проектов да и тестами покрыто. Флаг вам в руки да весло подмышку, дерзайте. Но в один прекрасный момент вы можете вырасти из проектов на одного разработчика. Именно в этот момент вы поймете, что работая в команде далеко не всегда стоит писать как хочется, свои велосипеды/костыли приветствуются как правило только в безвыходных ситуациях.

Пример ситуации: удаление страницы, должно удалить запись из БД и редиректнуть на прошлую страницу, если все ок - показать сообщение "все ок", если возникли ошибки - вывести какие именно ошибки возникли.
Задача тривиальная, с помощью самописа решается довольно просто: пишем в сессию, выводим и удаляем из сессии. Ваш коллега решая подобную задачу тоже напишет свой костыль потому, что в мире существует всего один человек, который знает как реализована задача вывода, он не будет долго сидеть и разбираться:

* а подходит ли ваше решение под его задачу
* что будет если ваше решение сделать более абстрактным
* что сломается в случае ошибки

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

CTRL + SHIFT + Z

В общем есть машина с 4-мя колесами, вставляю ключ, открываю дверь, смотрю в салон, вообще не тот. Проверил стоянку: та, что под домом, двигатель - тоже самое. Где может быть проблема?

Это может быть что угодно, например behavior модели, или формы, или еще что-то. Код в студию

Планировалось разделить эти шаблоны приложений на разные репозитории на rmcreative об этом было сказано.
rmcreative.ru/blog/post/yii-2-sobiraetsja-razdelit...

https://github.com/yiisoft/yii2-app-basic

this.event2();

explain

Как говорит мануал, $_POST заполняется только для HTTP Content-Type application/x-www-form-urlencoded или multipart/form-data.

Значит, разбирать вам этот запрос вручную надо. Кратко говоря:

parse_str(file_get_contents('php://input'), $rgInputData);
//var_dump($rgInputData);

php composer.phar global require "fxp/composer-asset-plugin:1.0.0"

С версии 2.0.1 (вроде) обязательная штука

Начните уже читать доки, это же основа фреймворка вообще.
www.yiiframework.com/doc-2.0/guide-db-active-recor...

class Model extends ActiveRecord {
    public static function find() {
        return new MyQuery(get_called_class());
    }
}

class MyQuery extends ActiveQuery {
    public function withFullUrl($url) {
        $this->andWhere(['full_url' => $url]);
        return $this;
    }
}

Теперь модель и query разделены, поэтому всё что относится к запросам и формированию этого самого запроса — в отдельном классе.

Нууу давайте разбираться.

Для начала почитайте про HTTP на той же вики. Досканально знать не нужно, но стоит минимально понимать структуру запросов/ответов, понимать что у запроса и ответа есть заголовки и тело (тела может и не быть, зависит от типа запроса/ответа).

Так вот. Куки. Куки живут на стороне браузера. Они передаются HTTP заголовком на каждый запрос на сервер (даже если вы за картинками полезли). Есть просто куки, есть http-only куки. Куки могут быть разграничены по хосту и пути. Все это дает нам гибкость и помогает с секьюрностью. В PHP содержимое $_COOKIE предоставляет нам SAPI. Когда PHP получает на обработку запрос, SAPI используемое (php-fpm, cgi, mod_php имеют свои реализации SAPI) в данный момент берет заголовки и тело запроса, парсит их и заполняет все эти суперглобальные массивы типа $_SERVER, $_GET и в том числе и $_COOKIE. Все что прислал нам клиент (что-то что делает запросы это клиент, что-то что их обрабатывает - сервер), а куки шлет нам браузер только те что можно исходя из того куда шлется запрос. Устанавливаются куки заголовком Set-Cookie в ответе, то есть тут больше нужно читать в принципе про HTTP а не про PHP. PHP просто позволяет вам работать с этим добром. Вы можете сэтить куки напрямую работая с заголовками ответа при помощи функции header. Более того, если выставить время жизни куки в 0, то как раз таки они а не сессия будет сбрасываться при закрытии браузера так как тот будет забывать все такие куки.

Вот... сессии... В PHP сессия обычно это файл. Просто какой-то файл с рандомным именем. Если скажем в php.ini указано session.autostart или делается вызов session_start то создается файл под сессию пользователя (можно переместить в рэдис или мемкэш, свое хранилище и т.д в зависимости от нужд. Так же данные можно шифровать, что по умолчанию и происходит). Этот файл имеет ID, просто какая-то рандомная строка. И если при обработке запроса не нашлась сессия с предыдущего запроса - создается новая.

И вот мы подошли к самому интересному - как PHP связывает сессию с предыдущего запроса с текущей. И тут все довольно просто - куки. Когда пользователю присваивается сессия, автоматически сэтится http-only (что бы нехорошие люди не могли из js увести нашу сессию) кука, в которую записан идентификатор сессии. В дебагере браузера можете посмотреть есть ли у вас кука PHPSESSID (название можно менять в настройках, да и вообще сессии можно не только через куки связывать, но это уже загоны по секьюрности) когда будете эксперементировать с сессиями.

Когда запрос обрабатывается SAPI, при наличии session.autostart, перед тем как начинать создавать новую сессию, пых все же смотрит а есть ли у нас кука с идентификатором сессии, проверяет есть ли у него такая, и если есть успокаивается и не создает новую. Поскольку сессия привязывается через куки, то можно выставить время жизни этой самой куки (в php.ini) и таким образом регулировать время жизни сессии.

Вот... когда использовать куки а когда сессии? Желательно понимать, что чем больше данных в куках (а у них есть лимит к слову) - тем больше данных мы передаем на каждый запрос. То есть это не круто когда что бы получить 1 килобайт данных мы должны в заголовках передать пару килобайт кук. Люди, повернутые на оптимизации, даже картинки хранят на отдельных cookie-less доменах что бы уменьшить количество трафика и пакетов (обычно простенький HTTP запрос влазит в размеры одного TCP пакета). Если вам нужно работать с этими данными из JS на любой странице, например локаль выбранноую пользователем для того что бы применять переводы еще и в JS, то стоит использовать куки. Для всео остального лучше конечно же использовать сессии. Во всяком случае на начальных этапах когда что-то сильно сложное вам делать не придется.

в laravel же есть профайлер, нет? Я так понимаю вы время запроса к серверу измеряли, а не к базе.

Если же вы меряли именно время запроса, подозреваю что изза ленивого подключения учитывается еще и время оного. 99% что у вас проблемы с ресолвом DNS. Пропишите в настройки соединения с базой вместо localhost 127,0,0,1

Но одно но - постоянные срачи.

Вы из-за какого-то быдла собираетесь сменить ЯП?
PHP отлично подходит для своей ниши - странице-ориентированный вебдев.
Не fastcgi, не вебсокет-сервер, а именно "отдал документ и умер".
Для остального нужны другие технологии, например node.js или вовсе nginx с модулем на си.

По поводу срачей - это будет в любом случае. Я вот косо смотрю на большинство ruby программистов, так как мой опыт общения с ними показал что большая их часть хают php, и при этому их код ни чуть не лучше. Но я так же знаю и достаточное количество толковых рубистов, которые не так страстно пропагандируют свою религию. Точно так же как знаю хороших php-шников, которые в свободное время пишут простенькие web-приложения на haskel и других языка.

Я для себя решил уже давно, что язык программирования никакой роли не играет. И да, останавливаться на php смысла нету. Но вам нужно на нормальном уровне освоить хотя бы одну платформу. Из того что вы писали в комментариях ясно, что вам стоит попробовать себя в java хотя бы по одной причине: все виденные мною популярные технологии под java обладают неплохой архитектурой. Это вам не yii, в котором архитектуры как таковой и нет. Когда при обучении у вас жесткие рамки, стандарты... Когда инструменты подталкивают вас все делать по best-pratice, тогда можно учиться быстрее. А с иструментами вроде yii это сложно. А уже после осознания этих best-practice, осознания концепций базовых, переход с java куда угодно не станет таким уж сложным. Скажем перейти с java на php в таком ключе будет очень легко (при условии подобающих фреймворков, на вроде symfony2/zend2), как и на .NET, как и на любую другую платформу.

Можете так же попробовать golang, тот же ruby (но не ror, ror пропитан религией), javascript (все же опыт работы с асинхронными языками программирования достаточно полезен), python идеально подойдет для написания небольших утилит или демонов... java после php осваивается нормально, возможности языков в плане построения архитектуры с большего одинаковы. Просто у вас не достаточно опыта в разработке как таковой.

А по поводу депрессий программиста - это нормально и никак не зависит от используемых инструментов. У каждого такое бывает, нужно добавлять в жизнь немного разнообразия. Я вот для борьбы со скукой вообще решил немного попрактиковаться в написании чего-то на c++ (анализ аудио, классификация и т.д.).