Get best of the week

Problems and principles of customization of the boxed version of Bitrix24



Many companies at some point come to the conclusion that a number of business processes need to be automated so as not to lose their place in the sun and their customers. Therefore, customers are increasingly starting to “digitize” their business.

There are different platforms for this purpose, Bitrix24 is one of the most popular. The speed of development and emergence of new features, high-quality support and a rich set of tools that even with minimal customization covers the basic needs of most different companies, makes this platform an almost perfect solution for business.

But, alas, not for developers, especially beginners.

Experts write training articles on 1C-Bitrix and various modules of the system, but after reading them, beginners still do not have a common picture and understanding how everything works on this platform. There are articles on the Internet about best practice development on frameworks, but development on B24 is bypassed. There are companies that have learned to make a quality product, but they keep their best practices secret.

If you want to know how you can work with Bitrix24, while maintaining the original hair color, welcome to cat.

Julia Silantieva is a leading developer of Bitrix24 in the ITECH full-cycle digital agency.

What is Bitrix24


Probably, everyone who, due to duty or out of interest at least once encountered the development for Bitrix24, knows the product 1C-Bitrix: Site Management (BUS) . This is a CMS for creating websites or, by the definition of Bitrix itself, an Internet resource management system.

But few people know that the Bitrix24 corporate portal is a service written in 1C-Bitrix.

Bitrix24 has 2 solutions: cloud and box. They differ, as the name implies, by the location of the portal code: on Bitrix servers or on the client server. The box gives more room for imagination, but has a more expensive license and needs server support, and the cloud is cheaper, but has a number of restrictions on customization.

In general, you can modify both cloud and boxed versions. Which solution to use depends on the needs of the client.

In the framework of this article, I want to consider in more detail the general approaches to development on the boxed version of Bitrix24 .

Box Solution: Product Architecture


Inside the service lies the Bitrix Framework , which is the core of the site.

Bitrix Framework contains modules and components:

  1. A module is a data model and API for accessing this data. The whole product is structurally divided into modules that are responsible for a particular area of ​​application: Intranet, Tasks, CRM, Business processes and others.
  2. A component is a controller and view for use in a public section. A component using the API of one or more modules manipulates data. The component template (view) displays data on the page. The components are part of the modules, but solve a narrower, more specific problem, for example, display a list of tasks or a deal card. The entire public part of the service is built on a call from the page of various components. For example, a CRM deal list page consists of menu, filter, and list components.



The core of the Bitrix Framework are files located in the / bitrix directory . You cannot make changes to the kernel ( Generally. Never. Do not even think about it ) for several reasons:

  • when updating the system, the changes made will be erased;
  • ;
  • , — , .

However, there is another big caveat.

The Bitrix24 portal, like any other site written in 1C-Bitrix, includes a site template, a public part (i.e. sections and pages), components and component templates. And it differs from a regular site in that when installing updates all of the above is also updated. Therefore, the public part, the Bitrix24 template and standard components can also be considered the core of Bitrix24 . And this means that you can’t make changes in them either (at least because they will be deleted during the next update).



But there are still loopholes, and it’s real to make changes painlessly.

Updateability


Product updates are very important. They solve security problems, close existing bugs (however, sometimes they produce new ones right there :)). Sometimes new cool buns arrive with updates.

Major new Bitrixoid products are presented at their conferences, which are held every six months (the last was held in April online ), but they are released with patches almost every day. Keeping abreast helps email updates. You can connect it in the admin panel of any portal on Bitrix24: Marketplace -> Platform Update -> Advanced -> Subscribe to receive information about updates by mail .



Bitrix advises installing updates as soon as they become available. But I would recommend not always adhering to this advice. It is advisable to install updates at times of minimal load on the server, for example, on weekends or at night - according to Murphy’s law, at the moment when you need to do everything quickly and quietly, Bitrix crashes with an error when updating. :) Of course, this happens infrequently, but it will not hurt to play safe. And do not forget to backup before starting updates.

Customization Principles


All development should be carried out in one folder - / local .

To add your functionality to the site written in BUS, just find the component you need, copy it to the / local folder , customize the class and component template.

At Bitrix24, this approach is fundamentally wrong.

Firstly, if you copy the template to the / local directory , the system will always use it instead of the standard one. This means that after the next update, the client will not see new functions that could be added to this component, and errors, if any, will not be fixed. Manually maintaining the relevance of the components is difficult, and if the changes were global, then impossible.

Secondly, the service components are a complete system, and their code is written on the assumption that the original system is used in the whole system. This means that a customized template can lead to information incompatibility with the rest of the system and become a source of hard-to-catch errors.

What, then, is a developer who needs to change or add some kind of logic?

There are several solutions to the problem:

  • take advantage of certain permitted points of insertion into the interface and deferred functions;
  • change the result of component execution and add your own styles and scripts to it;
  • create your own business process or set up robots;
  • bind to events on the side of PHP or JS;
  • create your own type of field (for example, a widget);
  • write your application;
  • write your module.

For each task you have to choose the most suitable tool.

Local


The main folder where the developer can and should run his hands is / local . Initially, it is not on the project, so you can fill the folder at your discretion, but in terms of paths it is important to follow the instructions of Bitrix, otherwise the platform will not see custom components and modules.

We offer a universal folder structure / local :



  • activities contains actions of business processes.
  • components contains self-written components (not to be confused with customized Bitrix components!).
  • css , fonts , images , js contain the corresponding files and resources.
  • modules . , .
  • php_interface php-. ajax-, , , .
    • init.php — Bitrix Framework. . , , . init.php , , , init.php . , , __autoload composer.

  • templates .
  • tools cron .

The structure is very flexible: when it is necessary (for example, when new tasks appear), you can add new sections to the folder, rather than spend time developing a new structure.

When processing folders, priority is always given to the / local folder over / bitrix . This means that if in / local / templates / and / bitrix / templates / there are website templates with the same name, then the template from / local will be connected .

An important observation follows from here : in order for Bitrix to understand that it is necessary to take customized component templates from the / local folder , it must have a certain structure:

/ local / templates / site_template / components / namespace / component_name / template_name / .

At the same time, the site template folder in / local (we are talking about Bitrix24, not the BUS) should contain a template created by Bitrix ( / bitrix / templates / bitrix24 / ). Only in this case, the system will understand that it is necessary to connect the component from / local .

What else is important to keep in mind when designing?


1. All language variables must be stored in the corresponding lang files. The language file is a php script that stores translations of language phrases into a particular language. This script consists of an $ MESS array, the keys of which are identifiers of language phrases, and the values ​​are translations into the corresponding language.

Each language has its own set of language files stored in the subdirectories / lang / of the file structure of the system or module.

Why is it important to take all the texts into separate files? When translating your portal into another language, it will be enough to collect and translate only phrases from language files, while creating new sections for the corresponding language. There will be no need to look for places where texts can occur in the code, and make changes directly to the portal code.

Read more about how to use language files in an official document .

2. When working with components, you do not need to access the database directly. The concept of working with the product involves working with data through API functions. The data structure can vary from version to version, and functions retain backward compatibility. Bitrix strongly discourages the use of direct database queries, as this can violate data integrity and lead to system inoperability.

Moreover, if we are talking about the system tables of the Bitrix Framework itself, this is not just not welcome, but in principle not supported. It is necessary to work with them through the API of the system, since the physical structure of the database can change, and the work of even the oldest API is guaranteed.

3. Versioning work on a project using a version control system. At the same time, due to the peculiarities of development on Bitrix, it makes sense to provide for a “peculiarity” in setting up the repository for the project: separate the core files and the custom ones.

4. Read the docks. On many local issues, especially common with 1C-Bitrix, you can find separate articles or documentation. For developers who are accustomed to google immediately in English, it will be a surprise that most of the articles are written in Russian. :)

And you need to remember the golden rule that experienced developers advise to adhere to: less code - fewer bugs .

Total


Today you can observe the imbalance between supply and demand in the development market for Bitrix24. The need for developers is growing rapidly, and many experts do not want to get involved with the product from Bitrix, as they are familiar with its oldest and almost dead brainchild - BUS.

But the devil is not so terrible, and even novice developers will be able to get accustomed and produce a high-quality product, which "is not a shame for the boys to show" © user habr.

More articles:


All Articles