Media Website Development on 1C-Bitrix
A news portal is one of the most demanding project types on 1C-Bitrix. Thousands of publications daily, millions of views during peak hours, dozens of editors working in parallel. Here there's no room for slow pages—readers leave competitors in 2 seconds. Bitrix handles this with proper architecture: composite caching, CDN, optimized info-blocks, and correctly configured editorial workflow.
Content Architecture
The foundation is info-blocks with thoughtful structure. The main "Publications" info-block contains all materials: news, articles, interviews, reports. Material type is a directory property, not a separate info-block, because the shared content stream must display on the homepage without combining multiple sources.
Categories—info-block sections (politics, economics, society, sports, culture, technology). Nesting is single-level—deep trees complicate navigation and dilute SEO.
Tags—multiple string property or binding to Highload-block tags. Highload-block is preferable: it normalizes tags (avoid duplicates like "COVID" / "Covid" / "covid-19"), stores SEO description for tag pages, and tracks popularity.
Special Projects—separate info-block with binding to publications via "Related Materials" property (multiple binding to main info-block elements). A special project has its own page template, logo, sponsor. A publication can belong to both a category and a special project—cross-linking without content duplication.
Authors—Highload-block with fields: full name, photo, position, bio, social media links. Binding to publication via property. Author page displays all their materials via news.list with author ID filtering.
Editorial Workflow—Control Without Chaos
In a media editorial office, 3–5 people work on one material: correspondent, editor, publishing manager, proofreader, photo editor. Bitrix lacks an editorial module level of WordPress Editorial Calendar, but workflow is built on info-block properties and user group rights.
Publication Statuses—"list" type property:
- Draft—created by correspondent, visible only to author and section editor
- On Review—editor works with text, makes corrections
- Proofreading—spelling check, fact-checking
- Ready for Publication—approved by publishing manager
- Published—visible on website
- Unpublished—archived, not indexed
Access Rights. We create groups: "Correspondents," "Section Editors," "Publishing Managers," "Proofreaders," "Editor-in-Chief." Via info-block rights:
- Correspondents: create elements, edit their own, change status to "On Review"
- Section Editors: edit all in their section, change status to "Ready for Publication"
- Publishing Managers: change status to "Published" for any section
- Editor-in-Chief: full access, including "Unpublished"
Notifications. Handler for OnAfterIBlockElementUpdate tracks status changes and sends notification to the next person in chain—via email or Telegram bot. On transition to "On Review"—notify section editor. At "Ready for Publication"—notify publishing manager. Scheduled publication via "Publication Date" property with date-based activity (ACTIVE_FROM).
Versioning. If edit history is needed—enable info-block business processes with change logging. Standard Bitrix mechanism stores element version history when "Business Processes" module is enabled.
RSS, AMP, Turbo Pages
RSS—rss.out component with element count settings (50–100 latest), full text or summary. Create separate RSS feeds for each category—for aggregators (Yandex.News, Google News) topic feeds are required.
Yandex Turbo Pages—formed via separate RSS channel in Turbo format. Template: XSLT transformation of standard RSS with turbo:content addition. Turbo analytics connected via Yandex.Metrica with separate counter.
AMP (Accelerated Mobile Pages)—requires separate template for each page type. In Bitrix, implemented via alternative site template, activated by URL condition (prefix /amp/). AMP template uses limited component set: amp-img, amp-video, amp-carousel. Forms via amp-form with endpoint to separate PHP handler.
Advertising Blocks
The advertising module in Bitrix enables creating ad containers with banner rotation, section-based targeting, and impression/click tracking. For major media this is insufficient—we connect Google Ad Manager (GAM) via gpt.js tag. Ad Manager containers placed in site template with lazy-loading (load ads after main content)—improves Core Web Vitals.
Native advertising—separate info-block section marked "Partner Content" (property "Sponsor" + visual marking in template, per Federal Law "On Advertising").
Performance Under High Load—Key Engineering Task
A news portal with millions of daily views is a completely different infrastructure level than a corporate site. Bitrix offers tools but they must be properly configured.
Composite Cache. Page is split into static part (HTML, cached to disk or memcached) and dynamic fragments (view counters, authorization block). Static part is served directly via nginx without PHP—reduces response time from 200–500 ms to 10–30 ms. Configuration:
- Admin panel: "Settings" → "Composite Site" → enable
- Exceptions: pages with POST forms, personal account, personalization pages
- Dynamic areas: via
$APPLICATION->IncludeComponent()with parameterCOMPOSITE_FRAME_MODE => "A"(AJAX loading)
CDN. Static (CSS, JS, images, video) served via CDN. In main module settings, specify CDN domain. For media from upload/ configure nginx rewrite to CDN origin. Cache TTL: 30 days for static, 1 hour for RSS.
Component-level Caching. For news lists CACHE_TIME = 300 seconds (5 minutes). For homepage—60 seconds. For archive—86400 (1 day). Tagged cache (cache_tag) is tied to info-block—when new publication added, list caches auto-clear.
Server Architecture. Minimal config for portal with 1M+ views/day:
- Nginx as reverse proxy + static file serving and composite cache
- PHP-FPM with worker pool (pm.max_children calculated by: available RAM / single process consumption)
-
MySQL/MariaDB—master-slave replication: writes to master, reads from replicas. Bitrix supports DB cluster via
clustermodule - Memcached or Redis—for sessions, component cache, tagged cache. Redis preferred—supports persistence and data structures
- Sphinx or Elasticsearch—for full-text search of publication archive. Standard Bitrix search fails with millions of records
Monitoring. Bitrix "Performance" module shows basic metrics. Additionally: Grafana + Prometheus for server metrics, Sentry for PHP/JS errors, custom dashboard with TTFB metrics per page.
Media Portal Development Stages
| Stage | Work | Timeframe |
|---|---|---|
| Analytics | Category structure, editorial workflow, load requirements | 2–3 weeks |
| Design | Publication grid, material templates, mobile version | 3–4 weeks |
| Frontend | Markup, AMP templates, ad containers | 4–5 weeks |
| Backend | Info-blocks, workflow, RSS/Turbo, Ad Manager integration | 4–6 weeks |
| Infrastructure | CDN, DB cluster, Redis, monitoring, load testing | 2–3 weeks |
| Content Migration | Archive import, old URL redirects | 2–4 weeks |
| Launch | Smooth transition, first-days monitoring | 1 week |
Total timeframe—from 20 weeks. Content migration often becomes the most unpredictable stage: legacy CMS may store data in non-standard formats, and old URL redirects are critical for preserving search traffic.