Box advantage
Frankly, this post is a comment on Denis Boltikov ’s opus “ The advantages of a boxed CMS over a studio one ”. As a rule, I avoid such topics, since holivar is not an event for which I am ready to waste my time. However, the advantages listed by Denis plunged me into a state of shock and made me think that he just really needed to push the “box” at his new place of work .
Kopipastu benefits Denis listed:
Kopipastu benefits Denis listed:
- Best quality boxed CMS code. For the developer company, this CMS is the main product. Its development, optimization, testing has spent much more man-hours than any studio. The efficiency of the boxed CMS has been proven on hundreds and thousands of websites created. Easy site extensibility. Most of the required modules have already been created. We need an online store - we connect, configure, work. We need a forum or feedback section - we connect, configure, work. API for developers. If available, a competent programmer will easily increase the necessary functionality. Open documentation. There is user documentation, developer documentation, API documentation for creating your own modules. In most studio CMS this is not or there is, but, like top web studios for a separate, rather large fee. Technical support that is always ready to help solve your problem. A large community of developers. Find a specialist who will improve the site on the boxed CMS is much easier and faster than wanting to delve into someone else's, and, as already noted, undocumented engine. Write from scratch is really easier. It so happened that just a couple of weeks ago we ( Kudzev , Warlock and I did a bit) completed the study of two CMS for implementation for a specific project with specific needs. I will not explain why, for a long time, but as a result of the dropout, the two noisiest “boxes” - UMI and Bitrix - became experimental.
A brief report on the research contrasts to a considerable extent the arguments of Denis.Subject of study
For the study selected two CMS - UMI.CMS and 1C-Bitrix. Studies were conducted within two weeks. The sources of information were:- Source codes of systems. Documentation of systems. Technical support forums. Consultations of third-party developers who had experience working with systems. The subject of research was:
- System architecture. Principles of working with a database. Many sites. System of rights. Quality of writing code. Time to develop a module "Module". Support the best practices.
results
- CMS is built on modern technologies PHP5, MySQL5, XSLT. The system itself is light in terms of code size and degree of understanding. The architecture of the system is built on a modular principle. There is a set of classes that implement the kernel and external modules. The kernel provides quite rich tools for working with files and databases. Modules can use any functionality. Connecting modules is simple and affordable. The documentation on the kernel is good, there is an SDK in the development of the module. The work with the database is based on the use of intra-system objects. The database structure is hierarchical in the form of a tree. Direct access to the database is missing. The structure of the tables in the documentation is not described. Data is stored in tables as data types. Data types can be inherited and nested. Multi-site based on URL parsing. Multisite is implemented logically on the basis of a single entry point with preservation of the domain of circulation. The system of rights at the module level. The implementation of the right at the level of operations is not implemented. But hypothetically possible to implement. The quality of writing code is good. The code is written transparently, centrally. Comments are present only in difficult to understand places. The time to develop a module "Module" - 2 days. The module implements the conceived functionality by about 70%. Best practices: full support for OOP (as far as PHP5 allows), centralized error handling, template engine based on XSLT, ORM based on kernel classes, VO based on data types, implementation of FrontController with transfer of control to modules.
- A well-known system with a rich history. Uses standard technologies PHP4, MySQL4. The system is very redundant and cumbersome, difficult to understand. The architecture of the system is built on a modular principle. There is a kernel and a number of plug-ins. Connecting a module is a nontrivial task and is associated with a large number of files for configuration. The structure of the site is physical with the creation of folders and files with duplication in the database. The kernel documentation is good. Write your own module from scratch is impossible in principle. The kernel provides the means of accessing the database, but the means of working with files are represented in a rudimentary level. Working with the database can be through system interfaces, as well as directly. The structure of the tables is indicated partially. All data in the database have meta-information, which entails redundancy and system overload. There is a mechanism for storing data as information blocks. Information blocks can only be in the form of categories and elements. Both categories and elements cannot be nested or complex types. Multi-site is implemented at the level of the web server and physical file duplication. The rights system is good. It is possible to organize a distinction at the level of modules and elementary actions. The quality of writing code is low. The main reason for this is clearly the poor organization of the system. The code is scattered in different files and it is very difficult to assemble a complete picture. The time to develop the Module module is 2 days, the module is 50% of the designed functionality. Adjusting the administrator zone for your module is the most difficult task in developing the module. Best practices: partial poor OOP support, error handling only at 404 level, runtime errors are output to the user, there is no template (this is just awful), ORM is missing, pseudo VO through arrays , Front-ApplicationController is missing - there are a lot of entry points (the principle of the first PHP sites through include).
Conclusion
Neither CMS is suitable for implementing the conceived functionality. But if we consider it from the standpoint of the fact that it will be easier to remake, then this is UMI.CMS. This CMS is more modern, it uses most of the good practices and is quite easy to learn and adapt. From the point of view of a developer, Bitrix is an outdated, bulky, redundant system, which still exists only due to good marketing. Both systems were not originally, and now they are focused on refinement, and they can be called closed systems. Both systems do not implement one of the fundamental principles of building MVC web-applications (Model-Controller-View) - the essence is in the separation of business logic, event processing and presentation, and this entails an increase in development time and refinement at times. not that studio CMS is better. The point is that in order to draw conclusions about the benefits of a product, you need to operate with specific examples, and not with your own speculation and the commercial vein.
')
It was an honest study. Conclusions do only you.
Update
In the comments, for some reason, they decided that this is PR of UMI :( But it’s not about that. The point is that there is a project and a solution that needs to be sought for this project, and not a project to tighten up the possibilities of ready-made solutions.
- A well-known system with a rich history. Uses standard technologies PHP4, MySQL4. The system is very redundant and cumbersome, difficult to understand. The architecture of the system is built on a modular principle. There is a kernel and a number of plug-ins. Connecting a module is a nontrivial task and is associated with a large number of files for configuration. The structure of the site is physical with the creation of folders and files with duplication in the database. The kernel documentation is good. Write your own module from scratch is impossible in principle. The kernel provides the means of accessing the database, but the means of working with files are represented in a rudimentary level. Working with the database can be through system interfaces, as well as directly. The structure of the tables is indicated partially. All data in the database have meta-information, which entails redundancy and system overload. There is a mechanism for storing data as information blocks. Information blocks can only be in the form of categories and elements. Both categories and elements cannot be nested or complex types. Multi-site is implemented at the level of the web server and physical file duplication. The rights system is good. It is possible to organize a distinction at the level of modules and elementary actions. The quality of writing code is low. The main reason for this is clearly the poor organization of the system. The code is scattered in different files and it is very difficult to assemble a complete picture. The time to develop the Module module is 2 days, the module is 50% of the designed functionality. Adjusting the administrator zone for your module is the most difficult task in developing the module. Best practices: partial poor OOP support, error handling only at 404 level, runtime errors are output to the user, there is no template (this is just awful), ORM is missing, pseudo VO through arrays , Front-ApplicationController is missing - there are a lot of entry points (the principle of the first PHP sites through include).
- CMS is built on modern technologies PHP5, MySQL5, XSLT. The system itself is light in terms of code size and degree of understanding. The architecture of the system is built on a modular principle. There is a set of classes that implement the kernel and external modules. The kernel provides quite rich tools for working with files and databases. Modules can use any functionality. Connecting modules is simple and affordable. The documentation on the kernel is good, there is an SDK in the development of the module. The work with the database is based on the use of intra-system objects. The database structure is hierarchical in the form of a tree. Direct access to the database is missing. The structure of the tables in the documentation is not described. Data is stored in tables as data types. Data types can be inherited and nested. Multi-site based on URL parsing. Multisite is implemented logically on the basis of a single entry point with preservation of the domain of circulation. The system of rights at the module level. The implementation of the right at the level of operations is not implemented. But hypothetically possible to implement. The quality of writing code is good. The code is written transparently, centrally. Comments are present only in difficult to understand places. The time to develop a module "Module" - 2 days. The module implements the conceived functionality by about 70%. Best practices: full support for OOP (as far as PHP5 allows), centralized error handling, template engine based on XSLT, ORM based on kernel classes, VO based on data types, implementation of FrontController with transfer of control to modules.
- System architecture. Principles of working with a database. Many sites. System of rights. Quality of writing code. Time to develop a module "Module". Support the best practices.
- Source codes of systems. Documentation of systems. Technical support forums. Consultations of third-party developers who had experience working with systems. The subject of research was:
Source: https://habr.com/ru/post/20872/
All Articles