Как написать свою cms

Как я написал свою 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-вендор.

Блог компании Parallels
Веб-разработка
Программирование
Отладка
WebGL

Рождение одного проекта или как написать свою CMS

Приветствую вас, уважаемые Хабравчане. Я очень долго шел к тому чтобы написать статью здесь о себе и своем проекте. В этой статье я хотел бы рассказать Вам мою историю зарождения идеи проекта. А также написать свою историю развития взглядов на разработку ПО в целом. Возможно даже, мне удастся передать часть знаний основанных на моем многолетнем опыте работы программистом. Поехали!

Oбо мне

Расскажу немного о себе. Меня зовут Александр, я работаю программистом более 10 лет. Мне приходилось решать задачи в разных областях бизнеса, таких как банковское дело, электронная коммерция, проекты структурирования данных, парсеры и прочие задачи «энтерпрайз» сектора.

Цель данной статьи показать одну из граней мира разработки ПО и возможно открыть новую дверь возможностей для других программистов. Что я имею ввиду под этим заявлением?

Этапы развития программиста

Наверняка ранее Вы уже читали статьи про этапы развития программистов. По моим убеждениям каждый программист проходит этапы развития в своей профессиональной карьере.

Я определил этот путь развития программиста в 5 этапов:

Первый этап это когда ты студент или ты еще новичок в программировании. Тебе нравится просто видеть результат того что ты запрограммировал, будь это окно с кнопочкой «Hello» или парсер данных который анализирует и структурирует.
Второй этап это когда ты уже пишешь сложные интеграции и используешь продвинутые фреймворки. И ты получаешь удовольствие от того что освоил очередной инструмент.
Третий этап это когда ты начинаешь разбираться как лучше структурно спроектировать приложение. И просто сходишь с ума от того что ты разделил правильно логику на компоненты.
Четвертый этап это этап бога разработки ПО. Ты понимаешь все предыдущие этапы и тебе нравится построить систему сборки и доставки всех модулей приложения в единый удобный автоматизированный установщик.
Пятый этап это самый грустный этап. Ты понимаешь что твоё любимое дело уже не приносит той былой эйфории и просто делаешь всё на автомате. Вот тогда наступает тот момент когда тебя распирает просто сделать свой продукт и вывести его на рынок тем самым решив чью-то проблему или просто улучшив какой-то рабочий процесс.

Рождение и смерть идеи

Как вы уже наверняка поняли, что эти этапы основаны на моем личном опыте. Поэтому возможно у кого-то будет совсем другой опыт развития. И я не заявляю что так и никак по другому. Дальше речь пойдет о том самом 5-ом этапе развития и что с этим делать дальше.

Однажды в мою голову упала одна очень интересная идея. Перед этим конечно я ходил неделю и думал какой бы сервис «запилить». Причем серьезно и обдуманно я решил делать что-то грандиозное.

Идея была такова, создать некую платформу, по сути веб-сайт, который позволит каждому желающему рассказать другим о своих умениях в чем-то где он преуспел относительно других. Например, заядлый рыбак, хочет поделится своим опытом как ловить правильно окуня или карпа. Он создает некое событие на этой платформе с датой проведения семинара и размещает промо-ролик или просто описание своего семинара. Остальные пользователи голосуют интересно или не интересно, при сборе какого-то количества голосов, событие утверждается платформой или отклоняется из-за недостатка голосов в поддержку. Причем человек разместивший это событие имеет возможность установить сумму за посещение данного семинара. От владельца этой платформы требовалась полная организация этого мероприятия. Соответственно взяв небольшую комиссию с продажи билетов. Вот уже готовая монетизация.

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

Всего лишь CMS

Дальше встал вопрос на какой технологии это всё делать. Я недолго думая, начал смотреть существующие CMS и прочие платформы для быстрой сборки такого рода проекта. Решение было такое, что я возьму какой-то движок для работы с данными и просто буду делать веб-морду доставая эти данные по REST. Я не собирался закопаться в полноценную разработку. В итоге всё же пришлось.

Мой взгляд на разработку ПО

Для каждой задачи, свой инструмент. Я всегда стараюсь придерживаться этого правила в разработке ПО. Еще один из важных факторов это разделение логики на технологические области ответственности. Для меня важны четкие границы интеграции между разными технологиями. Другими словами мне нравится когда «фронтэнд» отделен от «бекэнда» например. То есть от слова «совсем». Или существуют выделенные структурно модули, интеграции, и все это работает независимо. Сейчас это называется микро-сервисы.

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

Все! Решаю сделать космолет

Исходя из опыта я думал что нужен такой инструмент который поможет из готовых блоков формировать дизайн страниц и связывать его с данными и сервисами этой платформы прямо из браузера. Основной критерий был это никакого узко-специализированного программирования под каждую задачу. Всё должно быть абстрактно и как конструктор.

Потратив 2 недели на поиск чего-то подобного и испытав при этом две бесплатных CMS — Drupal и WordPress (я попытался использовать их в качестве движка управления данными и интеграцией по REST API). Но ни одна из них не удовлетворила мои требования. Поэтому мною было решено написать свою CMS с «блекджеком и шлюхами».

Технологии

Следующий вопрос который предстояло решить это выбор стека технологий для реализации. Особо долго не раздумывая, я конечно же предпочел сделать все на Java. Нужно было только решить какие фреймворки взять. Критерий в выборе фреймворков был таким — не брать лишнего и использовать только нужные части инструмента (в дальнейшем немного пожалел о выборе). Для построения интерфейса администраторской панели, мною был выбран один малоизвестный AJAX-фреймворк из Тайваня — ZK Framework. Мне в нем нравится подход MVVM, и его AJAX-составляющая (сейчас я уже считаю это минусом). Так как не нужно писать тонны JS чтобы следить за актуальностью состояния интерфейса пользователя на странице (на данный момент я нашел лучшую альтернативу).

Что же за стек технологий я по итогу получил:

Ну что, вперед!

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

Один в поле не воин, или.

Дальше мне хотелось всё же создать команду. Я начал регистрацию своего продукта в качестве стартапа в одном из бизнес-акселераторов. Но так и не закончив свою заявку, остановившись на этапе «Ваша команда».

Я много и часто рассказывал своим друзьям кто работал в близкой к сфере IT (информационных технологий) или в сфере IT.

В конце концов мне удалось найти ~~такого же сумасшедшего~~ потенциального клиента на мой продукт. Он также как и я, решил делать свой продукт, но он не программист. И ему нужна была платформа для его продукта. Я решил, вот оно! Мне даже не пришлось предлагать самому использовать мою CMS, мне было предложено на ней сделать сайт. Бесплатно конечно. Это был мой шанс испытать на реальной разработке мою CMS. И знаете что, я был приятно удивлен, но моя CMS справилась с этой задачей на все 100%. Да, конечно я много чего в процессе сборки дорабатывал, улучшал, и просто «фиксил» баги. Но в итоге я смог гибко натягивать любые дизайны и шаблоны на страницы, подключать и интегрировать данные и сервисы из сторонних источников.

И швец, и жнец, и на дуде игрец

С этого момента я понял что нужно развивать свои знания в области маркетинга, и читать книги о построении своего бизнеса. В процессе я участвовал с этим продуктом в хакатоне от MongoDB, получил частично реакцию аудитории на этот продукт. В соц. сетях откликнулись и даже поделились моим сообщением о том что я сделал CMS. По результатам хакатона, я конечно не получил ни единой награды, но я остался доволен тем что я участвовал.

Пока я ждал результаты хакатона я еще сделал две попытки «запитчить» мой продукт на мероприятиях по привлечению инвестиций. После чего уже увидел живую реакцию слушателей. Что принесло мне огромный опыт.

Результат

Что на данный момент я имею:

Некий MVP(Minimal Viable Product) покрывающий функционал:
- гибкой шаблонизации
- файлового хранилища
- модификации модели данных налету
- интеграцию с REST сервисами
- управление ролями и пользователями в MongoDB
Опыт презентации IT-продукта и реакцию зала.
Партнеров в работе над IT-продуктами, мотивированных решать задачи лишь за идею.
И большой «роадмап» дальнейшего развития продукта. На данный момент по стеку технологий я задумал колоссальную переработку, и почти полную смену этого стека технологий. Плюс расширения функционала.
Идеологию в реализации оставляю такую же.

Заключение

А теперь я вернусь с чего начинал. Смысл делать свой продукт есть всегда, даже если все вокруг говорят «да это уже есть, это всё сделали до тебя». Я называю таких людей английским словом Naysayer, однажды я услышал это слово от Арнольда Шварценеггера в одной из его мотивационных речей.

Несколько возможных путей развития продукта:

Отдать его в open source
Объединиться с похожими продуктами
Собрать сообщество таких же сумасшедших как я, кто создает свои продукты и пытается их продвинуть на рынок

Вот официальный демо-сайт CMS:

P.S.: Я хотел бы извиниться за частые использования «американизмов» в тексте. Сленг разработчика очень наполнен ими. Если бы я все перефразировал на русские синонимы, я бы потерял стиль повествования понятный и атмосферный для коллег по цеху.

Я надеюсь, мой рассказ вам понравился, и кому-то он будет полезен. Всем хорошего продуктивного дня!

Строим свою CMS на PHP и MySQL. Часть 1

Задача построения системы управления содержанием (CMS) может привести в замешательство новичка разработчика PHP. Но не так страшен черт, как его малюют! В данной серии уроков мы построим простую, но полностью работоспособную систему с нуля.

В ходе процесса вы научитесь создавать базы и таблицы MySQL, работать с объектами, константами, включениями, сессиями и прочими инструментами PHP. Кроме того мы покажем, как отделять логику приложения от презентации и сделать код PHP более безопасным. А также вам откроется многое другое, полезное в деле создания собственной системы мечты.

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

Примечание: для изучения материалов уроков потребуется веб сервер Apache с установленным модулем PHP и сервер MySQL. Для работы на локальном компьютере можно воспользоваться одним из инструментов веб разработчика: XAMPP (на английском языке), Denwer, Open server или другим.

demo sourse

Функционал нашей CMS

Первым делом надо точно определиться, что будет делать наша CMS. Итак, вот список функций:

Главная страница, на которой выводиться список последних 5 статей
Страница со списком всех статей
Страница просмотра отдельной статьи

Вход/выход для администратора
Список всех статей
Добавление новой статьи
Редактирование существующей статьи
Удаление существующей статьи

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

Планирование работ

Для создания нашей CMS нужно сделать следующие шаги

Создать базу данных
Создать таблицу articles
Сделать файл конфигурации
Построить класс Article
Написать скрипт клиентской части index.php
Написать скрипт серверной части admin.php
Создать шаблон клиентской части
Создать шаблон серверной части
Создать таблицу стилей и логотип системы

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

Шаг 1. Создаем базу данных

На первом шаге нужно создать базу данных MySQL для хранения содержания. Можно сделать так:

Запускаем программу клиент mysql Открываем окно терминала и набираем команду mysql -u username -p После запроса введите пароль для доступа к MySQL. username — имя пользователя, который имеет полномочия для создания баз данных. В случае работы на локальном компьютере можно использовать root , хотя для безопасности всегда следует создавать пользователя с другим именем для решения задач администрирования.
Создаем базу данных После метки mysql> вводим: create database cms; И нажимаем Enter.
Выходим из программы клиента mysql После метки mysql> вводим: exit И нажимаем Enter.

Теперь у нас есть пустая база данных, в которой можно размещать таблицы и содержание.

Для решения такой задачи также можно воспользоваться инструментами для администрирования баз данных, таким как phpMyAdmin, cPanel или Plesk (если они установлены на вашем сервере). В некоторых случаях использование подобных инструментов является единственным доступным для пользователя инструментом для работы с базами данных (ситуация зависит от правил, установленных на вашем хостинге).

Шаг 2. Создаем таблицу articles

Наша простая CMS имеет единственную таблицу в базе данных: articles . В ней содержатся все статьи в нашей системе.

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

Создаем текстовой файл tables.sql на жестком диске и добавляем в него следующий код:

DROP TABLE IF EXISTS articles; CREATE TABLE articles ( id smallint unsigned NOT NULL auto_increment, publicationDate date NOT NULL, # Когда статья опубликована title varchar(255) NOT NULL, # Полный заголовок статьи summary text NOT NULL, # Резюме статьи content mediumtext NOT NULL, # HTML содержание статьи PRIMARY KEY (id) );

Выше приведенный код определяет схему таблицы articles . Он написан на SQL, языке для создания и манипулирования базами данных в MySQL (и во многих других системах).

Разберем выше приведенный код

Создаем таблицу articles Выражение DROP TABLE IF EXISTS articles удаляет любую существующую таблицу articles (вместе с данным — осторожно!). Мы выполняем данную операцию чтобы в базе не было двух таблиц с одинаковыми именами. Выражение CREATE TABLE articles ( ) создает новую таблицу articles . Код, размещенный в скобках, определяет структуру данных в таблице.
Определяем для каждой статьи уникальный ID Теперь можно определять структуру таблицы. Таблица состоит из набора полей (также их называют столбцами). Каждое поле содержит опредленный тип информации о статье. Сначала мы создаем поле id . Оно имеет тип smallint unsigned (без знаковое маленькое целое), то есть число от 0 до 65,535. Таким образом, наша CMS может содержать до 65,535 статей. Также для него определяется атрибут NOT NULL , который означает, что поле не может быть пустым (null). Данное свойство существенно облегчает труд разработчика. Добавляем атрибут auto_increment , который указывает MySQL назначать новое, уникальное значение для поля id при создании записи. Итак, первая статья будет иметь id 1, вторая — id 2, и так далее. Мы будем использовать уникальные значения как указатели на статью при выводе и редактировании в CMS.
Добавляем поле publicationDate Следующая строка создает поле publicationDate , которое хранит дату публикации каждой статьи. Данное поле имеет тип date , соответствующий значениям дат.
Добавляем поле title Теперь создаем поле title , в котором размещается заголовок. Оно имеет тип varchar(255) , то есть может хранить строку длиной до 255 символов.
Добавляем поля summary и content Последние два поля 2, summary и content , содержат резюме статьи (краткое описание материала) и HTML содержание соответственно. Резюме имеет тип text (то есть, может состоять из 65,535). А поле content имеет тип mediumtext (то есть может содержать до 16,777,215).
Добавляем основной ключ Последняя строка в выражении CREATE TABLE определяет ключ для таблицы. Ключ также называют индексом, и он служит для быстрого поиска данных в таблице за счет некоторого увеличения требующегося пространства для хранения. Мы определяем поле id как PRIMARY KEY . Каждая таблица может содержать единственный PRIMARY KEY , так как данный ключ уникально определяет каждую запись в таблице. Кроме того, с помощью данного ключа MySQL очень быстро находит нужную запись.

Теперь у нас есть схема таблицы и ее нужно загрузить в MySQL для создания структуры. Самый простой способ — открыть окно терминала, перейти к папке с файлом tables.sql и запустить следующую команду:

mysql -u username -p cms < tables.sql

. где username — имя пользователя MySQL, а cms — имя базы данных, которую мы создали на шаге 1.

Вводите пароль пользователя после запроса, и MySQL загрузит и выполнит код из файла tables.sql , создав таблицу articles в базе данных cms .

Также можно воспользоваться инструментами для администрирования баз данных, таким как phpMyAdmin, cPanel или Plesk (если они установлены на вашем сервере).

Шаг 3. Создаем файл конфигурации

Теперь у нас есть база данных и мы готовы разрабатывать код PHP. Начнем с создания файла конфигурации для хранения различных установок для нашей CMS. Данный файл будет использоваться остальными скриптами нашей системы.

Первым делом создаем папку cms в папке веб сервера. Она будет содержать все файлы нашей CMS.

В папке cms создаем файл config.php и копируем в него следующий код:

getMessage() ); > set_exception_handler( 'handleException' ); ?>

Разберем код подробно:

Выводим ошибки в браузере Строка ini_set() устанавливает режим вывода сообщений об ошибках в браузере. Отличная опция для отладки кода, но на готовом проекте данную опцию надо отключить ( установить значение false ) для безопасности ресурса.
Устанавливаем временную зону Так как наша CMS будет использовать функцию PHP date() , нужно указать временную зону сервера для PHP (иначе PHP будет генерировать предупреждение). В примере установлена зона «Australia/Sydney» — поменяйте на свою.
Устанавливаем детали доступа к базе данных Затем определяем константу DB_DSN , которая указывает PHP, где искать базу данных MySQL. Параметр dbname должен соответствовать имени базы данных нашей CMS ( cms ). Также мы будем хранить имя пользователя MySQL и пароль, которые используются для доступа к базе данных CMS в константах DB_USERNAME и DB_PASSWORD . Установите правильные значения в данных константах, которые соответствуют вашим настройкам.
Устанавливаем пути Мы устанавливаем 2 пути в нашем файле конфигураций: CLASS_PATH , который указывает на место хранения файлов классов, и TEMPLATE_PATH , который указывает на место хранения шаблонов HTML. Оба пути указываются относительно верхнего каталога cms .
Устанавливаем количество статей, выводимых на главной странице HOMEPAGE_NUM_ARTICLES управляет максимальным количеством заголовков статей, которые выводятся на главной странице. Мы установили 5, но можно легко увеличить или уменьшить значение.
Устанавливаем имя и пароль администратора Константы ADMIN_USERNAME и ADMIN_PASSWORD содержат данные регистрации для администратора нашей CMS.
Включаем класс Article Так как файл класса Article (мы его создадим позже) требуется во всех скриптах нашего приложения, добавим его здесь.
Создаем обработчик исключительных ситуаций В завершение определяем handleException() — простую функцию для обработки исключений PHP, которые могут генерироваться при выполнении кода. Данная функция выводит общее сообщение об ошибке и записывает данные об ошибке в журнал веб сервера. Такая функция способствует улучшению безопасности системы за счет обработки исключений PDO, которые могут выводить имя пользователя и пароль на странице. После определения функции handleException() , мы устанавливаем ее как обработчик исключений PHP, вызывая функцию set_exception_handler() . Такой обработчик исключений сделан для упрощения материалов урока. «Правильный» способ для обработки исключений для перехвата всех вызовов PDO в Article.php заключается в использовании блоков try . catch .

Замечание о безопасности

В реальных проектах лучше помещать config.php где-нибудь за пределами корневого каталога веб сайта, так как в файле содержатся имена и пароли. Обычно код PHP невозможно просмотреть в браузере, но иногда из-за неправильной конфигурации веб сервера код становится доступным. Вы можете использовать функцию hash() для хэширования паролей и хранить в config.php хэши, вместо текстовых паролей. Затем при регистрации пользователя можно опять воспользоваться функцией hash() для кодирования введенного пароля и сравнения результата с сохраненным в config.php хэшем.

В следующем уроке мы построим основной класс нашего приложения — Article.

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: www.elated.com/articles/cms-in-an-afternoon-php-mysql/
Перевел: Сергей Фастунов
Урок создан: 22 Ноября 2012
Просмотров: 292690
Правила перепечатки

5 последних уроков рубрики «PHP»

Фильтрация данных с помощью zend-filter

Когда речь идёт о безопасности веб-сайта, то фраза «фильтруйте всё, экранируйте всё» всегда будет актуальна. Сегодня поговорим о фильтрации данных.

Контекстное экранирование с помощью zend-escaper

Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

Подключение Zend модулей к Expressive

Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

Совет: отправка информации в Google Analytics через API

Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.

Подборка PHP песочниц

Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.

1.1. Создание своей CMS. Вступление.

В этой части нашего курса мы будем заниматься созданием свой CMS для интернет-магазина. Но прежде чем начать Вам следует прочитать вступление, чтобы понять нужно ли Вам писать свою CMS или взять к примеру Друпал с удобным Commerce (и кучей готовых модулей). Во вступление мы разберем:

Логику работы интернет-магазина
Когда мы должны разрабатывать свою CMS вместо того, чтобы использовать существующие
Выгоды от своей CMS
Описания других готовых CMS интернет-магазинов

Интернет-магазин: зачем он нужен?

Думаю все уже сталкивались с покупками в Интернете. В Интернете полно всяких сайтов продающих любые вещи:

Магазины, такие как Amazon, Ozon,
Аукционы, такие как eBay
Сайты купонов, такие как Biglion, Groupon
Сайты с годовой подпиской

Интернет магазин очень популярный способ продвинуть свой бизнес на новый уровень.

eBay

Например сайт eBay посещают примерно 84 миллиона активных пользователей и продают товаров на 1900 долларов в секунду. Это значит что 84 миллиона покупают и продают не выходя из дома. eBay это не стандартный сайт аукцион, здесь очень много функций соц. сети: профили пользователей, личные сообщения, рейтинг, популярность, отдельные магазины пользователей.

Amazon

Годовой доход Amazon за 2013 год составил 74 млрд. долларов. Amazon самый популярный интернет-магазин в мире.

BaseCamp

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

Почему используют электронную коммерцию?

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

Зачем использовать PHP?

PHP очень популярный язык программирования, именно его мы будем использовать для каркаса нашей CMS. Многие предпочитают более молодые языке, такие как Ruby и фреймворк на нем Ruby on Rails. Но мы будем использовать проверенную связыку PHP и MySQL. Возможно программирование на PHP не самое быстрое и требует больше ресурсов сервера, чем в других языках. Но PHP довольно простой и для него много готовых решений, библиотек, подходов.

Когда использовать готовые решения?

Уже существует огромное количество наработок по электронной коммерции и Вам следует их использовать, например когда:

Горят сроки по сдачи проекта
На проекте несколько разработчиков и каждый стремится сделать что-нибудь свое. В этом случае использование одной CMS со своими правилами написания кода унифицирует процесс разработки
Клиент имеет предпочтения к какой-либо CMS
Если готовое решение идеально подходит для решения проблемы.

Готовые интернет магазины

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