kulgan

тут

Включаем php 7.x.
Включаем логирование (судя по вопросу).
Пока не работает:
Проверяем где поломалось.
Определяем количество подобного кода, который сломался.
Правим.

Можно использовать Phpstorm, выставить в проекте php7 и запустить проверку проекта. Я так делал при переходе с 5.6 на 7.1.

Очень интересную вакансию получил на днях, на мой взгляд она в какой то мере описывает то, что должен знать мидл.
- писать хороший код на PHP от 2 лет;
- знаешь для чего нужны интерфейсы в PHP
- у тебя есть опыт проектирования MySQL, понимание механизма оптимизации реляционных баз данных этого типа;
- используешь концепции ООП, а не пишешь лапшекод;
- знаешь основные паттерны проектирования
- умеешь разбираться в чужом коде;
- знаешь о замыкании в JavaScript и как красиво написать рабочий код;
- применял AJAX и периодически его используешь;
- знаешь как писать юнит-тесты и когда их писать целесообразно;
- знаешь о dependecy injection и почему он нужен для повторного использования, масштабирования и тестируемости;
- понимаешь, чем ActiveRecord со связями отличается от традиционного, фаулеровского, ActiveRecord

IMHO то что надо

1. знать большинство отличий/нововведений 2-3 последних мажорных версия PHP (и уметь их правильно использовтаь)
   
2. знать один из фреймворков (ZF2, Symfony2, Laravel4/5) на уровне полного понимания внутренней работы фреймворка (на каких паттернах построена та или иная часть системы, почему именно на них, как это все взаимодействует и т.д)
   
3. знать как работают реляционные СУБД т.е понимание JOIN'ов не только, что куда лепить, а и как это происходит внутри, ну и с остальными функциями так же
   
4. ну и в конце то концов разобраться с SPL, что бы не было ситуаций как на PHP UK Conf.
   
5. JS - понимать как там все внутри крутиться, вертится. Желательно знать еще какой то фреймворк (Angular, backbone, etc)
   
6. HTML, CSS - по вкусу (не считаю, что php программист должен быть крутым верстальщиком, но одно другому не мешает и если нравится то это только плюс будет)
   
7. Знать English, что бы стыдно на митинге не было
   
8. быть адекватным, вменяемым человеком
   

Знаете, я с вами соглашусь, что хорошую вводную по Elastic трудно найти. Пока сам не переварил доков и не набил шишек многие элементарные понятия оставались для меня неясными. Поэтому вот моя вводная: Elastic можно использовать как NoSQL БД, только надо быть внимательным, т.к. всё-таки его основная задача поиск, а не удовлетворение функций БД. Например, если вы не настроили хранение исходных данных, а только индексацию, то свои данные вы уже не извлечёте из него. НИКОГДА. Только отдельные выражения, удовлетворяющие условиям поиска. Всё, тупик. Так же нельзя повторно индексировать уже загнанные в него данные. Т.е. перед загрузкой данных надо грамотно настроить индексацию, т.к. перестроить индекс, как это делается в реляционной БД невозможно. Нужно придумать новую схему индексации и перезалить данные в Elastic. Именно поэтому основное использование Elastic - как дополнение к существующей БД из которой данные можно перезалить по одному или полностью в Elastic (можно, конечно сделать схему Elastic->Elastic, но тоже есть нюансы).
Ещё пару слов про схему. Это ЛОЖЬ, что в Elastic нет схемы данных. Она как раз есть и ооочень жёсткая. Жёсткая до того, что однажды определив, вы не сможете её поменять. Изначально Elastic оказывает медвежью услугу, разрешая вам дополнять схему по-умолчанию, но когда вы разберётесь с этой темой, то можете обнаружить, что Elastic "понастроил" такого у себя внутри, что остаётся только охреневать и переделывать всё явно, отказавшись от его "услуг" по автоматическому добавлению полей в схему.
Так же в Elastic очень непросто строить сложные запросы на поиск и агрегатные запросы. Совершенно неинтуитивно. Но если освоитесь, то будет вам счастье. )))
Несмотря за такие "страшные" вещи - Elastic классная система и по производительности агрегатных запросов не уступает платной версии MSSQL в поиске в многопроцессорных системах (проверял на одинаковых аппаратных конфигурациях с 16 ядрами). Так что если вам хочется большую скорость в агрегатных запросах и главное - это бесплатность, то берите и осваивайте Elastic. Мощности и возможности у него огромные. Но... нужно потратить приличные усилия на изучение.

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

Тернарный оператор

mysql> explain select test6.i from test6, test9 where test6.i=test9.i;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                              |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
|  1 | SIMPLE      | test6 | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |   100.00 | NULL                                               |
|  1 | SIMPLE      | test9 | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
2 rows in set, 1 warning (0,00 sec)

mysql> show warnings;
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message                                                                                                                                 |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select `test`.`test6`.`i` AS `i` from `test`.`test6` join `test`.`test9` where (`test`.`test9`.`i` = `test`.`test6`.`i`) |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0,00 sec)

mysql> explain select test6.i from test6 join test9 on test6.i=test9.i;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                                              |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
|  1 | SIMPLE      | test6 | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    2 |   100.00 | NULL                                               |
|  1 | SIMPLE      | test9 | NULL       | ALL  | NULL          | NULL | NULL    | NULL |    4 |    25.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------------------------------------------+
2 rows in set, 1 warning (0,00 sec)

mysql> show warnings;
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message                                                                                                                                 |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
| Note  | 1003 | /* select#1 */ select `test`.`test6`.`i` AS `i` from `test`.`test6` join `test`.`test9` where (`test`.`test9`.`i` = `test`.`test6`.`i`) |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0,00 sec)

Как можно заметить, оба стиля переписаны в одно и то же представление.

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

SELECT maker, price FROM Product JOIN PC USING(model)

Что эквивалентно PC.model = Product.model, но короче и позволяет в дальнейшем ссылаться просто на model - парсер уже знает, что значение поля будет идентично и не будет теряться в догадках, хотели вы получить model из PC или из Product

Пишите на Python, а узкие места переписывайте на PHP.

$request->request->get('new_liseuse')['titre']

чтобы понятно было:

$array = $request->request->get('new_liseuse');
var_dump($array['titre']);

Можно указать начальную позицию кратную 50 в запросе через start.
Для вашего примера так:

https://my-portal.bitrix24.ru/rest/18/{Token}/user.get?start=50

А что по нему читать-то?
Там всего 30 тегов, ~25 из которых не нужны в большинстве случаев.

Берете и пишете описание кода с парой тегов по необходимости.
www.phptherightway.com/#documenting

Честно, каких-либо существенных изменений я не заметил. В основном книга была просто дополнена. Из явных отличий: теперь код примеров соответствует PSR, также раздел про системы контроля версий был переписан с акцентом на Git.

Изначально затея MVP была в этом:
View должно было быть представлением данных, глупым представлением, которое всего лишь смотрит на изменения полей Model и обновляет вид для юзера
Controller должен был отвечать за ввод и вывод информации пользователю. Никакой бизнес логики - лишь команды и ответы.
Model должен был быть представлением данных. Это не значит, что модели должны быть "толстыми" - это значит, что должны быть другие части приложения, отвечающие за бизнес логику. Не модель. И уж точно не та "модель", наглухо связанная с базой данных.

А теперь мое имхо:
1. Контроллеры принимают запрос, валидируют, достают авторизированного юзера, проверяют пермишены. Вызывают ОДИН метод какого-то класса, форматируют результат и отдают.
2. В моделях только логика БД. Никакой бизнес логики от слова "совсем". Никаких зависимостей. Ничего.

Всю логику выносить куда-то. Логика не должна знать о том, что это HTTP - и.е. никаких обьектов HTTP запросов, никаких HTTP ответов, никаких HTTP ошибок. Если нужен 404 - создается эксепшен под юс кейс (типа UserNotFoundException), а в контроллере ловится и переделывается в NotFoundHttpException. Никак иначе.