-
What is Bitrix Framework?
-
Production Architecture
-
Production Architecture
-
Structure of files
-
Access Rights
-
A Site in Terms of Bitrix Framework
-
-
Processing Techniques
-
Core D7
-
Modules
-
Name Spaces
-
Core Parameter Setup
-
Exceptions
-
Events
-
Code Writing Rules
-
Applications and Context
-
Errors
-
ORM
-
API
-
Highloadblock
-
-
Design Integration
-
Using Access Rights
-
Site Design Template
-
Using message files for localization
-
Editable areas
-
Navigation tools
-
Advertisement
-
Managing Template Service Data
-
Editing Service Areas
-
Managing Page Encoding
-
Managing Document Header
-
Managing Metadata Values
-
CSS management
-
-
Setup of External Appearance of Additional Elements of the Site Design
-
-
Information Blocks
-
Working with Infoblocks Using Standard Means
-
Infoblocks 2.0
-
Action Plan in Case of Problems
-
Sorting
-
Work with Infoblocks through API
-
Examples
-
-
Components
-
Simple and composite components
-
Location of a Component in the System and Its Connection
-
Component Structure
-
Composite Component Structure
-
Component Description
-
Component Parameters
-
Component Templates
-
Support of Component Classes
-
result_modifier.php
-
component_epilog.php
-
Operation of a Composite Component in a SEF Mode
-
Frequent Errors
-
Component Caching
-
Working with Components
-
Template Customization
-
Component Customization
-
Creating Components
-
Additional Methods
-
Redefinition of Incoming Variables
-
User-Defined Templating Engines
-
Operation of a Composite Component in SEF Mode
-
Ways of Data Transmission among Components
-
A Simple Example of a Component Creation
-
Component Creation Example
-
TinyMCE Visual Editor Integration Component
-
Caching in own components
-
-
CUSTOM Parameter Type
-
More examples
-
Errors When Working with Components
-
-
-
Modules
-
Programming in Bitrix Framework
-
Golden Rules
-
The file init.php
-
UTF-8 or a National Encoding?
-
Working with Databases
-
Setup of SEF for URLs
-
Language Files
-
JS Library
-
Interface of the Control Panel Toolbar as Seen by a Developer
-
Some Theory
-
Performance
-
Security
-
Examples, tricks, and advice
-
Custom Fields
-
Gadgets
-
Project Testing
-
Project Quality Control
-
Debugging Web Applications
-
-
Push and Pull module
-
Version Control System
-
-
Multiple Sites
-
Introduction
-
Use of Multiple Site Version
-
How many sites can I create?
-
Language versions (mirrors)
-
Sharing visitors between sites
-
Configuring the multisite system
-
Working with the Data in a Multiple Site Configuration
-
Frequent Questions Arising When Working with a Multiple Site Configuration
-
-
Business Processes for Developer
-
Template of a Business Process
-
Business Process
-
Activities
-
Executing a business process activity using API
-
Arbitrary PHP Code in a Business Process
-
-
Additional Information and Examples
Configuring the multisite system
Technically speaking, a multisite version of the product can be implemented in two configuration modes:
- Multiple site in one domain. (Old name: First Option Multiple Site.) The product and all sites work under the management of one copy of the Apache web server.
- Multiple site in different domains. (Old name: Second Option Multiple Site.) Each site works under the management of a separate copy of the Apache web server or a separate virtual web server.
From the point of view of the software product, both options are equal. The choice of either of the multiple site option depends on the goals set by the developer.
The multiple site in one domain is recommended:
- If you need to create sites in different languages or, for example, the regional sites of the same company;
- If a common domain name is planned to be used for both sites;
- If you use virtual hosting which does not permit creating several virtual web servers with a shared access to files.
In this case, URLs will be represented as:
http://example.com/s1 (http://example1.com/s1)
http://example.com/s2 (http://example.com/s)
or as:
http://example.com/ (http://example1.com/)
http://example.com/s2 (http://example.com/s2)
The multiple site in different domains is recommended:
- If the sites to be created have different subject-matter or if sites with unique URLs are to be created;
- If you use the allocated server or can set up separate web servers on a shared hosting.
The use of multiple site in different domains also permits to exclude from site URLs spare subcatalogs /s1/ or /s2/ and start forming URL addresses directly from the catalog "/". I.e. site addresses will look as follows:
http://www.example.com/
http://www.example.de/
http://www.second.example.com
The software product installation package is delivered with a configuration for multiple sites in one domain. Additional setup is needed in order to use multiple sites in different domains.
Both configurations will be reviewed using the example of the creation of a multiple site system consisting of two sites:
- www.site1.com - company’s corporate website
- www.site2.com - company’s E-store