Как я написал свою CMS, и почему не рекомендую вам делать то же самое
Работа над программами управления контентом CMS (content management system) полна чудес. Под катом поучительная история Petr Palas. Если у вас все хорошо с английским, то в оригинале текст можно почитать здесь. Enjoy!
Написание собственной CMS — это как держать у себя дома слона.
Для большинства людей гораздо проще сходить в зоопарк.
В 2000-м я обучался в университете и работал Интранет-разработчиком: публиковал в Интранет контент, написанный на статичном HTML. Это была моя первая «программистская» работа, и я ею наслаждался. Пару недель.
Потом стало очевидно, насколько мои обязанности являются однообразными и неавтоматизированными. И я начал писать приложение на классическом ASP, которое позволяло бы пользователям самостоятельно управлять контентом. Я и понятия не имел о существовании такой штуки, как Content Management System, и потому изобретал велосипед. В то время существовало всего несколько коммерческих CMS, зачастую стоившие сотни тысяч долларов. Учитывая распространённость и ценовой диапазон этой категории ПО, неудивительно, что не я один пытался уменьшить свои неудобства и повысить эффективность, создавая собственную CMS.
К 2004-му почти каждое интернет-агентство создавало собственную CMS, нередко кастомизируя под конкретных клиентов. Это приводило к появлению десятков модификаций — кошмар с точки зрения управления. «Это бессмысленно», думал я. К тому моменту я уже написал несколько специализированных CMS и снова заскучал. «А что если написать CMS, которая может быть полезна для любого сайта?» В результате я организовал компанию Kentico Software, чья миссия была очень проста: создать CMS, которую любой разработчик в мире может использовать для создания любого сайта.
Сюрприз: люди всё ещё пишут собственные CMS!
13 лет спустя меня ещё поражает количество людей, которые пишут собственные CMS. Существует масса зрелых продуктов, под все виды проектов: от open source до коммерческих систем корпоративного уровня, от лучших в своём классе до универсальных «всё-в-одном».
Так зачем кому-то до сих пор нужно писать собственную CMS?
Ответ прост: люди делают это из-за разочарования.
Традиционные веб-ориентированные CMS чреваты недостатками и ограничениями. Но правда в том, что все эти разочарования уже утратили актуальность. Знаю, звучит лицемерно. Ведь мне помогло написание своей CMS, так почему это не поможет другим?
Позвольте объяснить.
Самописные CMS устарели из-за headless-архитектуры
За последние 15 лет рынок CMS и технологии начали идти в ногу с изменениями цифрового ландшафта и пользовательскими ожиданиями, связанными с многочисленными разнообразными устройствами.
И сегодня новое поколение CMS-технологий — облачные, с headless-архитектурой — скоро совершит революцию в сфере управления контентом. В отличие от традиционных решений, headless-CMS сосредоточены только на управлении контентом и на том, чтобы сделать его доступным любому приложению посредством API. Поскольку у таких продуктов нет «головы» (head), которая обычно диктует, как нужно отображать контент, headless-CMS оставляют вопрос дизайна полностью на откуп разработчикам.
Поэтому не слишком разумно сегодня писать собственные CMS — если только вы не хотите стать вендором таких продуктов. Но мне легко говорить. Ведь я же не единственный, кто столкнулся с многочисленными недостатками и нашёл много причин, по которым самописная CMS может быть выходом из ситуации.
Так что давайте рассмотрим основные причины недовольства разработчиков и выясним, почему же они устарели.
Причина №1: стандартные CMS ограничивают мой творческий потенциал
Первое, на что жалуются фронтенд-разработчики, это вмешательство CMS в их HTML-код и необходимость искать обходные решения.
Но с этим покончено: headless-CMS дают вам полную свободу и никак не влияют на результирующий HTML-код. Для извлечения контента из репозитория вам достаточно лишь с помощью своего любимого языка программирования вызвать соответствующий REST API.
И более того, вы сами полностью решаете, как будет этот контент отображаться!
Причина №2: интерфейсы стандартных CMS слишком сложны
Многие традиционные CMS в последние десять лет существенно разрослись. Хотя все они начинались с идеи предоставления замечательного решения по управлению контентом, большинство не смогли избежать «ползучего улучшизма», поскольку они проникли в электронную коммерцию, автоматизацию маркетинга, системы бронирования, почтовый маркетинг и так далее. Хотя для кого-то удобно иметь всё в одном месте, но новым пользователям трудно изучать такие CMS. Большинству нужно всего лишь управлять контентом, избыток опций снижает продуктивность.
Новые headless-CMS создаются исходя из другой предпосылки: это всего лишь один из фрагментов мозаики микросервисов, и потому эти продукты обладают пользовательским интерфейсом, оптимизированным именно под управление контентом. В то же время современные CMS предоставляют API управления контентом, позволяющие создавать собственные интерфейсы редактирования поверх их репозиториев контента. Это удобно, если вы хотите создать более специализированный интерфейс или интегрировать в приложение возможности по редактированию контента, а не перенаправлять пользователей в другой интерфейс.
Причина №3: стандартные CMS слишком дороги
«Мы не хотели платить Х рублей за коммерческую CMS, поэтому решили написать свою». Если вам не нужно что-то гораздо более простое, чем реальная CMS (вроде управления списком новостей), в долгосрочной перспективе вы не сможете сэкономить с помощью самописной CMS.
Сегодня можно выбрать из массы бесплатных CMS с открытым исходным кодом, или воспользоваться облачной headless-CMS, чья ценовая политика учитывает особенности потребления, что всегда будет выгоднее разработки и использования собственной системы.
Причина №4: стандартные CMS не безопасны
Для многих организаций обеспечение безопасности CMS является кошмаром. Поэтому некоторые разработчики думают: «Если мы напишем свою CMS, то хакерам будет труднее найти в ней баги».
Классическое обеспечение безопасности через неясность (security by obscurity).
Да, хакеры могут воспользоваться известными прорехами в безопасности, но широко используемые CMS обычно тщательно тестируются. И обычно основным источником проблем является неприменение в компаниях свежих фиксов различных применяемых плагинов.
С облачными headless-CMS у вас всегда будет самая свежая версия. CMS хостится напрямую у вендора, который прекрасно знает как код, так и инфраструктуру, и может уделять соответствующее внимание вопросам безопасности.
Причина №5: стандартные CMS не вписываются в мою архитектуру
В определённых ситуациях это было справедливое замечание. Наиболее традиционные CMS предназначались к использованию в качестве центральной платформы, на которой всё должно строиться. Это означало, что код вашего приложения был тесно связан с CMS, как это проиллюстрировано выше. Вы были ограничены своей CMS-платформой, языком программирования, циклами обновления, масштабируемостью и безопасностью.
Не удивительно, что множество программных архитектур не могли следовать по этому пути! Приходилось создавать прокси-слой между CMS и приложением, или — сюрприз! — писать свою собственную CMS.
К счастью headless-архитектура позволяет легко обращаться к контенту с помощью API и писать свои приложения так, как вам хочется.
Причина №6: многие клиенты всё ещё пользуются написанной нами CMS
Многие цифровые агентства продолжают поддерживать свои CMS ради клиентов. Некоторые делают это намеренно, чтобы привязать к себе клиентов, которые не смогут так просто перейти к другому агентству.
В целом использование агентствами собственных CMS не даёт никаких преимуществ. Если они не стремятся стать CMS-вендорами, то им лучше как можно скорее отказаться от самописных систем. К счастью, во многих агентствах уже есть понимание, что это тупиковый путь и что они не могут быть конкурентоспособными с проприетарными системами. Но они боятся прыгнуть в неизвестность и перевести клиентов на стандартные CMS. В каких-то случаях это эмоциональное или политическое решение. Например, если CMS была написана основателем компании много лет назад, или это детище лучшего разработчика, который, ко всему прочему, ещё и единственный, кто знает, как оно работает.
Мой совет: сделайте этот смелый шаг, пока ваше агентство не проиграло!
Выберите современную CMS и выделите основные преимущества, которые привлекут к ней ваших клиентов. Наконец, дайте своим разработчикам новую игрушку! Подсказка: большинство из них очень быстро влюбятся в headless-CMS.
… и две причины, когда использование самописной CMS оправдано
Честно говоря, всё же есть ситуации, когда использовать собственную CMS либо целесообразно, либо это вообще единственный возможный вариант:
• Управление контентом — основа вашего бизнеса: если вы компания наподобие Medium, то вам наверняка нужен абсолютный контроль над системой управления контентом. Если вы большое издательство с десятками публикаций, и вам нужен полностью кастомизированный рабочий процесс, то вам тоже может понадобиться собственная CMS (или хотя бы кастомный редакторский интерфейс). Однако в мире ОЧЕНЬ мало компаний, относящиеся к этим категориям и для которых оправданы подобные инвестиции.
• Уникальные требования по безопасности или соблюдению законодательства: опять же, существует немного организаций, вынужденных придерживаться специфических правил, когда речь идёт о хранении контента, обеспечении безопасности, программной архитектуре или инфраструктуре, и эти правила не позволяют использовать стандартные CMS.
Если что-то из сказанного — про вас, то помните, что каждый час, потраченный на создание своей CMS, это час, который вы могли бы потратить на создание конкурентного преимущества, а не на изобретение колеса.
Не пишите свою CMS, пока не возникнет очевидный бизнес-случай
Люди ВСЕГДА недооценивают объём работы по созданию настоящей CMS.
Возможно, в первый момент вы подумали: «Что такого сложного в CMS? Я просто возьму задокументированную базу данных и прикручу сверху интерфейс редактирования». Это лёгкий старт, но ещё не настоящая CMS. Когда вы начнёте добавлять уровни, например, моделирование контента, языковые варианты, рабочий процесс, разрешения, доставку контента, поиск и так далее, то обнаружите, что разрабатываете и управляете по-настоящему сложным решением.
Надеюсь, сейчас вам стало очевидно, что написание своей CMS — паршивая идея. Это замечательное упражнение в программировании, но не основа вашего бизнеса — если только вы не CMS-вендор.
CMS своими руками
Существуют ли маны или книжки по написанию cms или это только для тру нинзь?
Если у кого-нибудь была такая проблема и у него есть литература, то может поделитесь а?
Очень хочется просвещаться. Сам то я со временем нагуглю, но пока я буду искать что-то стоящее пройдет много времени, которое я мог бы потратить на чтение и просмотр.
Автор, а что гуглить. Есть минимум 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-звенная архитектура.
Не смешивайте логику (сложные вычисления, обращение к БД) и шаблонизацию. Лучше сделайте 2 файла: один с кодом, другой с шаблоном. В идеале, шаблонизатор получает от контроллера значения переменных и, кроме хелперов, никакого другого кода не вызывает.
C — контроллеры. Но это самая простая часть, контроллер — это просто класс с методами типа viewAction(), editAction() и роутер, который смотрит на УРЛ и вызывает нужный контроллер. Посмотрите, как устроен Zend_Controller и Zend_Front_Contriller, и сделайте так же, но попроще. выкинув 90% функционала — он вам не понадобится.
Нужно как-то сделать систему компонентной без сильных связей: чтобы ядро могло работать и без модулей, а добавление модуля не требовало дописывания кода в ядро. Почитайте про Dependency Injection, а также Observer (observer — это когда мы делаем функцию addEventListener()).
Не используйте хуки, как в Друпал. Это дурной и порочный путь, взятый видимо из древных времен и программирования на Си.
Что еще. Освоив все эти понятия, у вас в принципе не будет сложностей написать CMS, но почитайте еще мои советы по тому, как писать правильный код с исп. ООП: habrahabr.ru/qa/17158/#answer_70869
Написание своих велосипедов, в общем, полезно и способствует расширению кругозора разработчика, заставляет его изучать разные подходы к написанию кода.
Ну что еще. Если (в чем я сильно сомневаюсь) благодаря моему скромного совету вы все же сможете пройти этот нелегкий путь и станете успешным разработчиком, можете заплатить мне денег. Я не против.
Свой движок сайта на php в связке с MySql, для начинающих
Среди обычных пользователей различных CMS, есть те, у которых есть желание создать свою собственную CMS. Одним из таких пользователей был я.
В конце декабря я загорелся желанием сделать что то свое, при очень малом знании языков. И теперь, я хочу помочь рядовому пользователю несколько освоится в связке php и MySql, и в том, как можно написать свой сайт.
Во первых, мы должны понять, что у нас будет за сайт, и какова будет его структура.
У меня была идея фикс — истории из игр, чтобы любой пользователь мог их добавлять и выводились они постранично из БД MySql.
И так, сначала разметим структуру страницы. Для меня это было:
Header
Menu
Content
Sidebar
Footer
Header — шапка сайта;
Menu — соответственно меню;
Content — содержимое страниц в моем случае истории, но содержимым может быть все, что угодно;
Sidebar — боковая колонка, где находились новости и лучшие истории;
Footer — нижняя часть сайта (подвал) с копирайтом.
Также, нельзя забывать о подключении к базе данных — ведь страницы у нас динамические, и всю информацию мы будем брать оттуда, поэтому нам понадобится еще пара вещей — файл с конфигом, а также файл, который будет подключать нас к базе данных.
После этого, я создал 6 пустых php: index.php, config.php, connect.php, header.php, menu.php, content.php, sidebar.php и footer.php.
Забыл отметить, что для удобства редактирование кода стоит скачать программу Notepad++ — русская версия в ней есть.
Итак, начнем с простого. Для начала, в файл index.php добавим вот этот код:
Тэгами мы открываем и закрываем наш код (вместо
Создание собственной системы управления контентом сайта на PHP своими руками
Как создать собственную полноценную CMS. Идеология, технические нюансы и подводные камни
1. Нужно четко определиться что вам жизненно необходимо написать свою собственную систему управления контентом
Разработка своей собственной платформы займет очень много времени, в лучшем случае от 1 года вашей жизни. Если вы не готовы потратить такое огромное количество времени на это занятие то вам лучше сразу отказаться от этой затеи.
Вы должны понимать что это реально для ваших возможностей
Технически для создания проекта уровня полноценной CMS требуется не малое количество опыта и знаний, приступая к нему у вас должно быть ощущение что вы знаете что все получится, вы должны быть уверенны в своих силах.
Неожиданные проблемы при создании — как неизбежность
Подводные камни которые встанут у вас на пути лучше устранять в самом начале иначе в дальнейшем их размер может оказаться больше ожидаемого.
1. Идеология
Для начала скажу что все приведенные мною данные являются лично моим мнением, и я не исключаю возможности что в чем то возможно мыслю не верно, ошибаюсь или заблуждаюсь. Но считаю огромным плюсом ко всему сказанному, даже если на ваш взгляд я и не прав: я уже являюсь создателем довольно мощной платформы с потрясающими возможностями и учитывая это замечу сразу что любое негативное мнение людей еще не сделавших своего личного проекта относящегося тематически к этим материалам рекомендую рассматривать как мнение личности не имеющей соответствующего опыта в плане реализации создания CMS на языке PHP.
Зачем? и что? для этого нужно.
Давайте рассмотрим саму идеологию создания платформы, что же приводит человека отказаться от имеющихся решений.
Ответ на удивление прост. Если все будут делать сайты на своих лично разработанных платформах то в интернете придется закрыть 80% топиков форумов за ненадобностью. Почему? да потому — что основную долю трудоемкого время у людей отнимает именно поиск ответов на решения вопросом связанных именно с использованием чужого ПО. В то время когда я работал с чужими платформами — я стоял на месте. И сейчас занимаясь собственным проектом я двигаюсь в перед. Вперед двигаются и мои конкуренты, но чтобы быть в курсе всех технических вопросов устройства чужих «контент менеджеров» мне потребуется постоянно следить за всеми «движениями в коде» разработчиков, что совершенно не требуется при работе со своим личным проектом. Занимаясь собственным проектом человек может рыться в интернете в поисках интересных решений для себя, а не искать что-то для решения трабл в чужом коде, модулях, плагинах.
Написать этот хаб меня спровоцировала статья которая стала последней каплей, это была статья с этого-же хабрахаба о использовании систем от спама на сайтах. Просто уже до идиотизма надоело видеть как в поле зрения фигурируют обсуждения все тех-же проблем в тех-же узких местах. Создавая платформу я провозился несколько дней выдумывая собственную капчу, по моему мнению ее не должен пройти ни один бот. Ну и что вы думаете? Все отлично работает и я не видел еще не одного спамера. Также я не видал попыток взлома, подбора паролей, просматривая логи я вижу как вся нечисть уходит стороной. Все классно ребята! Хочется сказать — Делайте! и вам воздастся.
Ну а теперь перейдем к следующей части.
технические нюансы
Где начинать?
Естественно сервер должен стоять прямо перед носом, либо это ненужный компьютер либо в самом крайнем случае что-то наподобие денвера. Единственное позаботьтесь о надежности, потерять все данные через пол года работы будет очень обидно и провально.
Почему нельзя использовать хостинг в интернете под разработку?
А как вы собираетесь редактировать и создавать несколько тысяч файлов кода? Вы что при отладке каждого участка будете ждать выгрузки и загрузки файлов на далекий сервер? Сохранять и открывать файлы потребуется очень часто в течении всего срока разработки и тормоза связанные с удаленными серверами вас просто съедят — поверьте. Сервак под боком! — это первое правило.
С чего начинать?
Первым делом врубаем в настройках сервера полный вывод всех ошибок.
Если сервер настроен, и вы готовы к работе то возникает очень тяжелый момент, вы возможно осознаете что совершенно не можете понять за что нужно браться именно сейчас. Для решения этого момента вам нужно не напрягаясь спокойно раздумывать и записывать все мысли, делать зарисовки. Этот момент будет длится довольно долго, и со временем так и не сдвинувшись с места вы упретесь в целую кучу сложнейших проблем.
Этот момент обязательно нужно пережить, я конечно могу вам подсказать что именно надо делать но намного выгоднее будет если вы сами по размышляете несколько дней и попытаетесь что-то понять и придумать. Гвоздем на этом этапе является именно то что вам требуется правильно задать стратегию построения движка. Выбрав изначально ошибочное направление вы уткнетесь в тупик находясь уже далеко в пути и дорога назад покажется вам еще более мучительной. Собственно приведу пример: Я не занимался объектным программированием на PHP, но мне пришлось изменить все функции работы с базой данных и переписать полностью все апи движка когда я прочел в интернете отказ поддержки от какой-то одной не объектной, используемой мною функции.
В этот момент я осознал что объектная модель будет вытеснять обычный стиль кодинга и для того чтобы моя CMS не отставала мне необходимо поменять подход на объектно ориентированный. Было очень неудобно и обидно понять это находясь уже далеко за стартом. И если честно, зная об этом ранее я бы отказался писать код сам и продолжил пользоваться чужими решениями так как я плохо знал объектный подход. Но ничего страшного, несколько недель изучения и все стало понятно как день.
То есть что я хочу сказать: Не нужно рваться писать код. Для начала напишите всю вашу платформу набросками да картинками, и проанализируйте все что вы придумали. Рассмотрите пути решения поставленных задач. Это займет уйму вашего времени, но поверьте если вы этого не будете делать то потом вас может ждать крах. Зайдя в неудачный поворот и поняв что все напрасно вы возможно не сможете подняться. Начать все заново будет еще тяжелее, чем просто начать с нуля.
Далее по техническим нюансам: Не берите пример с других платформ, можно подсматривать но не нужно повторять. Вы можете подцепить грубую ошибку. Так например в одной из известных платформ есть реализация мультишаблонов для любого типа модулей, это очень классно придумано, но и как раз в этой же реализации есть очень неприятный недостаток. Сейчас я вам его опишу и вы сами поймете о чем идет речь. Движек собирает в кучу все что тащится вместе со всеми позициями, плагинами, модулями и выплевывает это на страницу, и даже если модуль не используется то его ява и css будут красоваться подгруженными на всех страницах подряд. Естественно движек работает отлично но почему бы не проверять что есть на страничке а чего нет и не давать вылетать тому что не требуется. Но к сожалению реализовать это у вас получится лишь продумав эти моменты еще на этапе «карандаша» когда код будет готов изменения принципа работы будут просто катастрофичны. Вы не представляете ка тяжело отладить много сотен взаимодействующих собственных апи и после этого узнать что сам принцип в подходе имеет недостаток. Устранять баги на этом этапе становится нереально трудным занятием.
До тех пор пока вы не нарисуете весь каркас движка приступать к коду нет смысла — Продумывайте абсолютно все!
Касаемо чисто технического вопроса, имея уже довольно обширный опыт хочу сказать, что я бы не рекомендовал организовывать подключение модулей или блоков сайта по GET параметрам в стиле index.php/mod=mod_content&article=32… это решение очень распространено и оно является совершенно утопическим, оно на первый взгляд только дает удобство, на самом деле если ваш URL будет index.php/?page=45 и не более того, а дальше ставится обработчик всего что принадлежит вашей «page» то жизнь станет намного проще а условия разработки более гибкими.
Еще несколько советов:
Правильно выбранный порядок загрузки файлов с функциями очень с экономит время, на деле часто натыкаешься с потребностью использовать что-то что находится там что еще не подключилось к системе. Лоадер ваших библиотек будет пливаться как старый иж в кукурузном поле если вы не угадаете заранее что и где вам сможет понадобиться.
Перед любым применением переменных проверяйте ее на инициализацию, конечно вы не не заметите разницы если даже и не будите этого делать но по факту вылезет следующий глюк — на рабочей платформе в случае атаки, перебора паролей, неадекватного бота, происках спамера — вы загляните в логи. И как раз там и обломитесь. Использование неициализированных переменных завалит вам логи до такой степени сообщениями о том что переменная «юндэфинед» что по сути вы просто не найдете то зачем пришли из-за этих прекрасных «SMS». Большинство хостингов где возможно придется жить вашему детищу будут настроены таким образом что при первом же обращении к сайту лог завалит напрочь.
Конечно при включенном выводе ошибок и уверенности что переменная будет определенна до ее использования вы понадеятесь что все прекрасно, но возможно как только вы переедите на новый хостинг по каким-то причинам сайт на вашем движке рухнет. И в двух случаях из трех окажется что в ваших файлах идет перебор пустого не заданного массива — это буде 503 ошибка на рас. И возможно найти эту траблу удастся не за один месяц. Я потратил 2 недели пока один из хостеров не помог мне с отладкой, если бы сам хостер не участвовал в решении проблемы я так думаю что я мог и не справится, у меня уже просто опускались руки. Ровно два раза сайт падал натыкаясь на этот узкий момент.
Причина его появления в основном связанна с запросами в базу, мы настолько наслышаны об опасностях инъекций и самого качества запросов, что при написании функций делаем шизофренически много проверок всех данных прежде чем отправлять запрос, но забываем проверять валидность выдачи базы. На домашнем сервере база может работать без нариканий а вот у хостера вместо ответа «что нет данных по запросу» база может просто промолчать, и если это молчание присвоить переменной и выкинуть return_ом из класса работающего с базой, думая что там в худшем случае летит false — то мы ошибемся, и даже его там не окажется. Поэтом ставим на все переменные if(!empti($var)) и юзаем дальше.
В остальном все технические вопросы по самому языку PHP прекрасно раскрыты в мануалах, и там вы найдете все что угодно, лезть в гуглы практически не приходится. В гуглах кстати вы будете искать ответы когда начнете прикручивать к движку всякого рода внешние API и создавать свои собственные, на этот момент вы будете активно внедрять ява коды и тут как раз может возникнуть миллион вопросов которые нет возможности решать по документации.
Я не ставлю целью сделать одним хабом самоучитель по созданию CMS платформ для управления контентом так что на этом можно закончить обзор технической части вашей работы.
Подводные камни
Вам нужен свой сервер, но не замарачивайтесь до синяков под глазами, не стоит ставить сложных систем. LAMP и даже денверо подобного сервера вам будет достаточно. Если вы будете уделять много времени самому серверу вы можете в конце пожалеть что зря его потратили так как жить в интернете ваш проект будет возможно даже в «более плохих условиях».
Следите за размером базы данных, большинство хостеров ограничивает по размеру загрузку бекапов баз и вы можете неожиданно узнать что ваша база не пролезет в новый дом.
Делайте бекапы базы в процессе ее расширения и пытайтесь заливать на доступные вам хостинг аккаунты. При заливке дампа вы возможно узнаете что ваш дамп имеет недочеты мешающие его воссозданию в другом месте, упереться в такой глюк очень неприятно когда база практически готова и для его устранения вам возможно придется многое изменить. Вам будет намного проще отладить базу еще до того как она обрастет таблицами и данными. Проверяйте работоспособность дампов базы от вашей системы на других площадках у хостеров.
Не парьтесь с документированием, я встречал очень грамотно и красиво оформленный комментариями с описанием код — несущий минимум функционала. Зачем он нужен? Конечно хочется красоты и аккуратности, пожалуйста — оформляйте каждую функцию если у вас есть лишние 5-6 лет для этого. В меньшие сроки, потея над каждым сантиметром описания вы вряд-ли уложитесь рассчитывая написать что-нибудь достойное по функционалу. Привыкайте видеть код, зачем его подписывать? вы что читать просто код не можете? Учитесь. Вы думаете что забудете зачем та или иная функция или переменная? А для чего давать им такие имена чтоб потом не помнить? Называйте все соответствующими именами и проблем с пониманием вашего кода не будет не у кого.
Основной проблемой при написании будет являться сам стимул и потраченное время. Нужно сделать очень много работы, у меня при наличие всех знаний и «бумажного плана действий» на написание кода движка ушел ровно год. При этом темп работ был ужасающий, примерно двое суток с перерывом на поспать и снова на двое суток кода. Проведя так целый год, результатом становится не только твое детище а еще и впавшие глаза, упавшие нервы и напрочь поехавшая крыша.
Сложного в написании совершенно ничего нет, просто объем работ очень большой и в нормальном ритме одного человека это от двух — трех лет и больше. При условии наличия наработанной базы своих наборов скриптов и сотен сайтов опыта за спиной на всевозможных платформах.
Надеюсь что мне удалось рассказать что ждет и чего стоит создание своей CMS платформы для управления контентом WEB сайтов. При изложении своих мыслей я имел ввиду, полноценной платформы — достойного уровня и с обширным функционалом, не уступающей по качеству не одной из существующих на данный момент а в чем-то даже и стоящей уровнем выше.
Работать, работать и работать или всю жизнь только прикидывать и взвешивать. Посмотрите вокруг! кого вы считаете профи? Людей которые изучили мануалы и теперь разжевывают их всем остальным? А в чем их сила? Они написали свой движок? Запустили новые стандарты валидности CSS? а ну так у них сайт есть? Так много у кого есть… Карма хорошая наверно? Или они клиентам на битриксе по нашлепали уродов?
Профи только инженеры — создатели. Если все обсуждать с ними а не на форумах то вы увидите что людей с достойными знаниями намного меньше чем казалось. Потратить один — два года, и выйти из конкуренции на всю жизнь. Выпить тепловоз чаю и выкурить короб сигарет размером с пяти этажный дом, разучится говорить в живую, смеяться без причины или наоборот найти причину громко посмеяться глядя на PHP код приведенный на хабрахабре в одной из веток.