Why implementation of Bitrix modules breaks at the setup stage
A module from the 1C-Bitrix marketplace is bought, installed, license activated — and at this point Bitrix module implementation is usually declared complete.
A week later it turns out the catalog is not indexed, exchange with the accounting system fails on schedule, and the very first update overwrites edits.
The site lives in manual patch mode: every modification goes through server access, every failure goes through finding someone to blame.
The most expensive part is the catalog and listings. Properties are not linked to sections, trade offers are not matched with products, the facet index is not rebuilt — the filter returns empty pages or a server error.
Catalog and listing setup means order in properties, section URLs, managed cache and sorting rules; without them a ready-made solution looks working but does not sell.
The second silent failure is exchange. Agents and scheduled tasks conflict over locks, the queue grows, and nightly synchronization with the warehouse or accounting stalls. In the browser such errors after installation are not visible — the log shows them.
The third is the conflict of updates with modifications. An edit in vendor code disappears on the next module update, and updating is necessary: closed vulnerabilities, compatibility with the current core branch.
Therefore adaptation of a ready-made solution is built so that modifications live in own templates and modules, not in vendor files.
Next we analyze how this is addressed: configuration audit, index rebuilding, separation of exchange and modifications, update procedure.
Measurable effect: what changes after solution adaptation
The effect of adaptation is visible in four numbers, and we take them before work starts and after launch — otherwise discussion about the result remains evaluative.
Implementation of Bitrix modules begins exactly with measurements: catalog listing speed, share of lost requests, frequency of exchange failures, time to return the site to operation after an update.
We measure catalog speed on real queries, not on the homepage: a category with property filters, sorting and pagination.
After moving heavy queries out and reindexing, the page is served many times faster — a catalog of several thousand items goes from four-five seconds to less than a second.
We count update resilience by the number of conflicts: core and template edits are moved to a separate layer, so a new version of the marketplace solution is installed without manual file comparison.
Exchange errors with 1C are also translated into numbers — the share of items with discrepancy in stock and prices and the number of records stuck in the queue unprocessed.
Site recovery time is the most underestimated metric: a copy is taken before work, the rollback procedure is tested on a test environment, so return to working state takes tens of minutes instead of hours of downtime.
The share of lost requests falls when resend and exchange queue control are configured: requests that previously disappeared during a failure reach the manager.
Methods of connecting solutions from the Bitrix marketplace
Connecting a marketplace solution is always a choice between configuration with standard tools and code modification.
Modules 1C-Bitrix are updated together with the core, and any changes in their files are overwritten during update: logic returns to standard, and with it previous limitations.
Therefore before installation we analyze which processes are covered by settings and which require their own logic.
In practice a standard module covers most tasks, the rest is added via extension points — event handlers and separate components. Below is a comparison of implementation options by scope of work, updatability and support.
| Option | When suitable | Limitations |
|---|---|---|
| Ready-made solution without modifications | Processes match standard, quick launch needed | Logic adjusts to the module; non-standard scenarios are not supported |
| Ready-made solution plus adaptation | Module core is suitable, some scenarios are own | Edits in files are lost during update — the wrapper is moved to events, each update is checked on a test environment |
| Partial modification with own code | Module covers the main part, the rest is an own add-on | Two sources of logic: when the module version changes its interfaces change, regression checks are needed |
| Custom development | Processes are unique or the standard solution pulls extra | Longer launch, support and compatibility with core updates — the developer's responsibility |
We fix the choice before work starts: it determines who is responsible for compatibility after the next module and core update.
Work stages: from project audit to handover to support
Installing a marketplace module rarely comes down to clicking a button: the solution has its own requirements for the core, rights and data structure, and the production site lives by its own rules.
Therefore we install not on the production site, but step by step — with a separate staging environment and a rollback point at each transition.
- Audit and requirements. We analyze the scenarios the module must cover, the catalog structure, the user group map, exchange with 1C and environment limitations. The output is a task list and a list of what installation may affect.
- Solution selection. We compare modules by task coverage, update freshness and compatibility with the current build, so as not to rewrite half the logic ourselves.
- Test environment. We raise a copy of the site — database, files, environment — and install the module there first: an unsuccessful build is rolled back without affecting visitors.
- Adaptation of templates and rights. We modify components and markup, separate roles so that new functionality does not grant extra access, and check that old pages work as before.
- Scenario and load testing. We run end-to-end scenarios, exchange, checkout and response under peak traffic, look at error logs; edits are returned to staging.
- Acceptance after setup. We compare the result with the agreed checklist and close deviations before transfer — acceptance is based on facts, not on "generally works".
- Transfer to the production site. We transfer only approved changes, take a backup, choose a low-activity window and keep a ready rollback scenario. Then comes documentation and handover to support: what changed, what settings are set, how to update the solution further.
Handover package: configurations, access roles, policies
Implementation of a marketplace module ends not when it works, but when the customer can maintain it without us.
The handover package is the same work result as a configured exchange or access rights: if logic lives only in code and the engineer's head, any edit turns into reverse engineering from source.
- Configuration description — which modules are enabled, which parameters are set, where standard templates and handlers are overridden, what is changed relative to standard delivery.
- Roles and access rights — matrix "role → section → allowed actions" plus separately service exchange accounts with minimum required rights.
- Data exchange scheme — what syncs with what, in which direction, by event or schedule, which object is considered the source of truth on discrepancy.
- Update procedure — procedure for checking a new module version on a copy, work window, rollback point and method to the previous release.
- Instructions for content managers — required fields, section nesting rules, what cannot be changed manually so as not to break output.
- Acceptance checklist — which scenarios were run, on what data, what is considered passed and what limitations remained known.
- Change log — who, when and why changed settings, linked to the task and the reason for the edit.
The package is stored with the project and updated at each release, not written once at delivery. Six months later a new administrator opens the settings documentation and sees the current picture, not reconstructing it from code.
Case: migrating the catalog to a ready-made solution without downtime
A store with a catalog of tens of thousands of items worked on custom modifications around a ready-made solution.
Product card response held around 3–5 seconds, exchange with the accounting system failed almost daily, and modules were updated only at night — with order acceptance stopped for 2–4 hours.
Diagnostics showed three causes: exchange every night unloaded the entire catalog, cache was reset due to direct database queries on every storefront view, and some modifications overrode standard handlers and fell off on every update.
What changed
The catalog was moved to the current 1C-Bitrix branch, exchange was built on incremental upload — only changed items and prices are transferred, not the entire reference.
Caching and indexes were configured for real storefront queries, and non-standard logic was moved to separate modules unaffected by update. Before each release we take a copy and check rollback to the previous version.
Metrics before and after
| Indicator | Before | After |
|---|---|---|
| Product card response | 3–5 seconds | up to 1 second |
| Exchange failures with accounting system | daily | none recorded |
| Downtime during update | 2–4 hours | 5–10 minutes |
| Nightly upload | entire catalog | only changes |
Updates are now installed in a working window: order acceptance stops for a few minutes, and rollback takes the same time if the release fails the check.
Exchange failures stopped being a daily background, and server load grew predictably — the storefront handles seasonal peaks without manual intervention.
How does adaptation of a ready-made solution differ from task-specific modification?
Adaptation is enabling what the solution already has: module settings, component templates, custom properties and event handlers. The core remains untouched, so updates of 1C-Bitrix and the solution itself are installed normally.
Modification begins where logic diverges from the customer's process and cannot be expressed by settings.
The fork is determined by signs, not wishes: calculation conditions change, field composition in a document, status scheme or exchange rules with the accounting system. One or two such divergences — adaptation is faster and cheaper.
If half the scenarios need rewriting, updatability can no longer be preserved, and it is more profitable to maintain your own development branch.
Updatability is the main selection criterion. Editing core files is lost on the next update installation, and with it support from the solution author goes: errors are not fixed, compatibility with the new platform version is not guaranteed.
Therefore we move changes to a separate layer — own module, events, overridden templates — and fix the update procedure in the policy.
Scope estimation is built from the number of extension points and affected entities: how many fields, statuses, roles and exchanges change, which will survive the update, what will have to be transferred manually. Such analysis before start shows where settings suffice and where development is needed.
Frequent technical questions about installation and compatibility
Before estimation we always discuss these five questions — they determine both the scope of work and the risks. Below briefly how each situation is handled in practice.
Will a module update overwrite our modifications?
Edits in the core are the main source of conflicts on every update. We move modifications to a separate layer: own components, event handlers, overridden templates in a child theme — then the standard update passes without manual file merging. If an edit is needed inside the module, it is formalized as a patch and rechecked on every update.
Will the module handle a catalog of tens of thousands of items?
It depends not on catalog size, but on how the module accesses the database. We look at queries in lists, caching, indexes by properties and whether it makes queries inside a loop.
If necessary, we move heavy pages to paginated output and cache with event-based invalidation — response time stops growing with the catalog.
We already have exchange with 1C configured — will it have to be redone?
Not necessarily. First we analyze the current exchange rules: which entities are uploaded, by which keys they are matched, how trade offers and stock are processed. We connect the module on top, overriding only the steps where its fields and logic are needed. If the rules conflict, we move them to a separate layer and compare checksums of uploads.
Will installation require site downtime?
Installing a marketplace module is performed on a working site — it is registration of the solution and its files. Downtime is needed only if the data schema or section structure changes.
We schedule such work for a night window: first deploy a copy of the site, check migration, then transfer changes to production and compare key pages.
What about the module license and its updates?
The license is tied to the product edition and the number of sites where the solution is used — some modules do not work on junior editions. We check this before purchase so as not to pay for an incompatible solution.
Separately we fix whether the license includes access to updates and technical support, and configure updates via the standard mechanism with a check on a copy.
Let's discuss the task: what to clarify before starting work
To discuss the task substantively, rather than get a from-to range, we need inputs on your environment. The more accurate the source data, the fewer assumptions in the estimate and the more predictable the preparation timelines.
- Catalog composition: how many items, whether trade offers exist, properties, multiple warehouses and suppliers — the loading scheme depends on this.
- Current errors: failure log, what already breaks during exchange, which operations employees do manually.
- Exchange requirements: which systems are involved — site, 1C, warehouse, order accounting — in which direction and at what frequency data moves.
- Installed modules and modifications: what is already installed from the 1C-Bitrix marketplace, which handlers and rules were customized for you.
- Access to the test environment: a copy of the production database and a separate environment where you can break things without affecting clients.
- Expected timelines and control points: by what date the result is needed, whether seasonal peaks exist, when sales cannot be stopped.
- Responsible persons on your side: who makes decisions on data composition and confirms acceptance.
Based on these inputs we describe the scope, fix the stages and return with an estimate and plan. In the plan we immediately include handover to support: exchange procedure, instructions for employees and the procedure for contacting us on failures after launch.
