Алексей Николаев

Wordpress заново загружает html-код виджета после того, как вы его сохраняете, т.е. фактически, виджет, на элементы которого вы вешали ваш JS, удаляется и заменяется новым. Для того, чтобы все работало, вам необходимо вешать "живые" события на все элементы необходимых вам идентификаторов, отталкиваясь от, например, документа.

Создайте новый инстанс класса, и получите объект, который только что был создан.

Проблема, описанная в вопросе, была в неверном приоритете операторов.

Зависит от ситуации. В вашем примере - второй. Но, в случае с кодом ниже - первый.

foreach($houses as $house) {
    $current_floor = $house[$floor];
    $rooms_count = count($current_floor['flats']['1-room']); // например, только 1-комнатные

    $total_rooms += $rooms_count;

    /* вышенаписанное гораздо лучше, чем
    $total_rooms += count($house[$current_floor]['flats']['1-room']);
    */
}

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

$_SERVER['HTTP_REFERER'] // тут адрес страницы, с которой был отправлен запрос

Однако учтите, что данного свойства может и не быть. Поэтому всегда проверяйте его на наличие.

Если нужна 100% гарантия, отправляйте из вашего скрипта дополнительное свойство, например, referer_id (либо id, чтобы на сервере получить из предопределенного массива саму ссылку, если у вас скрипты расположены в четко определенных местах; либо саму ссылку).

ActiveRecord в большинстве случаев подходит только для простых запросов. В случае чего-то более-менее заковыристого приходится лезть в модель и городить огород из правил разной степени кривости (если фреймворк поддерживает), или еще хуже - писать все вручную. Два варианта плохи по определению. Поэтому ActiveRecord для простых операций, а QueryBuilder (или какой-нибудь нативный и удобный объект для работы с БД) с блэкджеком и шл PDO и плейсхолдерами - для всего остального.

Отказываться не стоит, просто нужно использовать молоток для забивания гвоздей, а лопату - для копания. ActiveRecord адски удобен, при простых выборках или рядовых insert \ update он смотрится просто великолепно и делает код более простым и наглядным. В проектах ИМ 80% операций с базой идет через AR, и это очень облегчает жизнь.

$arrays = []; // здесь ваш массив с массивами
$needles = ['num', 'oper'];
$output = [];
foreach($arrays as $key => $array) {
    if(in_array($key, $needles) {
        $output = array_merge($output, $array);
    }
}

Если функция атомарна и не имеет зависимостей от других функций \ классов \ внешних переменных, а также может вызываться многократно за один цикл выполнения, то можно использовать ее. Наглядный пример - простая обрезка картинок, либо форматирование текста.

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

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

В index.php темы проверяете существование модулей в определенной позиции при помощи функции $this->countModules('position'). Далее, если модули есть, устанавливаете body определенный класс, на основании которого в css будете скрывать \ показывать этот div.

Либо, на основании вышеупомянутого условия, прямо в index.php определяйте, выводить div или нет.

if($this->countModules('position')) :
    // тут выводите нужный html, если модули есть
endif;

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

Время хранения кук тут роли никакой не играет. Нажмет пользователь "запомнить меня", а вы установите ему куку на час?

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

Get-запросы токенами защитить невозможно

Почему? Посылаете в get токен параметром, на сервере проверяете.

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

В вашем примере при логауте стоит делать unset($_SESSION['user']), или session_unset.