How not to develop a project on Bitrix
For all the time of my work with Bitrix, I had a chance to work with a very large number of projects that someone developed before me. Here and minor improvements, fix various bugs and logic errors, site redesign and global changes to the existing functionality. And, like any other developer, I can not stand to rake someone else's garbage, crutches and "temporary" patches, which in fact remember another 8 editions of the product.
Here I will try not to focus on the standard “worst practice” when programming in PHP, such as a devil-may-care attitude to the choice of variable and function names, unnecessary queries to the database in a loop, lack of user data checks in forms, ignoring comments and the like. I will try to touch on the moments peculiar to the development on Bitrix, which later will allow you to avoid resentment and curses in your address from the programmer, who fell to accompany your code. And yes, quite often this programmer will turn out yourself in a year, or more, when you completely forget why you inserted this or that crutch here.
Do not modify the kernel. Even if you are sure that it will not be updated. Even if it is faster. Even if you are too lazy. Forget this thought like a bad dream. If you need to change the logic of the standard component, transfer it to the new namespace / local / components / modify / and work with it. The same applies to modules, gadgets and activities of business processes.
Do not litter the init.php file. Combine the functions for working with a specific module or functionality into a class, write this whole class in a separate file, and in init.php just connect these files and set event handlers. I met init.php files of 500Kb, where functions, definition of constants, classes and initialization of handlers were mixed into the mess. Of course, when I had to understand these files, I cursed all my predecessors.
The next item does not apply to the case of developing ready-made solutions for the Marketplace, when the goal is to make the most customizable functionality from the public part for the end user. If you are working on a specific project, on a specific TK - you should not try to make a unified template for the component for all occasions. Personally, I adhere to the philosophy - it is better to have a few simple templates used for different purposes than one universal, but in which the devil himself will break his leg. Of course, in each particular case, you need to build on the fact that there is - a technical task, implementation options, and the like, but you still should not forget about “Occam's Razor”. As an example, I will give one project of a leasing company that I happened to rule. The project itself, of course, was implemented terribly, it was of real horror in the pages of the services catalog section. Each of the five sections had its own layout, in which both the position of the blocks on the page and the presence of some of them were different. And for all five pages, one template was used with a bunch of if-else, duplication of component calls, connection of styles and scripts, which, moreover, periodically conflicted with each other. As a result, a huge file in which to understand "without a half liter" was like death. Although it would seem that it was impossible to make 5 different templates and not create difficulties out of the blue?
Use API . Do not reinvent bicycles where it is not needed. Use the documentation - the whole product is pretty well described, as well as each function can be viewed in detail on bxapi.ru.
Avoid direct requests to the database . This is a special case of the previous item - use the API. Rough, unprotected requests can lead to data corruption, loss, or even data compromise.
Do not use CNC components from the site root . The consequences are usually quite sad, because the CNC uses the address handler file, trying to use it from the root easily breaks down the addressing of other components, as well as 404 pages. Nothing bad will happen if the articles you address are relative to the / articles / folder, and goods are relative to / catalog /.
Connect css and js using the API. Until now, everywhere I meet connecting scripts and styles with the help of html-tags. Use the class object \ Bitrix \ Main \ Page \ Asset and the addJs () and addCss () functions. This will allow to merge files and, subsequently, cache them with one click of the checkbox in the settings of the main module.
And finally, the error concerns not only Bitrix, but it’s too often I began to encounter problems associated with it. Check for an empty array with the results of the sample. As an example, the last time I encountered this problem when working with one online store. Complaint: pages are sometimes loaded for 16 seconds. What is connected with is not clear. Through trial and error, I found out that pages are loaded indecently long only when the basket is empty. It seemed, why would? As it turned out, a hover window appeared in the basket upon hover, in which images of the goods placed in the basket were displayed. Well, what did the previous developer do? I took the result of the work of the “small basket” component and in the file result_modifier.php made a call to GetList () of goods to select images with a filter from the product ID array, then from the results of the selection, add the src image to the array of the corresponding product. As a result, when there were no goods in the basket, the filter left empty, and the whole catalog of goods got into the sample. Well, then a cycle for each and ... we have what we have. It is clear that at the development stage with test 15 products it was imperceptible, and problems arose already in combat conditions. Although it would seem, what it cost to put a check on empty ($ arResult ['ITEMS']) ...
At this point, I finish my personal worst-practice top regarding development on Bitrix. If at least someone this information will help to avoid mistakes in the future and improve your development style, then it was not in vain.
Here I will try not to focus on the standard “worst practice” when programming in PHP, such as a devil-may-care attitude to the choice of variable and function names, unnecessary queries to the database in a loop, lack of user data checks in forms, ignoring comments and the like. I will try to touch on the moments peculiar to the development on Bitrix, which later will allow you to avoid resentment and curses in your address from the programmer, who fell to accompany your code. And yes, quite often this programmer will turn out yourself in a year, or more, when you completely forget why you inserted this or that crutch here.
“Write the code as if it would be accompanied by a violent psychopath who knows where you live” (c) John F. WoodsThe first and most important thing, in my opinion, is for the sake of all that is holy, use the local folder . This is simply vital when using the version control system - all you need is to add the / bitrix / folder to the exceptions. Everything. Further, almost all development is carried out only in it. This makes it much easier to find the necessary files and components later, it helps not to clutter the repository with unnecessary files, and in general, it brings the project tree into a neater, “human” look.
Do not modify the kernel. Even if you are sure that it will not be updated. Even if it is faster. Even if you are too lazy. Forget this thought like a bad dream. If you need to change the logic of the standard component, transfer it to the new namespace / local / components / modify / and work with it. The same applies to modules, gadgets and activities of business processes.
Do not litter the init.php file. Combine the functions for working with a specific module or functionality into a class, write this whole class in a separate file, and in init.php just connect these files and set event handlers. I met init.php files of 500Kb, where functions, definition of constants, classes and initialization of handlers were mixed into the mess. Of course, when I had to understand these files, I cursed all my predecessors.
The next item does not apply to the case of developing ready-made solutions for the Marketplace, when the goal is to make the most customizable functionality from the public part for the end user. If you are working on a specific project, on a specific TK - you should not try to make a unified template for the component for all occasions. Personally, I adhere to the philosophy - it is better to have a few simple templates used for different purposes than one universal, but in which the devil himself will break his leg. Of course, in each particular case, you need to build on the fact that there is - a technical task, implementation options, and the like, but you still should not forget about “Occam's Razor”. As an example, I will give one project of a leasing company that I happened to rule. The project itself, of course, was implemented terribly, it was of real horror in the pages of the services catalog section. Each of the five sections had its own layout, in which both the position of the blocks on the page and the presence of some of them were different. And for all five pages, one template was used with a bunch of if-else, duplication of component calls, connection of styles and scripts, which, moreover, periodically conflicted with each other. As a result, a huge file in which to understand "without a half liter" was like death. Although it would seem that it was impossible to make 5 different templates and not create difficulties out of the blue?
Use API . Do not reinvent bicycles where it is not needed. Use the documentation - the whole product is pretty well described, as well as each function can be viewed in detail on bxapi.ru.
Avoid direct requests to the database . This is a special case of the previous item - use the API. Rough, unprotected requests can lead to data corruption, loss, or even data compromise.
Do not use CNC components from the site root . The consequences are usually quite sad, because the CNC uses the address handler file, trying to use it from the root easily breaks down the addressing of other components, as well as 404 pages. Nothing bad will happen if the articles you address are relative to the / articles / folder, and goods are relative to / catalog /.
Connect css and js using the API. Until now, everywhere I meet connecting scripts and styles with the help of html-tags. Use the class object \ Bitrix \ Main \ Page \ Asset and the addJs () and addCss () functions. This will allow to merge files and, subsequently, cache them with one click of the checkbox in the settings of the main module.
And finally, the error concerns not only Bitrix, but it’s too often I began to encounter problems associated with it. Check for an empty array with the results of the sample. As an example, the last time I encountered this problem when working with one online store. Complaint: pages are sometimes loaded for 16 seconds. What is connected with is not clear. Through trial and error, I found out that pages are loaded indecently long only when the basket is empty. It seemed, why would? As it turned out, a hover window appeared in the basket upon hover, in which images of the goods placed in the basket were displayed. Well, what did the previous developer do? I took the result of the work of the “small basket” component and in the file result_modifier.php made a call to GetList () of goods to select images with a filter from the product ID array, then from the results of the selection, add the src image to the array of the corresponding product. As a result, when there were no goods in the basket, the filter left empty, and the whole catalog of goods got into the sample. Well, then a cycle for each and ... we have what we have. It is clear that at the development stage with test 15 products it was imperceptible, and problems arose already in combat conditions. Although it would seem, what it cost to put a check on empty ($ arResult ['ITEMS']) ...
At this point, I finish my personal worst-practice top regarding development on Bitrix. If at least someone this information will help to avoid mistakes in the future and improve your development style, then it was not in vain.