Как создать собственную полноценную 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 код приведенный на хабрахабре в одной из веток.
Что лучше друг?