Тимофей

Не знаю, сработает ли это для множественного значения, но тут точно есть проблема в том, что неправильно составлено значение атрибута ng-options, так как фактическим значением, передаваемым (и читаемым из) ng-model будет полный объект account, а не account.id. Нужно использовать select as label for value in array, где select => account.id, label => account.title, value => account. А вообще вопрос бы отпал сам по себе, если бы ты поглядел сюда. Там как раз есть в таблице ровно то, что я написал.

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

$filter -> fire(array('arg1' => &$arg1, 'arg2' => &$arg2));

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

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

Если имел место редирект (а он тут почти наверняка был), то можно посмотреть в панели разработчика все запросы, которые отправлял браузер, в частности запрос, который получил в ответ команду на редирект.
А так - 500 ошибка где-то в приложении отправляется вручную скорее всего, так что нужно сначала выяснить, где конкретно. Скорее всего какой-то middleware типа bodyparser'а не сумел обработать запрос. А вообще странно, что был именно редирект на /server-error. По-хорошему ошибку нужно выдавать не на редиректе, а непосредственно на странице, на которой она произошла. Ну и еще в консоль приложения загляни, там может тоже что-то полезное есть.

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

3 заветных слова: наследование, инкапсуляция, полиморфизм. По ним можно много нагуглить.
Элементарный пример нарушения принципа инкапсуляции - объявление public поля класса. Нужно все поля делать private, а доступ к ним организовывать через методы доступа типа get..., set... или как-то более прозрачно, если позволяет язык (__get, __set в php, свойства в C#). По наследованию и полиморфизму накосячить уже сложнее, так как этого не позволит синтаксис скорее всего. Хотя кто знает, какие у человека есть скрытые возможности...

index0h: Нельзя "знать node.js". Это как сказать, что я знаю не Java, а JVM или не C#, а .NET.

Знать надо JavaScript, а в случае с Node.js нужно дополнительно иметь представление об архитектуре серверных приложений (хотя Node.js это не только сервер, а по сути возможность писать на JS вообще все что душе угодно) и о том, какие задачи можно решить модулями npm. Вернее даже не знать, а уметь гуглить и понимать английский.

Но проблема в том, что на хорошем уровне JS знает со значительно большей вероятностью фронтендщик, чем бэкендщик. Отсюда проблема поиска: чтобы писать серверное приложение на Node.js - это либо фронтендщик начинает осваивать сервер, что, безусловно, похвально, но требует понимания многих вещей, с которыми человек ранее не сталкивался, либо бэкендщик начинает осваивать JavaScript, для которого, скорее всего, в новинку событийный подход и другие моменты из мира JavaScript который, как известно, во многом сильно отличается от классических языков с поддержкой ООП. Это я еще не упомянул тот факт, что Node.js появился сравнительно недавно, и специалистов по нему чисто физически не может быть очень много.

Еще один момент. Программисты изучают то, что приносит деньги, то есть то, что более-менее востребовано. Компании, в свою очередь, стараются использовать технологии, для которых легко найти специалиста (привет, 1С-Битрикс). В итоге замкнуый круг, который потихоньку, конечно, разомкнется, но нужно время.

Итого: дефицит специалистов, которые бы умели все, что необходимо. К тому же ты хочешь получить и фронт, и бэк в одном флаконе, что еще больше усложняет поиск.

Можно, короче, по пацану сделать, вот так

$result = array_reduce($input, function($acc, $i) {
	if (isset($acc[$i['id']])) $acc[$i['id']]['num'] += $i['num'];
	else $acc[$i['id']] = $i;
	return $acc;
}, array());

// если нужен неассоциативный массив
$result = array_values($result);

Удалить-то можно - делаешь querySelector('[src="main.js]') - только вот беда в том, что пока скрипт не загрузится, он не появится в DOM, а, следовательно, ты не сможешь его гарантировано удалить до выполнения.

Набор программиста-хипстера

Делал тоже сайт по недвижимости на Drupal - нисколько не пожалел. Точнее тут не столько сам друпал упрощает работу, сколько модуль Views под него. По идее же на таком сайте должна быть куча разных списков с разными фильтрами, а это как раз задача для Views. Плюс очень тонкая настройка форм редактирования контента под клиента. В WP это тоже есть, конечно, но не на таком уровне. Гибкая генерация "красивых" ссылок с Pathauto... Короче, куча удобных штук. Только вот один очень важный момент есть - если с друпалом до этого не общался, то будешь достаточно долго разбираться. Но, на мой взгляд, оно того стоит.
Ну или да - фреймворк. Вряд ли с ним будет быстрее, зато полный контроль над тем, что происходит на сервере.

Просто не надо так делать. Один ресурс = один URL. Можно разве что через GET-параметр передавать tid, если на целевой странице в зависимости от него что-то меняется. А это легко делается в шаблоне ноды, так как у тебя есть доступ к параметрам через функцию args и доступ ко всем полям ноды через $content['field_name']['#items']. Если используешь views, то просто выводи unformatted list, renered entity.

В классе, реализующем ArrayAccess, в методе offsetSet отщепляешь левую часть ключа до точки, далее:
- Если у ключа не осталось правой части (то есть нет точек) - просто задаешь значение по ключу у $this -> collection (ну или как у тебя поле со значениями обозвано)
- Если осталась - при отсутствии значения по ключу инициализируешь его как new static
- Задаешь значение в дочерней коллекции по оставшемуся "хвосту" ключа

Ну и как offsetGet при этом реализовать, думаю, понятно.

Вообще лучше сделать это через __set, __get, чтобы не было некрасивых записей типа $obj -> set/getName, а просто обращаться к name так, как будто это поле объекта. Ну а sanitize нужно вызывать как static::sanitize. Только добавь к методу sanitize static. А, ну и обязательно нужно сделать PRIVATE $name, а то смысл инкапсулирования теряется.