Тимофей

Для начала профессиональные дизайнеры скорее будут использовать Illustrator (а то и Sketch), чем Photoshop :)
А программ, которые сгенерируют из макета вменяемый код, в природе не существует. Ты скорее на адаптацию получившегося кода будешь тратить больше времени, чем на написание его с нуля.

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

А в чем, собственно, проблема? Можно ведь оставить и старый способ фильтрации, и новый добавить.
С точки зрения СЕО это вряд ли на что-то повлияет, поскольку поисковые системы не станут отправлять формы.
А так создать роут типа Route::get('/catalog/{segment1?}/{segment2?}', 'Controller@getIndex'), где как-то сопоставлять сегменты и ограничивать выборку по ним.

А как это, собственно, можно сделать по-другому? Все правильно в вопросе написано. Можно только еще добавить для удобства scope, добавляющий в запрос колонку с ценами, чтобы все это более прозрачно смотрелось.

Возможно, дело в том, что у тебя в конфигах waterline стоит migrate: 'safe', в таком случае миграции не производятся и индексы, соответственно, не создаются. Попробуй сделать migrate: 'alter' (только если не в production среде!) или задать индексы вручную.

Прочитал весь вопрос, но на ответы меня не хватило, так что могу что-то повторить)

Момент 1. Языки. Если ты реально знаешь C++ (указатели, управление памятью, стек, куча, ООП и т.д.), то ты автоматически уже почти знаешь PHP, Python и Ruby. У тебя есть преимущество при изучении этих языков, так как ты уже имеешь представление о том, что реально происходит в твоей программе и, что тоже важно, под капотом интерпретатора. Сами эти языки (с точки зрения подходов и принципов) не так уж сильно отличаются друг от друга. Каждый из них имеет ряд своих особенностей, но их не так много и освоить их не составит труда. При этом изучив любой из языков ты совершенно без проблем перескачишь на любой другой.

Момент 2. Фреймворки. Вряд ли в реальных проектах получится взять язык N, и ручками с нуля что-то на нем делать. Скорее всего будут использованы какие-то фреймворки. Но тут, опять же, достаточно взять любой доступный на языке N фреймворк, чтобы понять подавляющее большинство остальных. Yii, Django, Rails, Laravel - все они схожи гораздо сильнее, чем может показаться. Итог - изучив один из них можно легко перескачить на другой. Каждый перескок будет даваться все легче (актуально и для предыдущего пункта).

Момент 3. Сервер. Если ты хочешь заниматься именно вебом, то сервер, очевидно, его неотъемлемая часть. Тут у языков немного больше отличий, чем в первых двух моментах. Но суть одна - если брать самую распространенную конфигурацию, то должен быть т.н. front-end сервер (не путать с front-end частью приложения), который отдает обычные файлы, не беспокоя само приложение, и back-end сервер (или сервер приложения). Back-end сервер как раз и занимается выполнением кода приложения и тут в зависимости от языка свои особенности по его установке, настройке и связке с front-end сервером. Но все в пределах разумного и вполне реально изучить. Менее распространенные конфигурации можно будет изучить по ходу, да и суть будет похожа.

Момент 4. Node.js. Да, для него отдельный пункт. В JavaScript все построено на асинхронном программировании, поэтому он сильно отличается от "классических" языков. В подробности вдаваться не буду, но рекомендую как минимум с ним ознакомиться, чтобы иметь общее представление об асинхронном программировании, в частности на сервере. Можно взять не Node.js, а какие-то похожие варианты на других языках, но JavaScript основан на этой идее, поэтому я считаю., что оптимально взять именно его.

Момент 5. Лирика. Любая технология решает опеределенный круг задач, поэтому говорить, что она "плоха" просто некорректно. Можно сказать, что она не решает данную конкретную задачу или же есть какая-то другая технология, которая решает ее лучше. Теперь конкретно про PHP, Python и Ruby. Как ты успел заметить в этом вопросе, существует очень много споров о том, что же лучше. Сам факт неугасания этих споров в течении многих лет говорит о том, что нельзя однозначно их разрешить.
Так же есть тренд говорить, что PHP язык для лохов. Но говоря так человек лишний раз доказывает свою некомпетентность и невежество. Исторически так сложилось, что PHP самый распространенный язык, поэтому на нем написано огромное количество вещей разных назначений и качества. Людей, которые могут на нем писать (я намеренно не стал использовать слово "программист"), очень много и логично, что качество кода многих из них оставляет желать лучшего. Многие говорят про порог вхождения, но я бы не сказал, что у того же Python этот порог выше. Плюс PHP за последние годы приобрел много хорошего и как язык, и как его инфраструктура. Короче, можно смело брать PHP :)

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

include как бы намекает, что можно вставлять куски конфигов из отдельных файлов. Создаешь файл с тем, что нужно, и просто пишешь include my-awsome-config-file.

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

Если вопрос именно в том, чтобы использовать PostgreSQL с нодой, то проблем никаких - есть sequelize, waterline и, думаю, еще много модулей для удобной работы с базой и ORM. По скорости выигрыш тоже будет скорее всего. Ну а в остальном слишком много "но" и "если", чтобы можно было однозначно сказать, стоит ли это делать или нет.

Потому что при наследовании нельзя изменять доступность функции. Если нужен синглтон, то ты по определению не сможешь унаследоваться от класса с открытым конструктором. А сделано это для того, чтобы объект любого класса, унаследованного от данного, гарантированно обладал всеми функциями родителя, в частности и возможностью создания новых объектов. Иначе теряется смысл наследования.

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

trait ClosureConfigurable {
    public function configureWith(Closure $closure) {
        $closure($this);
    }
}

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

Я, конечно, могу быть немного не прав, но мне всегда казалось, что такие штуки, как Bootstrap, являются набором уже готовых к использованию элементов, то есть термин "верстать" для них не совсем пригоден. Разве что немного подпилить по мелочи там, где это действительно необходимо, но не верстать.

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

И уж точно не нужно лезть в исходники фреймворка. Для этого (по крайней мере у Bootstrap'а, у остальных, наверняка, тоже) есть less/sass/stylus переменные, которые можно (и даже нужно) переопределять под себя. А в каких-то индивидуальных случаях никто не мешает перелопатить стили в после подключения стилей фреймворка.

Почитай про включаемые области, это как раз то, что нужно.

Можно ли сделать семантически-адаптивную и бла-бла-бля своими руками

Можно, ибо разработчики существующих решений тоже делали это, очевидно, своими руками.

но я хочу понять и научиться делать собственноручно

Конечно, делай, раз хочешь понять и научиться. В чем вопрос-то?

Куда смотреть, статьи,книги,советы

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

Еще хотел бы узнать нужна ли галерея для мобильных устройств?

Ты бы пользовался галереей на своем мобильном устройстве? А целевая аудитория сайта? Только у нее есть ответ на вопрос.

Посадочные страницы с точки зрения верстки принципиально ничем не отличаются от любых других. По flex'у выше ответили.

Вот. Думаю, исчерпывающе.

Через $rootScope?

Такого в ангуляре нет, можно только сделать как-то так:

<div ng-hide='editMode'>{{content}}</div>
<div ng-if='editMode' contenteditable>{{content}}</div>