Composite Bitrix component: where the logic breaks
A composite component is a bundle of a list and a detail page, where routing, cache, and access permissions depend on each other.
An error in one layer breaks the others: an incorrect SEF rule turns detail URLs into duplicates, an aggressive cache serves a page under the administrator to a guest, and poorly designed permissions expose other sections via a direct URL. Let's break down how this is closed during the development of a composite Bitrix component.
The most common breakdown is routing. The URL template is assembled from the symbolic code and sections, but nesting and code changes during editing are not taken into account: old URLs stop opening, the search engine sees duplicates, and redirects are not configured.
Bitrix SEF requires explicit rules for rebuilding and handling 404 — otherwise the detail page serves content at any URL.
The second source of failures is caching. A composite component caches both the list and the detail, as well as the shared template; with incorrect keys, the cache is not cleared when an element is added or is cleared entirely on every action.
The result is either stale data or a drop in response under load. This is treated by separating the cache by section and tying the reset to infoblock events.
The third layer is access permissions. Checking permissions only at the list level leaves detail pages open: a user lands via a direct link where they should not be able to see.
Permissions must be checked in every mode of the component and at the section level, not for the page as a whole.
These three layers are connected: the SEF rule affects the cache key, and permissions affect what even gets into the cache. That is why a composite component is designed as a whole, rather than patched piece by piece.
What correct development of a composite component delivers
A composite component in 1C-Bitrix is the point where three things converge that most often break in custom-built solutions: page addresses, cache, and access permissions.
When they are designed together rather than "patched in later," the system's behavior becomes predictable: SEF rules are described declaratively and do not depend on the order of parameters in the query string, the cache is invalidated by specific tags, and the permission check sits at the entry point of the component rather than in the template.
The practical effect is visible in the metrics. Stable SEF URLs eliminate duplicate pages and "jumping" addresses when filters change — the share of correctly indexed sections grows, and redirects stop being manual work.
Managed caching reduces catalog page response time from seconds to tens of milliseconds on a warm cache and relieves the load on the database during peak traffic.
Access separation closes an entire class of failures: a user without the role does not receive data through a direct method call, even if the template rendered incorrectly.
This is not a "cosmetic" check in the markup, but a filter at the level of the selection and the cache — and that is precisely why it cannot be bypassed by substituting query parameters.
The SEF mode and handling of composite addresses deserve separate mention: when the rules are stored in the component's configuration rather than smeared across handlers, adding a new section requires no edits in multiple places.
The mistakes of typical solutions — "cache everything," permissions only in the interface, addresses that depend on the session — are eliminated at the design stage rather than after launch.
The result is a reduction in the class of failures that cost the most: lost search rankings, load spikes, and data leaks. Next, we break down what this looks like across the stages of work.
Operating modes: simple component, composite component, custom template
The choice between a simple and a composite component is not about "more complex/simpler", but about where the routing logic lives and how it coexists with the cache. A simple component solves one task: output a list, a detail page, or a form.
A composite component takes on the "list + detail + sections" bundle and parses the address itself according to SEF rules, connecting the appropriate template for each mode.
A component template is the presentation layer: it configures SEF URLs, pagination, selection fields, and extension points.
If you distribute the logic across templates correctly, a single composite component covers an entire catalog or blog section, instead of turning into a set of copies.
| Option | When it fits | Limitations |
|---|---|---|
| Simple component | One page: list output, card, form | SEF URLs and sections are assembled manually, logic is duplicated across pages |
| Composite component | A section with hierarchy: catalog, blog, services | Requires careful cache and permission configuration, otherwise pages "stick" |
| Custom component template | Non-standard markup and custom output points are needed | More code in the template, higher risk of dragging business logic into it |
Caching is the main dividing line. A composite component has separate caches for the list and the detail page, so it is important to set the keys correctly: selection parameters, page number, user group.
Otherwise, after editing a single card the entire section is reset, and with incorrect keys a visitor sees someone else's cache.
Access permissions are checked at the component and template level: a guest, an authorized user, and an administrator may receive different selections and different markup. If this is not taken into account, the cache will serve a guest data intended for another group.
That is why the cache is tied to the user group, and the permission check happens before the selection, not after.
Implementation stages: from audit to handover
We start with an audit: we look at which components are already in use, where data-fetching logic is duplicated, how the templates are structured, and what actually ends up in the cache.
At this step we identify the bottlenecks — most often these are queries in a loop, the lack of separation by sections, and a cache that is reset on any change in the information block.
- Component audit. We analyze the current implementation: the call tree, data sources, caching settings, behavior under load. The output is a problem map with priorities: what breaks performance, what hinders further development.
- Schema design. We define the structure of the composite component: which branches (list, detail, sections) it covers, how parameters are laid out, where the boundary lies between logic and template. We agree on the schema before writing code — edits on paper are cheaper than edits in production.
- Implementation and cache configuration. We build the component with managed caching: separate cache per branch and parameters, tag-based invalidation when specific elements change rather than the entire section. This removes the main cause of "the site slows down after every content edit."
- Access rights verification. We test role-based scenarios: guest, authorized user, editor, administrator. We separately verify that the cache does not serve data unavailable to the current role — this is a typical leak when configuration is careless.
- Testing and measurements. We run load scenarios before and after, compare response time and the number of database queries. We record the result in numbers so that the effect is measurable rather than "it got faster."
- Documentation handover. We provide a description of the component schema, parameters, caching logic, and rights, along with instructions for typical changes. Your team can develop the component further without us — this is part of the result, not an option.
Each stage ends with an artifact: an audit map, an agreed schema, a working component, a measurement report, documentation. Describe your task — we will come back with an estimate and a plan based on these steps.
What the client receives: configurations and regulations
A complex component without documentation turns into a "black box": six months later, no one remembers why the cache is invalidated by that particular tag, or why permissions for a section are granted one way and not another.
That is why we deliver not only the code but also a complete set of artifacts that allow the component to be developed further and handed over to another team.
- Component configuration — the
.parameters.phpfile describing all input parameters, default values, and valid ranges. We separately document SEF modes and URL-building rules so that routes do not "drift" when the template is changed. - Caching scheme — which tags and lifetimes are set for the list and detail pages, and what resets the cache when an item is added or edited. The scheme is presented as a table: event → invalidated tag → affected pages.
- Access policies — a "role → action → access level" matrix by sections and information blocks, tied to user groups and component-level settings. It shows who reads, who edits, and who publishes.
- SEF routing scheme — the "URL → template → component parameters" mapping, including handling of non-existent addresses and redirects.
- Template map — which component template is responsible for what, which blocks are moved into include areas, and where the extension points for custom logic are.
- Update regulations — the procedure for editing parameters, the rules for resetting the cache after deployment, and a checklist for verification after changes in information blocks.
- Content manager instructions — how to add sections and items without breaking the URL structure and without resetting unnecessary cache.
- Decision log — why these particular cache and permission settings were chosen, which alternatives were rejected, and for what reason.
We hand over the set in the repository alongside the code, not as a separate archive — that way, on the next iteration, the engineer opens the scheme and sees the logic as a whole, without archaeology through the source code.
Case study: how a composite component eliminated a class of failures
The client is a retail chain with a catalog of several tens of thousands of items with property filters.
Before us, the catalog page was built by a monolithic component: every request re-pulled the list of sections, products, and SKUs, and the cache was reset on any change in the information block.
A content manager's edits brought down the cache of the entire section — under load, this caused regular failures.
We rewrote the output as a composite component with separated logic: the list and the detail card got their own cacheable branches, and cache reset was tied to a specific element rather than to the entire section.
Access rights were moved into a separate layer — the user group check runs before data retrieval, so restricted sections never make it into either the cache or the output.
We worked with 1C-Bitrix through standard mechanisms — without core modifications, so that platform updates would not break the logic.
| Metric | Before | After |
|---|---|---|
| Catalog page build time | 2.4 s | 0.4 s |
| Recovery time after a failure | 40 min | 5 min |
| Share of requests with errors | 3.1% | 0.2% |
The figures were captured on production traffic over two weeks before and after implementation.
Build time dropped due to caching of queries and eliminating repeated requests to SKUs; recovery sped up because a failure is now localized to a single component branch and does not require a full catalog reload. The error share decreased because rights checks and filters run before hitting the database.
We also recorded the behavior under peak load: during a sale, when the number of concurrent visitors tripled, the catalog page stayed within the same response time. Previously, at such moments the cache was rebuilt on every request and the server went into overload.
How does a composite component differ from a regular one?
A regular component is a single call in a template: it received data, rendered it, and returned the page.
A composite component is structured like a mini-application inside a page: it has a list, a detail page, an add mode and an edit mode, and each mode is a separate branch of logic with its own set of data.
That is why in code it operates not with a single request but with routing: which mode is active, which item is requested, what to show when an item is missing.
Hence the main difference at the architecture level — a composite component manages the URL structure itself rather than relying on physical files.
SERP-friendly URLs are a direct consequence of this architecture. A composite component reads the address, parses it into a mode and an identifier, and substitutes the required template without creating a separate file for each entity.
A rewrite rule in the component settings links the human-readable address to the selection parameters, and adding a new entity requires no changes to the site structure.
A regular component has no such routing: the address is set by the page, and filtering goes into the request parameters.
Their caching is also of a different class. A regular component is cached entirely per page, and any data change invalidates the whole block.
A composite component caches by mode and, separately, the selections within a mode, so updating a single item does not rebuild the entire list.
When managed cache is enabled, invalidation is tied to tags: editing an entity resets only the branches associated with it, not the whole page. On a catalog with frequent changes, this is the difference between rebuilding the entire section and a targeted update.
A composite component checks access permissions on entry into each mode, not once per page. This makes it possible to serve a guest only the list and the detail page, while closing editing behind a check before data loading — unnecessary selections are not executed at all.
A regular component usually has a single check for the entire output, and separating operations within it is more difficult. That is exactly why a composite component is chosen where SERP-friendly URLs, targeted cache, and different permissions for different actions are needed.
Common technical concerns about the component
A complex component almost always attracts the same questions — about caching, permissions, and human-readable URLs. Below we address them substantively, without generalities.
Will the cache serve stale data after edits?
The component caches not "everything indiscriminately" but the result of its work taking into account the key: call parameters, user groups, language, section.
Editing content through the administrative panel automatically invalidates the related cache, and for external sources we hook cache invalidation to data change events.
If content is updated on a schedule, we add tagged cache with a limited lifetime — the visitor sees the current version, not a "snapshot" from a week ago.
Will access permissions break when separating by roles?
Permissions are checked at the component level and at the data query level, not just in the template. This means a hidden section cannot be opened by a direct request — the server will return a denial, even if the link is known.
For guests, authenticated users, and employees we configure separate logic branches so that each group sees exactly its own set of data.
Will SEO-friendly URLs have to be redone after launch?
We design URLs with routing rules from the start, rather than "bolting them on" later. The component outputs human-readable links at the development stage, so when new sections are added the structure doesn't break and old URLs continue to work. When migrating from another system, we configure redirects so that search traffic doesn't drop.
Will platform updates break the component?
We don't modify the core and don't rely on deprecated calls — the logic lives in its own component with clear extension points. Updates are applied on a test environment, run through key scenarios, and only then go to production. If an update changes behavior, we have a rollback plan.
These four topics cover most concerns even before the start. If questions remain about your configuration — we'll address them during the assessment stage.
Let's discuss the task: we'll come back with an estimate and a plan
To make the estimate accurate rather than a rough guess, we need at least some context from you: which component we're touching — custom or standard, what its current SEF rules are, how caching is configured, and which user groups see what.
From these inputs we understand the scope: enhancing an existing complex component is usually cheaper and faster than rewriting from scratch, but only if the template and cache architecture allows it.
Describe the task — we'll come back with an estimate and a work plan. In response you'll get:
- an analysis of the current component: where SEF breaks, what gets cached unnecessarily, which access permission checks are bypassed;
- a phased work plan — from designing the URL structure and cache modes to template output and tests;
- an access permission scheme: which groups see which data and at what level this is checked;
- implementation options with honest limitations of each — no "we'll do everything at once";
- the scope of migration work if the component replaces an existing section;
- a list of what's needed on your side: access credentials, a test environment, example URLs;
- timelines by phase and the points where you accept the result.
If the task isn't fully formulated yet — that's fine. Describe in your own words what should work and what's getting in the way right now: we'll ask clarifying questions about SEF, caching, and permissions and come back with an estimate.