What is a content management system (CMS)?
A content management system (CMS) helps companies manage digital content. Whole teams can use these systems to create, edit, organize, and publish content. It acts as a single place to store content and provides automated processes for collaborative digital content management and creation using built-in (or designed) workflows. Different privileges and responsibilities are provided to individuals based on roles. For example, authors can post and save their work, but editors can modify and publish it. Administrators can do all these things as well as grant other people in the organization permission to update or revise content.
A CMS helps create and manage websites and website content using minimal technical overhead, so you can make better content instead of acting as a project or traffic manager. By providing an easy and cost-effective solution for content management, a CMS allows companies to manage and distribute their content without investing in a full-time content development team.
Types of content management systems (CMS)
Nearly every CMS is comprised of two parts—the front end and the back end. The front end is the part the user interacts with. It’s how websites are visibly structured and styled. The front end brings HTML, CSS, and JavaScript together to deliver rich, interactive content that’s styled to match your company’s branding.
The back end of a CMS is the application that is used to post new content to a website. The process begins by accessing a web interface to easily add, create, and publish content to your CMS’s front end. Rather than knowing HTML, CSS, and JavaScript, you create content in an interface similar to Microsoft Word. The back end then stores this content in the database and publishes it to the front end of the website.
Together, these two systems comprise the CMS. They allow you to publish content without understanding web technologies or building your web application from the ground up.
The following are some of the different types of content management systems that are available today.
Coupled CMS
A coupled CMS is often referred to as a traditional CMS. It offers a fully accessible back end that connects to and modifies a website’s database and publishes content to a styled front end.
While a coupled CMS is an all-in-one solution, the main distinction between it and a software-as-a-service (SaaS) CMS is that a coupled CMS requires dedicated web hosting to run. Although web hosting is relatively inexpensive, it’s important to remember that a CMS requires installing and maintaining specific technologies to make the software functional.
Additionally, a coupled CMS will likely require that an administrator set it up and configure the system installation for ongoing use. WordPress is an example of a coupled CMS, as it offers a complete package for users to install, launch a website, and publish content moving forward.
SaaS CMS
A SaaS CMS is also a complete, end-to-end solution, but unlike coupled CMS, SaaS CMS is hosted in the cloud. Which means that it requires no actual setup, installation, or preconfigured web hosting.
A SaaS-based CMS is an excellent solution for companies who need a straightforward web presence, as it offers all the capabilities without any of the server or web-hosting overhead. It enables all kinds of users to quickly create websites, manage the content, and distribute it through digital channels.
Decoupled CMS
In a decoupled CMS, the presentation part of the website is “decoupled” from the back end. The delivery system sits between the presentation of the website and accesses the back end through an application programming interface (API).
A decoupled CMS is an advanced solution that offers greater flexibility to interact with the content created in the back end. For example, suppose an organization wants to use its library of content for a new purpose, such as mobile applications. In that case, a decoupled CMS is an appealing solution because it supports multiple, adaptable applications on the front end while keeping your content and information consistent in the back end.
Headless CMS
A headless CMS has only a back-end system that accesses a database and stores content with a custom-built, front-end web application. It offers greater flexibility than a decoupled CMS, but it also requires considerably more work than any other option. A headless CMS also usually requires a developer to design, create, and connect a front-end application.
A headless CMS is a good solution for organizations that need complete control and flexibility over how their content is accessed. It provides content storage and organizational capabilities while allowing for a custom application on the front end—whether a website, a mobile app, or some other front end.
Core features to a content management system
Finding out what features of a CMS are critical to your business might start with what features are core to a content management system. Leveraging side-by-side comparisons of content management solutions and products can be helpful to your decision-making process. Still, the core question is, what features are core to any solution?
User roles and role-based content management
There are different types of roles within any Content Management System. Understanding how they work together is essential to giving your users access to perform their duties and access appropriate digital content. These range from typical organization roles to application management roles, task and feature comparison by application roles, to the resource (permissions) type roles, deciding what users can see and do with the content, including documents, sites, or templates.
Digital asset management
Content Management systems like Oracle’s offer powerful capabilities to manage all your digital assets for use in different marketing channels, including websites, marketing materials, email campaigns, online stores, paid search, and blogs. It provides a centralized content hub for all your assets, where you can organize them into repositories and collections and create rules and workflow to define how the content can be used and where.
Creating asset types to define what information you need to collect when users create assets is critical to any CMS. Digital asset types will define the custom attributes required for your digital assets (files, images, and videos).
Manage content in the cloud
As with ours, it is critical to move your content management to the cloud, centralizing your content all in one place and making it accessible anywhere.
You can group your files in folders to perform everyday file management operations, including copy, move, delete, in much the same way as on your local system and architecture. Since all the content files reside in the cloud, users will access them wherever they go, including mobile devices.
Content collaboration
With all your organizations’ content in the cloud, it will be easy to share assets or folders to collaborate with others both inside and outside your organization. Everyone you share content with will have access to the latest information—wherever they are, whenever they need it. Sharing and recording content coloration will enable the user to monitor how and when each shared item was accessed.
Build websites
With content management solutions, you can rapidly build and publish marketing, help, and community websites—from concept to launch—with engaging online experiences. The website building process is completely integrated across content, collaboration, and design are via a single authoring and publishing environment.
Cloud-based solutions make it easy to get started quickly by using out-of-the-box templates, drag-and-drop components (WYSIWYG), sample page layouts, and site themes to assemble a website from predefined building blocks. Or your developers can create custom designs, including templates, themes, or components to create unique online experiences.
What to consider before evaluating if a CMS is right for your business
A CMS makes content more findable by addressing six key areas in content management.
Content governance
Are there enforced policies and procedures in place for creating and managing content?
Information architecture for tagging
Is current and new content categorized and tagged in a way that everyone understands?
Business process for content management
Are workflows standardized and automated?
User experience for content
How are key stakeholders—from employees to customers—finding the information they need?
Technology and applications
Is the existing technology being used properly? What improvements or new systems would streamline information flow with optimal security? Do you have a cloud-based content management system?
Business value of a CMS
Can your data and content be managed more efficiently and securely? Are applicable regulatory guidelines being adhered to?
Using a content management system for your website
A content management system helps you create, manage, and publish content on the web. It also helps keep content organized and accessible so it can be used and repurposed effectively. There are various kinds of content management systems available—from cloud-based to a headless CMS—to meet every audience need.
Not only does it give you a way to store and manage all your information in a single, easily accessible database, but it also does the following:
- Supports inner- and cross-team collaboration
- Provides an easy and accessible way to update content
- Increases content visibility
- Improves productivity
- Reduces costs
- Enables you to maintain content consistency
- Scales as your needs grow
How does a CMS help to build websites?
Basically, a CMS platform takes care of all the technical details around building and managing a website. For example, to post content on the web, such as a blog post, you need to start with an HTML file. HTML allows you to structure your written content so that a web browser can read it. It also allows you to embed images and videos into your content and link to other HTML documents.
Once the content is created and structured, you can change the look and feel of it by using cascading style sheets (CSS). With CSS, you can change the font, color, and size of every element on your page to achieve the desired styling. Once completed, you upload the HTML and CSS files—along with any image and video files—to a web server where your new website is accessible to anyone.
While this process may not seem terribly difficult, it’s not a very efficient way to create documents and share them online. And most organizations don’t have the IT resources to devote to this task.
Advanced CMS technologies
HTML and CSS are OK for creating simple, readable documents, but they are limited when building websites that offer extensive capabilities and functionality—the kind of modern website most companies need to be successful.
For example, to add interactive features and more nuanced functionality to your website, you need to use JavaScript—the programming language of the web. HTML and CSS are relatively straightforward codebases used to create simple documents. JavaScript is a dedicated programming language not dissimilar from the languages used to develop smartphone or desktop applications.
Suppose you plan to migrate your blog site into a media website that serves thousands of visitors per month and posts several pieces of content per day. In that case, you need to start incorporating database technologies to house and access all your content. You need a database with its own programming language as well as another programming language to pass information between the database and the part of the website that users access and navigate. Just like that, things got complicated rather quickly. And that’s where a CMS comes in.
Content management system (CMS) benefits
The demand for digital marketing experiences is growing, and shows no signs of letting up. Today’s modern consumers are demanding omnichannel solutions and frictionless experiences. Digital technology provides endless ways for companies to engage with their customers and stay connected. So it’s no wonder that CMS market is expected to grow from $36 billion in 2018 to $123.5 billion by 2026.
Companies recognize how a content management system can help them leverage the full value of their content by streamlining the content creation and distribution process. Marketing and sales teams who invest in a CMS can expect to gain four key benefits as they work to get their message into the market and improve customer experiences.
Stronger collaboration and organization
With a CMS, multiple content marketing team members can contribute and help publish content. With its workflow management, content storage, and scheduling capabilities, the system helps them keep everything organized. Browser-based CMSs can be accessed from anywhere, and teammates in different locations can collaborate on content projects in the same system and on the most current version. Team members can all access the same content since it’s stored in the same place. There’s no need to send multiple files to multiple people—and no headaches from trying to control multiple versions.
User friendly
With a CMS, users don’t have to learn HTML or CSS. No matter their skill level, users across the organization can create and publish content. A content management system makes it easy to upload content onto web pages and update it through a content editor.
SEO and content optimization tools and plug-ins
Want to improve your search engine optimization (SEO) and drive traffic to your site? With a CMS, you can add plug-ins and tools to increase your search ranking. These tools can include options within the front-end interface to add web page titles, meta descriptions, and alt tags.
More time to spend on content
With a straightforward CMS system, better organization, and tools and plug-ins to help SEO, Content creators can concentrate on producing quality content. Marketing teams don’t have to work with multiple files or code. They can share their work with colleagues easily, even if those colleagues are miles away. They have time to refine copy, tweak imagery, produce more video content, or conduct A/B testing on different subject lines, offers, CTAs, and formats.
Learn more about content management solutions for CX
Why Oracle for content management
Oracle Content Management manages digital assets and structured content to build digital experiences on any channel or touchpoint. With a centralized asset repository at its core, content as a service (CaaS) APIs, and a react site builder, and a drag-and-drop WYSIWYG site editor, you can quickly create the right experiences for any target audience.
Get more information about content management systems
- Content management systems for information/record management
- Content management systems used as headless CMS
- Content management systems to help improve CX
- Oracle Content Management blog
- Oracle marketing blog: content management for CX
Как я написал свою 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?
Всегда, когда надо было сделать сайт, я брал какой-нибудь готовый движок и делал на нем сайт. Переписывал, писал различные модули или плагины.
Сейчас захотел написать свою CMS, скорее для опыта. Но понял, что даже не представляю с чего начать)
- Вопрос задан более трёх лет назад
- 5840 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 12
Ivan Goncharov @SilentBrain
Web-Programmer
Напишите лучше фреймворк. Даст больше опыта, чем CMS. CMS по сути монотонное создание формочек добавления/редактирования/удаления контента.
А в фреймворке будут более интересные задачи, попробуйте реализовать свою ORM, продумайте роуты, контроллеры, хелперы, попробуйте реализовать интерпретатор для языка Slim (slim-lang.com) или HAML и т.д.
Вот это будет действительно полезный опыт, которым можно будет даже поделиться потом с другими.
Ответ написан более трёх лет назад
Комментировать
Нравится 5 Комментировать
Если для опыта, то вам стоит двигаться примерно следующим образом:
1) Крепко-крепко подумать, а надо ли оно вам (потому как, если вдруг начнет получаться — процесс сам по себе затягивает и отвлекает от зарабатывания денег, личной жизни, да и жизни вообще)
2) Прикинуть, что вам не нравится в тех готовых движках, на которых вы делали сайты
3) Составить краткий список того, что должна уметь делать ваша CMS (в глаголах, желательно)
4) Поизучать фреймворки (на разных языках) и выбрать лучший, или, убедившись, что их авторы козлы полнейшие возможности, предоставляемые фреймворками избыточны, либо не достаточны — перейти к следующему пункту
5) Исходя из списка из пункта 3, выбрать хранилище данных. Критерий выбора — как ни удивительно — не его распространенность, но, скорее — возможность выборки требуемых данных минимальным количеством простых запросов.
6) Исходя из выбора хранилища данных, выбрать фреймворк/язык программирования
7) Подобрать хостинг, на котором есть все, что вам нужно
8) Пробежаться по списку из пункта 3 и быстро-быстро все написать. При необходимости — конкретизировать и расширить этот список. При необходимости — вернуться к пункту 4.
Как-то примерно так.
Ответ написан более трёх лет назад
Комментировать
Нравится 4 Комментировать
Начните с подборки фреймворка. Лично я использую Zend Framework (т.е. php).
Ответ написан более трёх лет назад
Нравится 1 1 комментарий
И к стати, на написание своей CMS уйдет ох как много времени, пока реализуете весь тот функционал, который уже есть в тех CMS, которые Вы использували раньше. Но у Вас появится опыт и вырастите как программист.
С index.php 🙂
А без шуток — с того, что соберёт вместе все остальное и заставит это работать так, как мне нужно. С ядра, если хотите.
Ответ написан более трёх лет назад
Нравится 1 2 комментария
Наверное имеете в виду паттерн фронт контроллер, и единую точку входа?
Возможно, я совсем не разбираюсь в терминологии. Просто озвучил то, как это делал пару лет тому назад.
Действительно, была точка входа и скрипт, через который подключались модули в нужные места шаблона.

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

Готовый продукт — готовый ответ. Смотря на готовое решение понять, почему они имеет именно такой вид новичку обычно нереально. А вот когда он на своем опыты набивает шишки, находит то или иное решение, то на готовый продукт он смотрит уже по другому.
Поэтому для обучения с целью зачем и почему сделали именно так совет разбираться в готовом проекте — плохой. Если с целью просто сделать что-то более менее адекватное посмотрев как делать правильно — хороший.
Full-stack developer (Symfony, Angular)
Ну по сути…
> composer.phar install
> app/console generate:bundle
и т.д.
То бишь за основу берется какой-то мощный фреймворк, позволяющий создать гибкую структуру компонентов. Мне вот нравится Symfony в плане гибкости. Модно написать какой-то бандл и без проблем использовать его в других проектов тратя минимум времени на доработки. За счет возможности написания агрегаторов, можно реализовать админку и возможность для каждого модуля написать часть оной и собрать все под одной крышей. Вы можете взять за основу другой фреймворк, и начать делать на нем.
Делать полностью с нуля нету никакого смысла, кроме как самообразование.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
С рисования. Рисовать пути превращения типичных запросов сначала в данные, а потом данных в ответ, думая где в него может понадобиться внедриться (изменить, заменить, декорировать) по каким-то условиям и прикидывать как это внедрение и проверку условий осуществлять. Так получите схемы взаимодействия ядра и модулей.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Open Source enthusiast
С пустой папки, потом index.php, потом набросок дизайна, потом к элементам дизайна цепляю внутреннюю функциональность и добавляю новые файлы по подпапкам, потом дизайн отделяется в отдельные компоненты (темы, скины, называйте как хотите) которые подключаются ядром, и так всё чередуется, размножается, переписывается.
Только геморрой это ещё тот, вот уже почти 2 года пилю CMS/CMF, если бы сейчас предложили начать писать с нуля — отказался бы наверное от такой затеи, уж слишком долго и непросто сделать что-то стоящее.
Начинать стоит если у вас есть список того, чего вы не можете реализовать в других CMS концептуально, либо это слишком сложно. В противном случае это потеря ОЧЕНЬ большого количества времени без особой пользы.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Вобщем теоретические проекты в вакууме не кому не нужны. Выберете реальную задачу интересную вам. Например это может быть например блог, интернет магазин или даже сайт визитка. Весть функционал вместе в cms все равно не стоит сразу пихать. Начиние писать. Подумать конечно стоит, но особо долго не тратьте на планы. После написания первой версии станет понятно, что и как лучше сделать подругому, улучшить.
Фреймворк лучше чем CMS в плане гибгости, это да. Я лично исползую один из популярных фрейморков и к нему написанны ряд приложений. Получается такая недо-cms. Но зато эта штука более гибкая и подстраивается под реальные проекты.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
В первую очередь, с написания Тех. Задания (ТЗ). Необходимо четко знать, что должна CMS уметь и как должна выглядеть. И уже только после этого, исходя из ТЗ, подбираются необходимые инструменты (языки, платформы, и т.д.). Необходимо четко знать цель куда двигаться, иначе можно вообще никуда не придти.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
С архитектуры, наверное.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
С копирования файлов стандартной пустой структуры, причем последней версии, которая содержит набор
классов, функций, много js, пустой шаблон, кешкаталог и пару файлов найсройки и индекса.
Далее идет указание этого ^^^ ФТП бекап-скрипту и проверка создания пустого бекапа.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Ваш ответ на вопрос
Войдите, чтобы написать ответ

- PHP
- +1 ещё
Регулярка для замены эмодзи символов в стороке?
- 1 подписчик
- вчера
- 77 просмотров
Рождение одного проекта или как написать свою 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
- Веб-разработка
- Развитие стартапа
