Museum Portal Development on 1С-Битрикс

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Showing 1 of 1All 1626 services
Museum Portal Development on 1С-Битрикс
Complex
from 1 week to 3 months
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    943
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    829
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1074

Museum Portal Development on 1С-Битрикс

A museum website is not just a showcase. It's a ticket office, a collection catalog, virtual tours, and an access point for people with disabilities. We specialize in the 1С-Битрикс platform, which allows combining all these functions in one project. Over the years, we have implemented more than 15 museum projects—from art galleries to historical complexes. And we know how to avoid typical mistakes that lead to ticket overselling or slow image loading. We will evaluate your project in 1 day—just contact us.

How 1С-Битрикс Solves Museum Website Tasks?

The platform provides the iblock module for fund cataloging and sale module for ticket sales. Customizations for museum specifics do not require rewriting the core—everything is solved through infoblocks v2.0 and properties. The system's flexibility allows implementing both a simple event poster and a complex virtual tour with audio guides.

Catalog of Collections and Exhibitions

A collection fund may include thousands of storage units. The structure of the Collections infoblock is designed with museum standards in mind:

  • PROPERTY_INVENTORY_NUM — inventory number
  • PROPERTY_AUTHOR — author (linked to the Persons infoblock)
  • PROPERTY_DATING — dating (string: "15th century", "1890s")
  • PROPERTY_TECHNIQUE — technique/material (multiple reference)
  • PROPERTY_DIMENSIONS — dimensions (string: "120×80 cm, canvas")
  • PROPERTY_COLLECTION — belonging to a collection (link)
  • PROPERTY_HALL — exhibition hall (linked to the Halls infoblock)
  • PROPERTY_HI_RES_PHOTO — high-resolution photo (file)
  • PROPERTY_AUDIO_GUIDE — audio description (MP3 file)

For photos, the image processing module is configured: upon upload, four variants are generated—a 300px thumbnail for the list, 800px medium for the card, 2000px large for zoom, and a watermarked version for protection. The watermark is applied via the OnFileSave handler. Search across the collection is implemented through search with faceted filters: by era, technique, author, hall. For full-text search, Elasticsearch is connected via a custom SearchProvider—Bitrix's built-in search cannot handle the volume of museum descriptions. For synchronization with the museum accounting system, the CommerceML standard is used.

Why Virtual Tours Increase Attendance?

Virtual tours boost engagement by 2 times compared to ordinary photos. We implement 360° panoramas of halls with hotspots. Libraries Pannellum (open source) or Marzipano are used. Panoramas are stored in the VirtualTours infoblock with properties: panorama file, JSON hotspots, linked panoramas, audio track. Hotspots are of three types:

  • info — opens the exhibit card
  • scene — transitions to another hall
  • audio — starts the audio guide

Editing hotspots is implemented through a custom admin interface: the manager clicks on a spot and fills in properties. Audio guides are uploaded in MP3 with automatic conversion to AAC via FFmpeg. For detailed examination of exhibits, OpenSeadragon with Deep Zoom technology is connected: the original photo (50–100 MP) is cut into tiles using the vips dzsave utility. Tiles are stored on a separate domain cdn.museum-site.ru or an S3-compatible storage.

How to Avoid Ticket Overselling?

The sale module is adapted for ticketing specifics. A ticket is a product with properties:

Product Property Purpose
Ticket Type Adult / Child / Discount / Family
Exposition Permanent / Temporary exhibition
Session Date + time slot
Limit Maximum visitors per session

The visitor limit is a critical function. On each sale, the OnSaleOrderAdd handler reduces the counter of available seats for the session. When the remainder reaches zero, the slot is hidden. The counter is stored in a high-load infoblock SessionSlots—this avoids concurrency issues. For atomicity, UPDATE ... SET count = count - 1 WHERE count > 0 is used. Discount categories are configured through cart rules; the buyer uploads a scanned document (order property type "File"). A manager verifies the document before confirmation. Savings on printing and distributing paper tickets amount to up to 200,000 rubles per year.

Event Poster

The Events infoblock contains lectures, master classes, concerts, museum nights. The output on the main page uses the bitrix:news.list component with the filter >=DATE_ACTIVE_FROM and sorting by date. Past events are automatically archived but remain accessible via direct links for SEO. An iCal file (.ics) is generated for the poster, which can be added to a calendar.

Accessibility (WCAG 2.1) and SEO

Museums as state institutions are required to ensure website accessibility. We implement WCAG 2.1 level AA: text contrast at least 4.5:1, keyboard navigation, mandatory alt attribute for exhibits (checked in OnBeforeIBlockElementUpdate), high-contrast mode (toggle in the header), text scaling via rem. For videos, a mandatory <track kind="captions"> is included.

For SEO, Schema.org markup of type Museum with nested objects ExhibitionEvent, Event, CreativeWork, Offer is used. The markup is generated automatically through a JsonLd component that collects data from infoblocks. The markup template is configured in the admin section—a marketer can add fields without developer involvement. This gives an increase in organic traffic of up to 30% according to our projects' data. Our many years of experience guarantee high quality and compliance with standards.

What is Included in the Work

  • Planning: structure prototype, functionality approval, technical specification.
  • Design: responsive interface, WCAG templates, low-vision version.
  • Development: backend on 1С-Битрикс, integrations with payment systems and cash registers, CDN setup.
  • Content loading: import from Excel/1С, image upload, audio guides, virtual tour setup.
  • Testing: ticket scenario verification, load testing (up to 500 concurrent users), accessibility audit.
  • Support: manager training, access transfer, documentation, 30 days of support after launch.

Development Timeline by Stage

Stage Duration
Planning 1–2 weeks
Design 2–4 weeks
Development 4–8 weeks
Content loading 1–2 weeks
Testing 1 week
Total 4–12 weeks

Common Mistakes in Museum Website Development

  • Storing large images without CDN—slows loading by 3 times.
  • Lack of atomicity in ticket sales—risk of overselling.
  • Ignoring WCAG—fines up to 2% of the budget for state institutions.

Cost and Timelines

Development timelines range from 4 to 12 weeks depending on complexity. Implementing a ticketing system increases ticket sales revenue by 30% through dynamic pricing. The cost is calculated individually after an audit of your requirements. We will evaluate your project in 1 day—get a commercial proposal with a detailed estimate. Get a consultation on your project—we'll tell you how to migrate from an outdated system or refine an existing site. Contact us for a detailed discussion.

How to properly design infoblocks?

When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.

Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.

Why 1C-Bitrix outperforms most CMS for business

The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.

What highload blocks are and how they speed up the catalog

Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.

From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.

What integrations are critical for 1C-Bitrix stores

Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.

What's included in 1C-Bitrix website development

Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.

  • Technical specification – user stories, infoblock diagrams, integration schemas.
  • Source code in Git – with commit history, release tags, branching rules.
  • Administrative documentation – description of custom components, deployment instructions, list of agents and events.
  • Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
  • Access to staging during development – test before production deployment.
  • Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).

Our process and technologies

Project type Timeline Complexity Key features
Corporate website from 1 month Medium Catalog, news, forms, CRM integration
Online store from 2 months High 54-FZ, marketplaces, 1C exchange, SKU
B2B portal from 3 months Very high Personal prices, document flow, Bizproc
Landing page from 2 weeks Low LCP < 2s, composite cache, static
Multisite structure from 1.5 months High Separate content, shared catalog, hreflang

Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.

Process:

  1. Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
  2. Design – UI/UX with design system. Components are reusable.
  3. Development – write components with custom templates in local/templates/. Business logic in local/modules/.
  4. Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
  5. Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.

Multilingual support and redesign

Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.

Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.

Guarantee and support

We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.