Structure of files

Files and Database

Bitrix Framework is based on files, and it gives more freedom to a site developer. Since a file in the system is just an executable file, it can execute anything, be it a programmer’s own PHP code or standard components, in any order. Curiously enough, such complete freedom may confuse a beginning developer, but things will get better as the developer gets more experience.

Note: execution of PHP is a great advantage of a static page of Bitrix Framework.

Files can be amended both in FTP and SSH with no need for additional tools of the database management system. They can be easily copied, moved, backed up, etc. Strictly speaking, you can store all the content in the database. But for simple static sites it will mean a clear complication and slowdown.

File implementation seems problematic because such a system is expected to have tens of thousands of files on the disk. Normally that is not so. Dynamic information (news, catalog of goods, and articles) are stored in database by the module of Information blocks. Then for the display, for example, of 10,000 goods in the Internet store, the one and only physical page (file) is used. In this file, a component of infoblocks is retrieved that, in its turn, selects and displays goods from the database.

E.g., for a catalog of goods a folder indeed must be created on the disk, but it will be the only folder, e.g., /catalog/. Then a complex component must be put there, and further on the pages of goods may look like, for example: http://***.com/catalog/1029.html. Obviously, these addresses will be “artificial” and subject to processing by the system. No files need to be created in the folder /catalog/ for them.

However, for each item of goods, a file will be created in cache so that the server will not have to make requests to the database in case of a subsequent visit of the customer.

With proper skill, the public part may consist of a dozen of physical files. All content may be presented in infoblocks, including the menu. But normally it is more convenient to edit static pages (e.g., About the company) as a file and not as a database entry. But if there are too many such static pages it may be a good idea to structure them and store them in infoblocks rather than on the disk.

The system size is rather large since its composition includes numerous components that are necessary for the quick start and operation of the administrative part. Components are not consolidated because the system is modular. Modules, components, and templates have a certain structure. It is important both for system updates and the development of own components.

A large number of files is characteristic of similar systems. (ZendFramework has the same particularity.) If hosting is configured properly, this problem will be solved by php precompilators. The amount of place allocated by the host and big number of system files are of critical importance.

Summary. File system instead of database is chosen as a tool for storing the site structure due to the following reasons:

A file gives more freedom to the site developer because file in the system is just an executable file.
It is easier to manage. This representation is based on a structure of static HTML pages located in different folders. By making certain improvements (implementing a small amount of PHP code) to such a site we can have a project working on Bitrix Framework in no time.
To a certain extent it is a tradition that was of a great importance at the initial stage of CMS development.
Such representation is consistent with the experience of content managers who work with local file systems (folders and files).

Site structure may also be organized in the database (infoblocks) but management of hierarchy in relational database is not very convenient.

Let us consider the use of files in Bitrix Framework in these examples:

File system and menu. The menu in files permits you to not connect the database where it is not really needed. The same applies to the properties of pages and sections and also file access rights. Theoretically, it is possible to build up an informational site with no requests to the database at all. Such a site will work faster, especially on shared hosting. There are also some advantages: when copying a section, the menu, access rights, and section properties are also automatically copied.
File system and users. Users from the administrative section have access to core files and other program files. But users are different. E.g., Bitrix, Inc. technical support. If a web developer is not sure of their users, such a web developer can always prohibit users editing both PHP code and entire sections (cores). According to the modern concept of Bitrix Framework, the public part shall have no PHP code, everything must be encapsulated in components. In this case, a user edits either bare static page or sets up a component.
File system and language versions. It would be difficult to support language information in a database. Since information in language files changes very rarely, it is easier to edit a line in a language file than to store these static phrases in the base. And, once again, the database is slow and excessive.

File Structure

The file structure of Bitrix Framework is organized in such a way so that the program components of the product core are separated from users’ files and also from the files determining external representation of the site. This particularity makes it possible to:

Avoid undesirable modification of the product core when working with system files.
Rule out the possibility of change of the public part of the site during downloads of product updates.
Set up external view of the site according to virtually any kind of task.

The system in its entirety is located in the catalog /bitrix/ that contains the following subcatalogs and files:

/admin/ - administrative scripts;
/cache/ - cache files;
/activities/ - action folders for business processes;
/components/ - a folder for system and user’s components;
/gadgets/ - gadget folders;
/js/ - JavaScript files of modules;
/stack_cache/ - stack cache files;
/themes/ - themes of the administrative section;
/wizards/ - folders of wizards;
/images/ -images used both by the system in general and by separate modules;
/managed_cache/ - managed cache;
/modules/ - catalog with system modules where each subcatalog has its own strictly determined structure
/php_interface/ - auxiliary service catalog containing the following catalogue and files:
- dbconn.php - database connection parameters;
- init.php - additional portal parameters;
- after_connect.php - is connected immediately after database connection was established;
- dbconn_error.php - is connected in case of an error when database connection is being created;
- dbquery_error.php - is connected in case of an error during the execution of an SQL query;
- /site_ID/init.php - additional parameters of a site; the file is connected immediately after a special constant with the site identifier (SITE_ID) was determined;
/templates/ - a catalog with site and component templates, consists of the following subcatalogs:
- /.default/ - a subcatalog with general files used by any given template by default; the structure of this catalog is similar to the structure of the catalog containing a specific template;
- /site template ID/ - a subcatalog with site template containing the following subcatalogs and files:
  - /components/ - catalogue with customized component templates;
  - /lang/ - language files belonging both to this template in general and to separate components;
  - /images/ - catalog with images of this template;
  - /page_templates/ - catalog with templates of pages and their description stored in the file .content.php. When a user creates new page, they can choose a template from this catalog;
  - header.php - prologue for this template;
  - footer.php - epilogue for this template;
  - styles.css - CSS styles of a template;
/tools/ - during installation additional pages are copied to this catalog; these pages can be directly used on any pages of the site: help, calendar, image view, etc.;
/updates/ - a catalog automatically created by the update system;
header.php - a standard file connecting, in its turn, a specific prologue of the current site template; this file must be used on all pages of the public part;
footer.php - a standard file connecting, in its turn, a specific epilogue of the current site template; this file must be used on all pages of the public part;
license_key.php - a file containing a license key;
spread.php - a file used by the main module to transfer visitor’s cookies to additional domains of different sites;
redirect.php - a file used by the Statistics module to record link click events;
rk.php - a file used by the Advertising module by default to record banner click events;
stop_redirect.php - a file used by the Statistics module to issue any message to the visitor who is on the stop list;
activity_limit.php - a file used by the Statistics module to issue a message to the bot in case the bot exceeds the activity limit.

Depending on the version used some catalogs and files may be unavailable.