Geekly Articles each Day
📜 ⬆️ ⬇️

KodiCMS architecture

Introduction


Hello everyone, in this article I will try to briefly tell about the components that make up the CMS architecture, there are a lot of them (I think they all don’t fit in the article), controllers, modules, plugins and css, js files connection.

The basis of KodiCMS is Kohana framework version 3.3.2 . The core of the system is the “kodicms” module, which contains the main logic of operation and is expanded with the help of observers (modules) through plug-ins and modules.

The list of modules that were developed for CMS:



* disableable - disabling is possible in application / init.php .
')
In addition to the modules developed by me, there are standard modules and third-party development in the system.



KodiCMS module


The main CMS module, namely, it expands the standard Kohana functional, contains basic controllers for working with Backend , configs, helpers, etc.

Settings


There are several types of settings storage in the system:


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


Those. when creating a plug-in, 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 creates config file.

Controllers


The system controller has several levels of abstraction:

  1. Empty System_Controller controller
  2. Security controller of access control System_Security <System_Controller
  3. Template controller responsible for the page templates System_Template <System_Security
  4. Backend System_Backend <System_Template controller, from which all controllers are inherited for access to which authorization is required. This controller connects all the necessary css, javascript, etc.
  5. Frontend System_Frontend <System_Template controller, from which all controllers are inherited for access to which authorization is not needed. (Authorization, Recall Password, Error Page)
  6. Media controller for searching media files (sss, 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 in it (test.css), then you can access it as cms / media / css / test.css
  7. The System_API <System_Ajax controller API is mainly used for ajax (GET, POST, PUT, DELETE) requests, and actions in the controller also come in several types of get_ ..., post_ ..., put_ ..., delete_ ..., depending on what type of request comes in.
  8. Front controller for frontend pages.


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

Frontend controller


The route for this controller is the last one on the list. When the controller is called, the page is searched by URL ( requests are cached ), then the page type is checked, the page is checked for access, widgets, parts of the page and other extensions are connected to the HTML template for the admin (for the admin, the ability to create a toolbar through View, as in fashionable CMS like Bitrix, Wordpress, etc.), caching on the browser side and specifying the 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 appropriate Content-Type) .

I drew a diagram of the path that passes the request when calling the frontend controller, the scheme is a bit confusing and the main thing is not to get lost 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 stylesheet file css / common.css is compiled from LESS files and third-party libraries, including Twitter Bootstrap , Font-Awesome, and others, recompiled when you turn on the Less plugin and make changes to the less / common.less file , which 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 templates, the Assets module is used, which was slightly modified, namely, the package manager Assets_Package was written , which will allow grouping media files into packages . It can also be used in the 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 can be connected to the controller as cms / media / .... without specifying the name of the module, files are searched through Kohana :: find_file and therefore the paths of finding files are cached.

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

Modules and Plugins


In addition to the standard features of the modules (and plug-ins including), support for the installation has been added to them.

At the moment of the installer launch, the installer searches and calls into each module of the install / observers.php file, at the moment the system is installed, the installer goes through all the modules and checks for the presence of the install / schema.sql files , and then install / dump.sql and after the launch of install / install.php

Since plugins have the ability to activate and deactivate , then install.php , uninstall.php , install / drop.sql , as well as in the frontend.php and backend.php files are added for them, which work in the same way as init.php , but are connected in Frontend / Backend.
Otherwise, the work of plug-ins is no different from standard Kohana modules.

PS
In the 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 tell about the device of one of the modules or several modules, either to show an example of the implementation of a simple site or describe the capabilities of the section " Hybrid Data ".

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

Source: https://habr.com/ru/post/240781/

More articles:


All Articles