October 18, 2014 at 03:00

KodiCMS Architecture

    Introduction


    Hello everyone, in this article I will try to briefly talk about the components that make up the CMS architecture, there are many of them (I think they will not fit in the article), controllers, modules, plug-ins and the organization of connecting css, js files.

    The core of KodiCMS is the Kohana framework version 3.3.2 . The core of the system is the “kodicms” module, which contains the basic logic of work and is expanded using Observers through modules and plugins.

    The list of modules that were developed for CMS:

    • API - Work with AJAX requests, supports request types GET, POST, PUT, DELETE . Answer in json or HTML format
    • Behavior - an extension of the behavior of Frontend pages
    • Dashboard - the desktop and everything related to it
    • Datasource - the basis for creating data partitions (using it the sections Hybrid Data , Categories , Document Rating are created ), which is disabled
    • elFinder - file manager, disable
    • Email, Email _Queue - sending mail, bulk mailing, Email sections in the Backend and tasks for the task manager, disabled
    • FileSystem - classes for working with FS
    • Installer - System installer
    • KodiCMS - System Core
    • Navigation - Backend Navigation
    • Page_Parts - Parts of pages (Associated with Pages module via Observer ), disabled
    • Pages - theoretically disconnected site page module
    • Plugins - plug-in module, organizes the extension of the system by plug-ins, disconnected
    • Reflinks - a temporary link generation helper, for example, Forgot password or Registration confirmation
    • Scheduler - Calendar for Backend, as well as Cron task manager, which is disabled
    • Search - search on the site, contains a full-text search driver, the list can be supplemented with its own drivers
    • Sidebar , disableable
    • Snippet - a module for organizing pieces of code that can be inserted into a template, is also used by the “Widget” module for widget templates, which is disabled
    • Tags - organization of tags in the page module and Hybrid data, disabled
    • Update - a system update module that is disabled
    • Users - system users, ACL
    • Widget - Widgets, blocks placed on the site’s pages, display any information that is disabled


    * disconnected - disconnection in application / init.php is possible .

    In addition to the modules I developed, the system has standard modules and third-party developments

    • Assets - for organizing CSS, JavaScript
    • Breadcrumbs - breadcrumbs generation, used by the breadcrumbs widget
    • Captcha
    • Minion - used by the task manager to run scheduled tasks ( tasks )
    • Pagination


    KodiCMS module


    The main CMS module, it is in it that the standard Kohana functionality is expanded, basic controllers for working with Backend , configs, helpers, etc. are contained .

    Settings


    There are several types of settings storage in the system:
    • File configs
    • A table in the database to override file configs (Cached)
    • A separate table for storing plugin information (Cached)
    • Storing user information User_Meta (for example, the set and arrangement of widgets on the desktop), as in Wordpress and Bitrix, SugarCRM, etc. (Cached)


    Each module, as well as the system plug-in, can redefine or add new parameters to the config file, therefore, it was decided to use them to store data that could be supplemented by a third-party developer in its module or plug-in, therefore, data for:


    Those. when creating a plugin, if you need to add a menu item (sitemap.php), a new section in the backend (datasources.php), expand access rights to new controllers (permissions.php) or add a new task to the scheduler (jobs.php), it is created in it config file.

    Controllers


    The system controller has several levels of abstraction:

    1. Empty System_Controller
    2. Security access control controller System_Security <System_Controller
    3. Template controller responsible for System_Template <System_Security page templates
    4. Backend controller System_Backend <System_Template, from which all controllers are inherited for access to which authorization is required. In this controller, all the necessary css, javascript, etc. are connected.
    5. Frontend controller System_Frontend <System_Template, from which all controllers are inherited for access to which authorization is not needed. (Login, Remember password, Error page)
    6. Media controller for searching media files (css, js, etc.) in all modules and plugins in the media folder , i.e. if in the plugin you create the media / css folder and put the css file (test.css) in it, then you can access it as cms / media / css / test.css
    7. The API controller System_API <System_Ajax is mainly used for ajax (GET, POST, PUT, DELETE) requests, and actions in the controller are also of several types get_ ..., post_ ..., put_ ..., delete_ ..., depending on what type the request arrives.
    8. Front controller for Frontend pages.


    Once upon a time I talked about such a structure at the office. kohana forum , maybe this post will seem useful to someone.

    Frontend controller


    The route for this controller is the last in the list. When the controller is called, the page is searched by URL ( requests are cached ), then the page type is checked, access to the page is checked, widgets, parts of the page and other extensions are connected through the observers, for the administrator, the profiler is connected to the HTML template (+ for the future, the ability to create a toolbar via View, as in fashionable CMS such as Bitrix, Wordpress, etc.), browser-side caching and page type (in the slug field in the page settings you can specify the extension, for example, rss.xml and the output will be with the corresponding Content-Type) .

    I drew a diagram of the path that the request passes when the frontend controller is called, the scheme is a bit confusing and the main thing is not to get confused in the arrows and find Request.



    Organization of media (css, js, less, image) files


    The main media files of the system are located in the cms / media folder.
    The main styles file css / common.css is compiled from LESS files and third-party libraries, including Twitter Bootstrap , Font-Awesome , etc., recompilation occurs when the Less plugin is enabled and changes are made to the less / common.less file , it is also the main one.

    The main JavaScript file is js / backend.js (it will probably be described in a future article).

    To connect css and js in the templates, the Assets module is used , which was slightly modified, namely, the Assets_Package package manager was written, which will allow you to group media files into packages . It can also be used in frontend for quick connection of libraries, as well as in widgets.

    // Пример использования пакетов во Frontend шаблоне
Meta::factory($page)->package(array('jquery', 'bootstrap', 'holder', 'fontawesome', 'demo-assets'));


    Each module and plug-in in the system can also have a media folder with a similar structure and be connected in the controller as cms / media / .... without specifying the module name, files are searched through Kohana :: find_file and therefore file paths are cached.

    Also, when requesting the backend controller, it searches for the javascript file cms / media / js / controller / controller_name.js for it

    Modules and Plugins


    In addition to the standard features of the modules (including plugins), installation support was added to them.

    At the moment the installer is launched, the install / observers.php file is searched and called in each module ; at the time of the system installation, the installer goes through all the modules and looks for the presence of install / schema.sql files , and then install / dump.sql and then install / install.php

    Since plugins have the ability to activate and deactivate , install.php , uninstall.php , install / drop.sql are also added for them , as well as frontend.php and backend.php fileswhich work similarly to init.php , but connect to Frontend / Backend.
    The rest of the work of the plugins is no different from the standard Kohana modules.

    PS
    In a previous article, I forgot to mention that there is a plugin repository for KodiCMS: github.com/KodiCMS , you can also see it in the backend .

    In the next article, I would like to talk about the design of one of the modules or several modules, or show an example of the implementation of a simple site or describe the capabilities of the Hybrid Data section .

    In general, if you are interested in learning something, write, I will try to tell you.
    Tags:

    Also popular now: