Автор, а что гуглить. Есть минимум 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
Написание своих велосипедов, в общем, полезно и способствует расширению кругозора разработчика, заставляет его изучать разные подходы к написанию кода.
Ну что еще. Если (в чем я сильно сомневаюсь) благодаря моему скромного совету вы все же сможете пройти этот нелегкий путь и станете успешным разработчиком, можете заплатить мне денег. Я не против.