Why Bitrix? Or the fairy world 1C

One day, on Monday, the thought occurred to me - “but I dig in the new core” (relatively new, but more on that later). The thought did not appear out of the blue, but the prerequisites for it were:

• test task, from one of the large studios of Mother Russia (in which the abbreviation ORM appeared),
• the idea of ​​writing a simple module,
• the desire of one of the customers, in the future, to make a store.

So, I want to share the story of this campaign in the dense tropical jungle.

A short introduction

I do not consider myself a programming guru either on Bitrix, or on anything else. The article reflects my observations, experience and thoughts. Constructive criticism is welcome, as well as well-reasoned disputes (as Socrates bequeathed). The background has highlighted three broad topics that will not be addressed. Like their main aspect - programming working with data within the framework of the Bitrix D7 kernel (ORM), although it is a fundamental factor for writing it.

In the pool with the head

The aspect of working with data is fundamental and without it, nowhere, I thought, and decided to go right away google look through the documentation, hoping for a detailed description and the availability of examples, and of course look at the courses. With a light hand and hope for something tasty and new. Seeing no cause for concern, I went camping. The clouds were gathering ...

What you need to know about the jungle or the rules of survival

Rule number 1 - Beware of unscrupulous travel agents

I decided to start with the courses, having seen the menu items that interest me (module and ORM), I thought a bunch of texts and code inserts - everything will be fast, let's go ... So my next mistake was made. In fact, it turned out:

• the courses are poorly structured - the study order is not thought out, you can find the absence of any connection between the chapters;

  
  
  
  
  
  
  

• permalinks - I'm not talking about links to documentation, but links to stack overflow and other chapters (at the end of the course, between which there is a sea of ​​information) are very distracting, this is not serious;

  
  
  
  
  
  
  

• water and common words - you can put a tick in the number of characters;

  
  
  
  
  
  
  

  Bold typeface is used to highlight important words, terms, phrases and sentences. That is, what is especially important in the context of the described functionality:

  
  
  

• interpretation of concepts in their own way is still an old topic (API - Component - Template aka MVC);

  
  
  
  
  
  
  

• inserts from the documentation - copy-paste of whole pieces, sometimes just to fill a place;

  
  
  
  
  
  
  

• quotes from developers - there are simply no words -_-, why is this bluster;

  
  
  
  
  
  
  

• outdated chapters - it just seems impossible to delete them; they reinforce the confusion at times.

  
  
  
  
  
  
  

  Relationships between entity (obsolete) or Product discount settings

  
  
  

Of course, the plus is that, in principle, there are courses. Probably a plus, because writing something only on their basis is still that task. Anyway. After reviewing the courses, mostly inserting the code, I decided to try, but there is still documentation. It started to drizzle ...

Rule number 2 - Beware of dense thickets

Having made a couple of simple samples using Scotch documentation, I decided to try to get a discount on the goods. And then the rain began. Pseudon core and easter eggs:

• two modules for discounts - yes, yes, I thought for a long time - why I added the discount, it is in the product, but I can’t get it through the DiscountTable
  
  
  
  entity class. I had to write in support. The answer was this:

DiscountTable - discounts on goods, belong to the module Trade Catalog, the functionality is outdated and not used. We recommend using the Cart Rules.

• lack of documentation - but you can get a link to the documentation - asked
  
  I. Expecting that from 2013-2015 she appeared. Answer:

The documentation for creating the Basket Rules is still in development.

• the work scenarios were not thought out - my next question was logical - How can I get a discount? To which I received an enchanting answer and ended up communicating with support:

To get the rules for working with the basket that apply to the product, you will need to create a basket object and perform the calculation for the product.

• incomplete functionality - some class methods may return error messages like:

To add product discounts, use the call CCatalogDiscount :: Add ()

• complex architecture - to create a complex selection of several tables, special relationship objects are used, which must be added to the SomeTable::getMap()
  
  
  
  method. This is not always easy (some entity description classes are generated automatically). Also, it saddens the fact that it is impossible to obtain a complex sample simply in the format of a multidimensional array. And the construction of relations can take more than a dozen lines.
• labyrinths of functionality - in D7 there are places that are constantly rewritten and at the same time all variations are supported. The same relationship objects can be implemented through: Entity\ReferenceField
  
  
  
  || Bitrix\Main\ORM\Fields\Relations
  
  
  
  || runtime
  
  
  
  (upon request)

All this is very depressing and makes you indignant, to say the least. And besides this, there are other inconveniences.

Rule 3 - Damn Insects

Bitrix has a number of strange and intrusive features that you constantly forget about, but they again flash before your eyes:

• rules for naming classes and files - your own forklift leading everything to lowercase, different names of classes and files;
• ways to connect third-party solutions - for example composer or vue (which is simply contained in the BX library without any obvious reasons and add-ons) ;

• support for old code - a lot of redundant, unnecessary classes and constant confusion;
• forgotten components - only the iblock module components were updated;
• component templates - the notorious and well-known, with business logic at the ready;
• implicit logic and problems with customization - after changing the order script, you can catch a subtle error and problems with modules;
• ubiquitous static - you start to think that this is normal;
• controversial admin panel - sometimes not convenient and not adaptive, but to develop modules for it ... mmm;

Trifles, but they are always nearby.

Rule number 4 - Strangers and natives are dangerous

Bitrix has one more benefit (no) - a large community. You can find any information, but its correctness and relevance will be a big question. Often, you can only learn how to create crutches or use an ancient code that already has an adequate replacement. But there are also messiahs who can show the way to their flock. One of these said:

To work with infoblocks, use the old kernel, which works well and stably.

I think I will do so.

Rule number 5 - Predators somewhere nearby

Marketers praising a product. Comparative articles where Bitrix is ​​the undisputed leader. A bunch the floor programmers, as I am. Many sites that ask to end their torment. Also the scourge of the community.

Rule # 6 - Have Water

With each new problem and the lack of an adequate solution, morality falls and you miss a move thoughts come, but is it all that is needed for this waste of time. The framework, containerization, and continuous integration may be better, rather than these half measures. In such cases, only a strong-willed decision well, demand saves the situation.

Rule number 7 - Tropical rain is hard

And it finishes one unpleasant fact, for attempts at programming, searching and structuring information, communicating with experts and returning to the past, learning something new, it takes a lot of time, in the absence of an intelligible result - it is constantly depressing.

Civilization aka conclusions

And here you come out of the jungle. Shabby but alive. Broken but still not broken. Your tired eyes are open and they see everything. A path where it really is worth moving and trails where special care is needed.

Bitrix is ​​a controversial product, saying that he generally developing develops incorrectly - not worth it. But to say that he is the best without noticing the flaws is blindly believing.

For myself, I decided, Bitrix - no. A complete failure, of course, will not work, but to develop a product in which for 5 years there has been no support for the basic functionality and intelligible documentation, for the new and announced kernel - I see no reason. It’s better to write a simple solution that will be used from project to project on the old core and go learn a new one.

Old man Frankenstein, of course, is worthy of life, at least a couple of worthy ideas in it. After all, we are not in the Middle Ages to burn at the stake all those who think differently. Or is it still worth what you think?

PS The article was written in haste, if you could not build a consistent chain of thoughts.