Иван Корюков

Не помню, разрешён ли group by во вложенных запросах, но если да, то вот так.

SELECT * FROM `cpl_city` WHERE `title` IN (
  select t.title from (
    SELECT COUNT(*) as `col`, `title` FROM `cpl_city` GROUP BY `title`
  ) as t where t.col > 1
)

Почитайте про функции ob_start(), ob_get_clean() и подобные. Они захватывают вывод в буфер, и этот буфер можно получить в виде строки.

В первом варианте получается что элемент с классом wr может быть как угодно глубоко внутри хедера.
Во втором - только непосредственно в хедере, но не в дочерних элементах хедера.

Возможно начинать вложенный элемент с > нельзя, но это не точно.

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

Проще всего использовать расширение xdebug. Оно помимо отладки позволяет профилировать код. Работает это так: добавляете в адресной строке специальный параметр (лучше использовать специальное расширение для браузера) и при отработке вашего php скрипта дополнительно будет создан файл, куда будет записано какая функция сколько раз распускалась и сколько времени выполнялась.
Этот файл можно открыть специальной программой, которая позволяет сортировать функции по времени выполнения, а так же смотреть на дерево вызовов.

Всё в порядке. Просто в питоне вместо тернарного оператора используется конструкция
variable = value_1 if test else value_2
Что аналогично традиционному тернарного оператору
variable = test ? value_1 : value_2
Работает это не только в лямбдах, а везде.

1) Вы пишете что модель сама берёт данные из post. Зачем тогда вам контроллер? Это плохая модель, она зависит от способа передачи данных . Контроллер должен получать данные и передавать их модели. А методы должны называться в соответствии с тем что они делают. Могут называться и одинаково, тут вопрос не к названию, а к содержимому.
2) то же самое. Модель должна вернуть данные, а уже контроллер дальше положит их куда надо.
3) подумайте сколько раз за один http-запрос будет создан лишний объект. Если это количество само по себе велико или зависит от обрабатываемых данных (например по одному лишнему объекту на выводимый на странице комментарий пользователя) то это плохо. Если один раз, то зависит от способа создания объекта. Если в конструкторе выполняются ресурсоёмкие операции, то... Это само по себе плохо. Конструктор не должен содержать кода (с некоторыми допущениями)
4) в третий раз повторяю - модель должна вернуть значение. Прервать выполнение программы она может в одном случае - возникла ошибка, такая что дальше работать бессмысленно. Для этого есть исключения. Контроллер должен поймать исключении и завершить выполнение, а лучше показать сообщение - "ой, возникла ошибка".
Во всех других случаях модель делает return, управление передаётся контроллеру и уже он, если необходимо делает die().
Хотя само по себе использование die() чаще всего является костылём.

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

Веб-компоненты - обобщающее название нескольких технологий, позволяющих создавать собственные элементы с инкапсулированными структурой, стилями и поведением.
Т.е. вы создаёте один-два файла в какой-нибудь папочке, описываете в них разметку, стили и js-код и вызовом некоторых api-функций говорите браузеру - "вот мой собственный элемент с именем my-element, если встретишь тэг , то наполни его вот этим, стилизуй вот так и по событиям выполняй этот код".
Технологии, которые это позволяют постепенно появляются в браузерах, но как обычно не полностью и не везде. Нужны полифилы.

И да, веб-компонент мужского рода)