Menu
homeBrowsers

Basic information. Documentation for the boxed version of Bitrix24 Changes in the integration module

Integration of an online store on 1C-Bitrix with the system can be done using the system module in Bitrix.Marketplace.

During installation, the module will help you upload existing orders into the system.

After installation the module will:

  • upload new orders from 1C-Bitrix to the system;
  • update data on existing orders taking into account changes made to 1C-Bitrix;
  • upload new orders and clients from the system to 1C-Bitrix;
  • update data on existing orders taking into account changes made to the system (for example, the status of the order was changed in the system, the number of goods in the order, etc., these changes will also be reflected in 1C-Bitrix);
  • send information about online payment of an order by the user to the system.

It is also possible to customize plugin classes without losing the modified code when updating. In order to implement the modified code, you need to place a copy of the file with the required class in the bitrix/php_interface/retailcrm directory.

The plugin has the ability to customize the following files:

RestNormalizer.php
Logger.php
Client.php
RCrmActions.php
RetailCrmUser.php
RetailCrmICML.php
RetailCrmInventories.php
RetailCrmPrices.php
RetailCrmCollector.php
RetailCrmUa.php
RetailCrmEvent.php
RetailCrmHistory_v4.php
RetailCrmHistory_v5.php
RetailCrmOrder_v4.php
RetailCrmOrder_v5.php
ApiClient_v4.php
ApiClient_v5.php

To customize files whose names include the API version used, files are created with a name without specifying the version, for example - RetailCrmHistory.php.

After creating a copy of the file with the class in the bitrix/php_interface/retailcrm directory, the module will use a custom class; you can make changes to its methods.

Registration of an online store in the system

Before installation, register your online store in your instance of the system (section Administration > Stores, for example, in the demo version):

Installing the solution in 1C-Bitrix

  • Click “Install” on the solution page in the Marketplace and enter the address of your online store:

  • Download the module via the 1C-Bitrix Update System:

  • Start installing the module:

The installation wizard will launch.

Installation Wizard. Step 1

At step 1.1, you need to indicate the address of your system (for example, https://test.retailcrm.ru) and the API key that you generated earlier in the system:

Important! If there is only one store in Bitrix, step 1. Sites is skipped.

Installation Wizard. Step 1. Websites

At step 1.Sites, you need to set the correspondence between your stores in 1C-Bitrix and the system.

Important! All your stores in the system must have a common API key.

Installation Wizard. Step 2

In the second step, you need to indicate the correspondence between the values ​​of the online store and system directories. The module itself tries to establish correspondence for typical statuses. Where the module failed to do this, you need to specify the match yourself:

Check whether the system has the necessary directory values ​​corresponding to the online store directories. If there are not enough of them, add them in the Administration section without closing the installation wizard page:

After this, refresh the wizard page: the new directory values ​​should be loaded.

Installation Wizard. Step 3

In the third step, the module allows you to set the correspondence between the fields of 1C-Bitrix and the system.

Important! If there is a “feedback” form or “1-click” orders, and this data does not fall into standard Bitrix orders, then they are not pulled into the system.

Also, if you are working with legal entities, you must fill out all the fields, as indicated in the screenshot below.

Installation Wizard. Step 4

In the fourth step, the module allows you to upload previously placed orders into the system. Unloading may take some time (1000 orders are unloaded in about 5 minutes). The progress of the upload process will be shown by a progress bar.

If necessary, you can pause the download and resume again after a while.

After uploading previously placed orders, you will be able to see analytical reports in the KPI Panel. We recommend performing this step.

Installation Wizard. Step 5

In the fifth step, uploading of the product catalog is configured. To do this, you must complete the following points.

1. Selection of information blocks and properties

The selected information blocks will be uploaded to the system. You will be offered a choice only of those information blocks that contain products or have linked information blocks with trade offers. In parallel with the selection of information blocks, you can select the following properties: article, manufacturer, color, weight, size - for this you need to specify the information block property, which is responsible for storing the corresponding property. Selecting a property is optional.

2. File path

A file in the format will be generated at the specified path, which will contain the directory structure. The default path is - "/bitrix/catalog_export/retailcrm.xml". If you change the path, you will need to perform a similar setup in the system.

3. Setting the number of offers in export

In the catalog export settings, there is a field “Maximum number of trade offers for a product”, where you must enter the maximum number of trade offers that one product can have (if there are more than 50). By default, the module calculates a maximum of 50 trade offers for a product. If there are less than 50 trade offers per product in the store, this setting can be ignored. If there are more trade offers and the setting is specified, it is recommended to transfer the agent to crowns if it works on hits.

4. Selecting the frequency of unloading

There will be three options to choose from:

1. No- when you select this item, periodic uploading of the catalog will not be automatically configured, and you will have to upload the catalog yourself each time.

This option can be useful if the product catalog of your online store changes very rarely, or you want to configure the upload parameters later.

2. Cron- selecting this item will lead to the automatic creation of a special profile that will be linked to the Cron service of the server on which the online store website operates.

The cron utility runs in the background and performs the specified tasks at the specified time.

Selecting this item can be useful if the catalog contains a very large item ( more than 10,000 products). For this item, you must specify the name of the special export profile.

3. Agent. In this case, a special profile will also be created that will connect to the “Agents” technology in 1C-Bitrix, and the upload will take place automatically once a day.

An agent is a PHP function that runs at a certain frequency. As each page begins to load, the system automatically checks to see if there is an agent that needs to be launched, and executes it if necessary. It is not recommended to create agents for time-consuming uploads - it is better to use cron.

This option is most preferable if the directory contains less than 10,000 products, then the uploading occurs quite quickly, and this will not affect the speed of the online store website in any way.

In the case of a large range ( more than 10,000 products), additional configuration of the Agent on Cron is required. For this item, you also need to specify the name of the special export profile.

4. Indication of instant unloading

As a result of setting the “Unload now” flag, the directory structure will be unloaded into the above file, immediately after installing the module.

After uploading the catalog to a file in the system, you need to go to the Administration -> Store -> Store name -> "Catalog" tab and check the "Download catalog from ICML now" box. In this case, downloading the file and processing it begins almost instantly.

5. Specifying a profile name

After correctly setting up the uploading of the product catalog, a new type of system export will appear in the Store > Settings > Data export section; if periodic uploading is specified during installation, an export profile will also appear.

Note:
To configure uploading yourself, it is possible to create your own export profile.

Completing the installation wizard

At the end of the installation, 2 agents will be created: one agent uploads order history from Bitrix to the system, the second agent generates a catalog. If order uploading is configured for an agent, then orders are uploaded to the system at the time the history is called. In other cases, orders are unloaded based on an event.

Unloading the delivery service during the exchange 1C-Bitrix - system

If you have automated delivery services connected to 1C-Bitrix, such as eDost, which have many profiles: Russian Post, EMS, DHL and many others, then in the system you can take advantage of the ability to upload this kind of delivery service.

Delivery methods must be configured on the system side. If the system module was installed before connecting the delivery service to Bitrix, then the missing delivery methods will need to be entered into the system manually. If the module was installed after connecting the delivery service, then the delivery methods will be installed automatically, as well as the service unloading itself. That is, for each order the delivery cost will be downloaded.

On the 1C-Bitrix side, you must make the following settings if the system module was installed after connecting the delivery service to the 1C-Bitrix system:

Go to Administration > Settings, go to the "Directory Settings" tab.

Configure the correspondence of delivery methods (preliminarily configured on the system side). Next, click the "Upload delivery services" button.

Setting up the frequency of uploading 1C-Bitrix - system

When updating the product catalog, two points can be highlighted:

Catalog generation (in yml/icml format) on the client side and

The system downloads the catalog once every three hours. The path to the file that needs to be uploaded is set in the store settings - you need to go to the section Administration > Stores > Select store > Catalog tab.

After installing the system module in 1C-Bitrix, a profile for uploading is created. To see, you need to go to Desktop > Store > Settings > Data Export. The screenshot shows two options:

Default,

Uploading the system directory.

If you select the second option, clicking on it will open the upload options.

If Agent is selected as the frequency option, to view the list of Agents, you need to go to Desktop > Settings > Product Settings > Agents.

If you click “Change” or “Add new”, you can assign or change the frequency of running the generation task.

Frequency of data synchronization during exchange 1C-Bitrix - system

The system module allows you to upload a product catalog to your system, as well as carry out regular two-way exchange of orders and clients.

By timely uploading data from the catalog, your system managers will have up-to-date information about product availability. A situation where a product is ordered, and after some time it turns out that it is out of stock, will not arise.

Order exchange is a process of data synchronization when orders are uploaded in both directions:

From 1C-Bitrix to the system:

  • If uploading by events is enabled, when creating or changing an order in the 1C-Bitrix system, it will be immediately uploaded to the system. If an unloading agent is selected, the order will be uploaded to the system within 15 minutes (it is not recommended to use this mechanism without compelling reasons, since in this case orders will arrive with a delay and updates to these orders will not be transferred to the system).
  • When a user changes, the master data will also be immediately uploaded to the system.

From the system to 1C-Bitrix:

  • If you create an order for a new user in the system, the order will be uploaded to 1C-Bitrix and a new user will be created in the interval from 1 to 15 minutes.
  • If you change the address, delivery cost or status in the system on the order page, then all these changes will be uploaded to 1C-Bitrix within 15 minutes.
  • If you change product discounts in the system and change the quantity of products, this will change in 1C-Bitrix in the interval from 1 to 15 minutes.

Changes in the integration module

Version 2.0

  • The integration module version V2.0 is designed to integrate 1C-Bitrix with the “Online store (sale)” module version > 16 installed in it.
  • Now the module operates via API V4.
  • The integration module now uses the new 1C-Bitrix D7 core.
  • Now changes regarding the client (full name, email, telephone) are also sent to the website from the system.
  • In the integration module settings in the "Other Settings" section, it became possible to translate order numbers from the system to 1C-Bitrix. That is, if you manually create an order in the system with the number, for example, 12345R, then an order with the same number will be created in 1C-Bitrix.
  • Since in the "Online store (sale)" module version > 16, Bitrix developers moved away from applying discounts to the entire order and left discounts only for products, the system, for now, also does not have the ability to use discounts to the entire order. You can set discounts only for specific order items.

Version 2.1

  • Added units of measurement in catalog export.

Version 2.2

  • The module now supports several API versions with a choice.
  • API V5 support.
  • Added the ability to unload balances by warehouse.
  • Added the ability to download price types.
  • Added basic Daemon Collector integration.
  • Added integration with Universal Analytics.
  • The logic of the built-in functions for data modification has been improved.
  • Added built-in function retailCrmApiResult.
  • Added trigger version of change history.

Version 2.4

  • Added a check in the processor for saving payment for a new order.
  • Added setting for the number of trade offers in export.
  • Added purchase price conversion.
  • Changing translation files.
  • Added a check when unloading changes from the system for order properties.
  • Added VAT upload.
  • Fixed getting a list of price types for uploading. All types available in Bitrix are available for selection.

Other settings

Order settings

Transmit order numbers created in the central processing center to the store

When an order is created in the system, it generates its own unique number according to the specified rules. When this setting is set in the module, the number of such an order will be transmitted to the store during reverse synchronization.

Unloading orders

  • By event- when you save the order, the data goes into the system;
  • Agent- new orders are sent before requesting the change history from the system.

Client API version

Now you can select the API version with which the module will work. The choice depends on the system version. It is recommended to select the latest version.

Enable unloading of balances by warehouse (available if warehouses exist)

Now you can periodically unload balances from site warehouses to system warehouses. To do this you need:

  • compare site warehouses with system warehouses;
  • indicate the system stores into which balances will be loaded;
  • select information blocks with goods needed for loading balances (you need to select those that are indicated in the catalog export for the system).

Unloading is carried out by the agent with a frequency of 1 hour (by default).

Please note that to load balances into the system, the options must be enabled.

Enable uploading price types for products (available only if there are several price types)

Now you can periodically upload additional price types from the store to the system. To do this you need:

  • compare site price types with system price types;
  • indicate the system stores into which additional price types will be loaded;
  • select information blocks with products that require loading additional price types (you need to select those that are specified in the catalog export for the system).

Uploading is carried out by the agent every 24 hours (by default).

Activate Demon Collector

Now you can add the Collector Daemon to the website from the settings interface. To do this, you need to specify the appropriate key for the desired site. The key can be found in the system.

Enable UA integration

Now you can enable integration with Universal Analytics from the settings interface (works correctly with the standard ordering component). For each site to which you want to add tracking, you need to fill in the Tracking ID and Custom Parameter Index.

Where $order is the generated array of order data to be sent to the system, and $arFields is an array of order fields on the website. function retailCrmBeforeOrderSave($order) ( //Your changes return $order; //or return false; and then changes from the system for this order will be ignored)

Where $order is an array with modified order data received from the system.

function retailCrmAfterOrderSave

retailCrmAfterOrderSave - a function executed immediately after changes to the order data received from the system history are saved on the website.

function retailCrmAfterOrderSave($order) ( //Your changes return; )

Where $order is an array with modified order data received from the system.

Function retailCrmApiResult

retailCrmApiResult - a function executed immediately after receiving a response from the system API.

function retailCrmApiResult($methodApi, $res, $code) ( //Your changes return; )

Where $methodApi is the name of the API method, $res is the result of the true / false request (successful or unsuccessful request), $code is the API response status code.

Please note that errors in the code when using this function may disrupt the synchronization of the site and the system.

If the tools listed above are not enough for some reason, you can make the required changes directly to the module code without the risk of losing these changes when updating the module. To do this, you need to copy the file with the required class to the /bitrix/php_interface/retailcrm/ directory and modify it there. This mechanism supports changing classes to work with clients, orders, events, catalog export and other auxiliary mechanisms.

Bitrix Framework- technological core (platform) for creating and managing projects (websites and corporate portals). The platform allows you to create an unlimited number of projects using one copy (license) of the product, placing the core and database of the system in a single copy on the server.

At the moment, not all the capabilities of the old kernel are duplicated in D7. But the new D7 core Bitrix Framework gradually replacing the old one. If using the old kernel resulted in a warning from the IDE: Method/class is deprecated , then you need to use methods.

For a number of reasons, the API documentation may not cover all methods. To understand how it works, it is sometimes better to look at the actual program code. To do this, you can use a free module from the Marketplace: .

Note: by adding #examples to the address of any page, you can quickly go to an example, if it exists on it. (This does not work in CHM format documentation files.)


Entity versions

Bitrix Framework is constantly evolving. New functions appear, some become obsolete, and new parameters appear in functions. However, a fairly large number of projects are not updated. To make programming work easier, the documentation indicates with which version of the product the class, method, parameter, event existed (exist).

Versions are listed in two places: in the title and in the tables. If the method is valid, then the title will contain only the version number with which it appeared in the product. If the method is outdated, then the range of versions where it was valid will also be indicated.

The tables indicate the version with which the entity appeared in the product only if its appearance does not coincide with the moment of the appearance of the class, method itself, and so on. In the illustration below: the COURSE_ID parameter appeared along with the method (that is, from 5.1.0), and the CHAPTER_ID parameter only from version 9.5.4.

If a parameter (usually this refers to parameters) has changed with the development of the product, there will be a corresponding note in its description. (For example: before version x.x.x the parameter was called *****).

Example

Notes:

  • Mark Outdated for a method, parameter, or key means that it is not recommended to use it since there will be no extensions or fixes.
  • The installation of versions has not been completed completely; work in this direction is currently underway.

"Bitrix", 2001-2019, "1C-Bitrix", 2019


Bookmark Custom tasks is intended for those who will directly work with the product, that is, for employees of companies using our software product.

The Administrative tasks tab is intended for those who will administer the boxed version "Bitrix24".

Bookmark Documentation intended for developers of projects based on the boxed version "Bitrix24".

Custom tasks

Administrative tasks

For developers

Developer documentation is a description of the system API. User documentation is a description of system components and settings.

The documentation is available both online and as a file in chm format. It is recommended to use the online version as it is more up-to-date. chm files are updated periodically and may not contain information about the latest versions.

Attention! If you do not see the contents of the format file .chm, then the reason is the security settings of the operating system. In the file properties, you need to unblock the file from viewing. Read more inFAQ

Documentation is reference information. It is not enough for a novice developer to work with the system. In mastering the principles of programming in Bitrix Framework A special course will help you:

Information on working with can be found in the tutorials and documentation. Training courses are designed to master the methods of working in a software product, and documentation is designed to master the principles of CMS customization.

When working with "1C-Bitrix: Site Management" problems arise in the form of specific practical problems. We have collected different pages of training courses into specialized topics to make it easier for you to find answers to your questions.
Training centers Ask a Question Forum



Bookmark Content managers is intended for those who will directly work with the product, that is, for content managers leading projects created on our software product.

Bookmark Administrators intended for those who will administer "1C-Bitrix: Site Management".

Bookmark For developers designed for project developers based on "1C-Bitrix: Site Management".

Content managers

You can import the course to your website Content manager from this archive. Course without questions for tests.
Course version dated June 5, 2015.

Administrators

For developers

Developer documentation is a description of the system API. User documentation is a description of system components and settings.

The documentation is available both online and as a file in chm format. It is recommended to use the online version as it is more up-to-date. chm files are updated periodically and may not contain information about the latest changes in the help system.

Attention! If you do not see the contents of the format file .chm, then the reason is the security settings of the operating system. In the file properties, you need to unblock the file from viewing. Read more inFAQ

Documentation is reference information. It is not enough for a novice developer to work with the system. In mastering the principles of programming in Bitrix Framework A special course will help you:

Not long ago, our company received a fairly large online store on 1C-Bitrix for maintenance and modification. The project was put into commercial operation a couple of months ago, but at the same time it had a number of serious problems. In addition, the customer planned to complete the tasks of finalizing the new functionality as quickly as possible. I was given the task of organizing effective work on the project with minimal site downtime and maximum satisfaction of the customer’s needs.

Initial data:

  • There is an online store on 1C-Bitrix
  • The project is several years old, but only a few months ago the site was transferred to 1C-Bitrix
  • Attendance 10-15 thousand people per day
  • The store catalog contains about 12,000 product items
  • Downtime and site outages are unacceptable
  • The project was developed by another company within six months:
    1. There is a technical specification for approximately 100 sheets, corresponding to approximately 40% of the work completed.
    2. No project documentation
    3. Lack of understanding why previous developers used specific architectural solutions.

I have been developing software in general, and web projects in particular, for about 8 years. During this time, I came across projects of varying complexity and, at first glance, the task did not seem too difficult to me. When implementing projects in our company, as a rule, the SCRUM methodology is used. I started to push away from her.

First of all, I got access to the source code of the project. Superficially analyzed. Agreed with the customer on the list of priority tasks. I made a development plan for 3 developers and, as Gagarin said, let's go!

Problem #1 – the developers are to blame for everything

As is usually the case, everyone is to blame except the customer. The designer made a layout that weighs too much, the hoster provided a server that works slowly, the developers made a site that is buggy and broken all the time, the managers completed some tasks that we did not ask to perform after switching from the old version of the site to 1C- Bitrix experienced a sharp decrease in search traffic, etc. The situation is not clear-cut. On the one hand, the main responsibility, of course, should lie with the developer company. It was necessary to convey to the customer the consequences of all actions with the site and prepare for the result. When performing the work, propose a holistic architecture of the future system and a development plan that must be followed until the completion of the main stages. Conduct thorough testing of the functionality and submit the work. On the other hand, I often come across a situation where the customer knows everything better, because his mother once drew, and therefore is the best designer, and his 7-year-old son is well versed in SEO optimization, because he spends all his time at the computer, playing GTA.

It is not for us to judge who is guilty and who is right. In this case, the previous contractor was a fairly well-known, reliable company and I can’t say anything bad about their development. And the customer, objectively, cares about his product and tries to improve it. I don’t know how it happened, for myself I found an explanation in the insufficient amount of analytics provided by the contractor to the customer.

As a result:

  • The project has not been brought to its logical conclusion. Many tasks are abandoned midway
  • The project is not documented. The operation of some of the functionality is not obvious. When developing a new functionality, it turns out that functionality that previously worked and the existence of which the new developer did not even suspect has stopped working.
  • Some of the code written by the previous performer has to be rewritten from scratch
  • The intended architecture of the project is not clear to the new contractor in the first weeks/months of work. Improvement of the functionality of one module leads to the loss of functionality of a module that is in no way related to it.
  • The customer is nervous, the performer is nervous, visitors are not happy, attendance is decreasing, sales are falling

I see only one solution to the problem: gradually systematically clean out all the site modules one by one to bring the product to the required state. Some errors were included in separate tasks and completed immediately; others were corrected in parallel with the development of new functionality. The result is that with each update, after promptly clearing out bugs, the site becomes better and more stable.

Problem #2 – parallel development.

In accordance with the 1C-Bitrix licensing policy, each website license allows you to use 2 copies of the system. One as a production site, the second for development. The problem is that development is carried out by several, in my case three, developers continuously. In the case of classical development, everything is simple. Each developer works on his own module. Then functional testing of each module is carried out, all improvements are merged into the repository of some version control system, then it is tested all together (integration testing). If the result is normal, the test version is presented to the customer. After the test version is accepted, the production server is updated. In accordance with the SCRUM methodology, I determined that I would upload new versions to the production site once a week. Accordingly, there are 3-4 days for basic development. 1 day for testing and bug fixes and half a day for updating the production server. The deadlines, of course, fluctuate, but I tried to strictly adhere to the “release every Thursday” rule.

The first thing I came across was that in 1C-Bitrix there are situations in which the same file is simultaneously used in different functionality at different ends of the site. The simplest and most obvious solution is to use a version control system, in my case, SVN, which I use in all other projects. But to use version control, it is necessary that each developer has his own version of the code, which he edits and then merges into the common repository.

What about the license? Contacted 1C-Bitrix technical support. I received an offer to purchase additional. licenses for development. To put it mildly, I was not happy, but I did not receive any other offers. I found a solution quickly enough. I decided to use NFR keys. Fortunately, partner status allows it. As a result, I created 5 online store installations:

  • Production server
  • Test server
  • 3 development servers (one per developer)

Over time I went even further. There is also a separate installation for the tester. It turned out that with my luck, the customer always logs into the test server at the moment when something is being updated there. The bug track contains many unnecessary tasks that have already been completed, and the customer gets the impression that we are doing our job poorly.

Currently I am using the following scheme:

  • Each developer uses only his local copy for work
  • At the agreed time, all completed improvements are merged into a common branch in the repository
  • QA takes the merged version for testing
  • After testing and fixing errors, the demo server is updated for the customer
  • After verification and acceptance by the customer, improvements are transferred to the production server.

Among the obvious disadvantages of this approach, I would like to highlight the low level of customer involvement in development. The result is visible to the customer only at the final stage. This approach is applicable if you have a good analyst who rarely makes mistakes and is in constant contact with the customer. Otherwise, many tasks will have to be redone from scratch.

As I was building the circuit I encountered another problem. The project takes up about 80GB of disk space. Without cache and temporary files - about 60. At first I tried to remove pictures and videos from version control - it didn’t work. The information on the site changes constantly. You need to test using current data. The first site commit to the repository took me more than 2 days in chunks. The first checkout to the development folder takes several hours (SVN server on the local development network). If, God forbid, you accidentally make a complete update of the project folder, you can go away to smoke, have lunch, play ping-pong or curling. Committing only selected files or folders is quite fast. Solution: I completed the task of downloading a dozen changed files at once.

Problem No. 3 – updating the production server and collaborating with the customer

The problem is the most important, complex and not fully resolved. After all, if other problems relate to the internal work of the project, then the reputation and income of the customer, and, consequently, my income, depend on the work of the site.

Murphy's laws work great here:

  • If something doesn’t work well on the test server, it will definitely break on the production server.
  • If something works perfectly on the test server, it will still break on the production server.
  • If a bug on the site exists for only 5 seconds, one of the visitors will definitely find it and will definitely write about it in reviews or in the feedback form.
  • If the site does not work for 1 minute during an update, then it is at this minute that the company owner will show it to his friend or competitor (and this is despite the agreement on the time and procedure for the update).
Of course, I'm exaggerating, but every joke has some humor in it. The minimum load on the site is from 4 to 6 am. Of course, it would be better to update at this time, but I really don’t want to.

In the case of most web applications, there is a clear structure for dividing the application into layers and updating the site can be divided into 2 parts:

  • Code update
  • Updating a Database Using SQL Scripts

In the case of 1C-Bitrix, everything is a little more complicated. Firstly, there are a lot of files. I have more than a million of them in my project. A typical update from the repository takes no less than 20-30 minutes. You can, of course, update only the changed files, but then the whole point of the repository is lost. Secondly, and this is much more sad, often when updating you have to make manual changes and settings through the admin panel. And this is always slow, you need to remember all the changes that need to be made, there is a high probability of accidentally making a mistake. You can, of course, write an SQL script that will make all the necessary changes to the database. In the simplest cases, of course, we do just that. But in most cases, writing and debugging such a script takes more time than the development itself and much more time than performing all the actions manually with subsequent testing.

I haven't found a good solution to the problem yet. Now we update the settings in the database manually. To minimize errors, a checklist is compiled with a list of what needs to be done during the update. We try to carry out the update as carefully and accurately as possible. After the update, the whole team checks the main functionality of the production server and conducts additional testing. The number of errors has been minimized, but it has not yet been possible to completely get rid of bugs and downtime during the update.

The second thing I encountered was working together with the customer. Because The project is large, about 30 people are constantly working on it. Content managers, sales managers, SEO optimizers, marketers and many others. Naturally, everyone makes some changes to the site pages and module settings. The first decision was to take away the rights from the customer to make changes to the site’s program code. The decision was absolutely correct, but it only got worse. If earlier the customer assumed that he could also go to the site and accidentally break something, now all the trouble began to fall only on us. What does it have to do with it. Even if the content manager edited the text on the page crookedly and did not close some tag, the developer is still to blame. The solution was found to be quite simple. The marketplace has a free module for page version control. This didn’t solve the problem, someone will still mess something up from time to time, but now it’s possible to see at any moment who changed what they changed and why everything broke. The result, of course, is not ice, but it saves me a lot of nerves.

Additionally, we decided that before each update of the test server, we take a copy from the production server to it. This also takes a lot of time. Archive the project, move it to another server, unzip it. All this takes several hours. But new improvements are tested practically in combat conditions. If the settings of the test and production servers are identical, the difference in operation will be minimal and the number of errors will be significantly reduced. As experience has shown, in a week the production server can change so much that some of the new functionality that works without problems on a week-old copy may not work at all on a fresh copy.

Problem No. 4 – “do it for me urgently, this is a 5-minute task”

The problem relates not so much to 1C-Bitrix, but to the refinement and support of working projects. Often the customer has a desire to do some small thing, but urgently and immediately on the production site. The result is always the same - nothing good comes out of it. In the best case, this modification will simply be forgotten during the next release; in the worst case, the server will simply crash and will have to be restored from backup for several hours.

I found only one solution - never follow the customer’s lead at the expense of reliability and safety. No matter how the customer asks, the developer will always be to blame. As my former boss told me: “I didn’t ask you to do anything bad.”

And since we touched on the topic of backups, I want to note. Backup using 1C-Bitrick is of course good and convenient, but very slow. If you urgently need to restore 1-2 files or several values ​​in the database, you have to wait until all 60 GB are unzipped. The following scheme seems to me to be the most effective:

  • There should be a daily backup of files and databases in the form of an archive to an external data source.
  • We always make a backup immediately before updating in one of 2 options:
    1. Option light – Copy the entire project folder to a nearby folder on the server. We save the database as a dump into a separate file. We don't archive anything. In case you need to restore some value in the database or one of the files, everything will be at hand and easily accessible
    2. Option strong – similar to the previous one, only we copy the database to another MySQL database. This will allow, in the event of a complete crash, to correct the site’s root folder in the hosts file in 1-2 minutes, and the project will start working from a neighboring folder with a copy of the database.

Conclusion

Thanks to everyone who read to the end. I hope my experience will be useful to you. I will be glad to receive suggestions for better ways to solve the problems raised in the comments or in a personal message. Now I have tried to voice the main problems of finalizing and supporting already launched projects with high reliability requirements. If the material turns out to be interesting, I plan to write a continuation about the features of the 1C-Bitrix architecture that distinguish the development of a site on Bitrix from the development of other web projects.