Автор, а что гуглить. Есть минимум 3 способа: расковырять простую Open-Source CMS (проблема: найти CMS с хорошей архитектурой и аккуратным кодом), устроиться в компанию, у которой есть своя CMS (а она есть почти у каждой студии), и наконец, написать самому правильно.

Маны нужны не по написанию CMS, а по используемым продуктам и технологиям.

Сначала надо определиться с задачей. Установите и попользуйтесь несколькими CMS, просто чтобы увидеть особенности их работы. (если вы не можете это сделать — вам надо изучать основы установки и настройки apache/mysql/whatever, а не CMS писать. Уходите практиковать эти навыки). Также, есть хороший сайт, где установлены демки десятков CMS и можно их посмотреть, не устанавливая.

Запишите, что вы хотите получить, сделайте наброски страниц. Определитесь с требованиями к вашей CMS. Какие в ней будут модули, как ими можно управлять.

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

Если вы еще не бросили эту затею, перейдем к следующему пункту. Проектирование архитектуры и написание CMS. Чтобы хорошо писать сложную CMS, нужен опыт и понимание того, как вообще писать сложные программы. Нужно глубокое знание HTTP/HTML/CSS/JS/SQL. А именно:

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

Что еще надо знать. Во-первых, надо иметь представление что значит MVC или 3-звенная архитектура.

M в MVC — это Model. CMS скорее всего будет хранить данные в БД — надо знать, что такое и как пишется DBAL (гуглите: PDO), плейсхолдеры в запросах, возможно, Table Gateway, ознакомиться с тем, что такое ORM, и почему PHP-ные ORM так тормозят. Если будете делать модельки, не храните значения полей в публичных свойствах — это неудобно и нарушает инкапсуляцию. Храните их в приватном массиве $attributes.

V is for View. Надо знать, что такое шаблонизаторы (прочтите мануал по Smarty, Django Templates, HAML и XSLT, чтобы иметь общее представление, какие они бывают). Для PHP хорошие варианты — использовать чистый PHP или XSLT, если осилите. Smarty — устаревший тормозной хлам, Twig тоже имеет недостатки. И не стоит ставить шаблонизатор, только, чтобы писать {$a} вместо [?= $a =].

Не смешивайте логику (сложные вычисления, обращение к БД) и шаблонизацию. Лучше сделайте 2 файла: один с кодом, другой с шаблоном. В идеале, шаблонизатор получает от контроллера значения переменных и, кроме хелперов, никакого другого кода не вызывает.

C — контроллеры. Но это самая простая часть, контроллер — это просто класс с методами типа viewAction(), editAction() и роутер, который смотрит на УРЛ и вызывает нужный контроллер. Посмотрите, как устроен Zend_Controller и Zend_Front_Contriller, и сделайте так же, но попроще. выкинув 90% функционала — он вам не понадобится.

Нужно как-то сделать систему компонентной без сильных связей: чтобы ядро могло работать и без модулей, а добавление модуля не требовало дописывания кода в ядро. Почитайте про Dependency Injection, а также Observer (observer — это когда мы делаем функцию addEventListener()).

Не используйте хуки, как в Друпал. Это дурной и порочный путь, взятый видимо из древных времен и программирования на Си.

Что еще. Освоив все эти понятия, у вас в принципе не будет сложностей написать CMS, но почитайте еще мои советы по тому, как писать правильный код с исп. ООП: habrahabr.ru/qa/17158/#answer_70869

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

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

Неизбежные накладные расходы.

Например, программа, которую вы написали, делает полезную работу в течение 10 мс, но на запуск и завершение виртуальный машины Ява уйдет дополнительно 5 секунд, и эти 5 секунд будут оверхедом.

Вообще, не увлекайтесь спецификациями. Марк Цукерберг как-то без них обошелся. Google тоже не следует строгим стандартам.

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

Вот, что стоит изучить (в любом порядке):

1) Начните с основ HTTP (только ради бога, не читайте спецификацию целиком, хватит общего представления о методах запросов, заголовках и теле запроса, кодах ответа 403/404/500/200/300)
2) Изучите основы HTML (есть раздел на сайте htmlbook). SGML вам хватит в том объеме, в котором он упоминается в спецификации HTML. PCDATA не упоминается в ней и потому знать про отличия от CDATA вам не нужно (ну если так хотите узнать, найдите спецификацию SGML и почитайте).

Обратите внимание, в некоторых (некачественных) статьях вы можете увидеть штуки вроде [br /] — самозакрывающиеся теги. Это ошибочный синтаксис, который употребляют авторы, путающие HTML и XHTML. В HTML такого синтаксиса нет (хотя в силу своей толерантности к ошибкам в HTML такой код как-то работает).

3) Изучите CSS и позиционирование элементов. Вот хороший учебник, разъясняющий тонкости всяких флоатов: softwaremaniacs.org/blog/category/primer/ А спецификацию CSS2.1, думаю, вы нагуглите сами, она довольно понятно написана.

4) Изучите яваскрипт (да, включая замыкания и прототипы) и DOM. Обратите внимание, jQuery — лишь обертка над DOM и не зная DOM, вы не сможете нормально пользоваться jQuery, вы лишь научитесь копипастить скрипты из интернета, не понимая, как они работают. После этого можете изучать jQuery, заодно советую заглянуть в исходный код, а не только читать документацию.

5) Изучите один из серверных языков, хотя бы основы

6) Изучите основы SQL

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

8) Изучите ООП

9) Изучите какой-нибудь серверный MVC-фреймворк

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

> А есть ещё и XHTML, который тоже имеет свои отличия…

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

> Клиентская разработка нынче редко обходится без всяких шаблонизаторов типа HAML/SASS

Вы еще Coffescript забыли упомянуть. Это очень спорные вещи, есть мнения как за, так и против. Но в любом случае, согласитесь, как-то странно изучать SASS, не изучив вначале CSS, верно? Начинающему это не нужно.

> а для эффективной серверной разработки всё и того сложнее: фреймворки, ORM, continuous integration, очереди задач и прочая-прочая.

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

По вопросу, где брать информацию: авторитетные источники (для поиска ответа во всех подробностях) — это спецификации W3C, официальная документация фреймворков, неофициальные источники вроде htmlbook, stackoverflow или Хабра — для того, чтобы быстро получить представление о тех или иных возможностях HTML. Еще можете какую-нибудь книгу почитать, только не старую.

В Стране Чудес.