1с битрикс добавить сайт

Обновлено: 06.07.2024

Форма создания/редактирования сайта предназначена для настройки параметров существующего или вновь создаваемого сайта системы.

Контекстная панель

Кнопка	Описание
Список сайтов	Переход на страницу со списком сайтов.
Добавить сайт	Переход к форме создания нового сайта.

Закладка Параметры

Поле	Описание
*ID	Указывается идентификатор сайта в системе. Идентификатор состоит из двух букв латинского алфавита. Например, ru, en.
Активен	При отмеченной опции сайт будет активен. Если сайт неактивен, то он недоступен.
*Название	Указывается произвольное название сайта.
Параметры для определения сайта в публичном разделе
По умолчанию	При отмеченной опции сайт будет загружаться по умолчанию.
Доменное имя	Задается доменное имя или список доменных имен (каждое с новой строки) сайта. С 11-ой версии поддерживается кириллические домены. Уровень домена может быть любым.

Заполнять поле рекомендуется только для организации многосайтовости на одном ядре.

Если в системе второй сайт работает на поддомене Пример:

В противном случае (или при равенстве значений в поле Сортировка) система будет открывать первый сайт при обращении ко второму.

Для случаев, когда сайты находятся на разных доменах Пример разных доменов:

Примечание: для того чтобы выбранный шаблон дизайна применялся к страницам сайта по умолчанию, это поле нужно оставить пустым.

Для папки или файла - страница или раздел, при отображении страниц которого будет использоваться данный шаблон;
Для групп пользователей - группы пользователей, для которых страницы сайта будут отображаться с использованием данного шаблона;
Период времени - дата или период времени, в течение которого страницы сайта будут отображаться с использованием данного шаблона;
Параметр в URL - параметр в URL страницы, при наличии которого к странице будет применен данный шаблон;
Выражение PHP - произвольное условие на языке PHP.

* - поля, обязательные для заполнения.

Пользовательские комментарии

Мы будем рады, если разработчики добавят свои комментарии по практическому использованию методов системы.

Для этого нужно всего лишь авторизоваться на сайте

Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.

Также Пользовательские комментарии не являются местом для обсуждения функционала. По подобным вопросам обращайтесь на форумы.

Очень много информации на нашем сайте по настройке многосайтовости, но эта тема почему-то всегда вызывает много вопросов. Хотя на мой взгляд здесь всё довольно просто.
Ну начнём с того, что на одной установке Битрикса можно сделать много сайтов (без покупки дополнительных лицензий можно сделать два сайта), а значит закроем первый вопрос: для настройки многосайтовости надо установить Битрикс только один раз .
Есть довольно подробный учебный курс , где описывается два способа настройки многосайтовости.

[spoiler]
Какой способ выбрать?

Теперь несколько слов о том, как система определяет текущий сайт.
Откроем настройки сайта (Настройки - Настройки продукта - Сайты - Список сайтов):

Многосайтовость по второму способу (мини HOWTO)

Они имеют разные корневые папки (т.е. при обращении к каждому из них открываются файлы из разных физических папок на сервере). Существует вариант, когда при обращении к любому домену открывается одна и та же папка на сервере (ниже рассмотрим такой вариант), но именно первый вариант является предпочтительным.

2. Теперь необходимо заставить работать ту же копию на втором домене.
Считаем, что публичная часть у сайтов разная (иначе зачем нужны разные сайты?), поэтому для второго сайта потребуется только ядро продукта (папка bitrix , ну и upload ). Теоретически, если их просто скопировать из первого сайта, то будет работать, но нас это не устроит (приходилось сталкиваться с такой "многосайтовостью").
Получим две копии ядра, которые работают с одной базой данных, после обновления одного из них обновится база данных, и второй сайт перестанет работать (ну и кроме того, копирование ядра противоречит лицензии).
Проблема решается использованием символических ссылок . Если говорить образно, ссылка выполняет задачу ярлыка на рабочем столе, который открывает программу, но сам программой не является.
Руководство по многосайтовости рекомендует выносить ядро в общую папку shared , затем делать символические ссылки в каждом сайте. Здесь для простоты изложения я упрощу этот шаг и сделаю ссылку с одного сайта на другой (с функциональной точки зрения разницы нет).
Набросал небольшой скрипт, который поможет создать символические ссылки при использовании только ftp доступа к серверу:

нет прав на запись в текущую папку;
действует ограничение безопасности (open_basedir), которое не позволяет пользователям разделяемого хостинга обращаться к другим сайтам.

Теперь надо скопировать с первого сайта .access.php (чтобы был доступ на чтение корневого раздела, при необходимости можно вручную отредактировать его, удалив всё кроме $PERM["/"]["*"]="R"; ) и index.php (который потом будет редактироваться).

3. Настройка сайтов.

4. Проверка публичной части.

Если всё было сделано правильно, сейчас на разных доменах должны открываться разные сайты. Для этого воспользуемся простейшим скриптом:

Всё. Задача решена.

А если общая корневая папка?

Это не удобно в первую очередь потому что публичная часть сайтов будет общая . Но если другого варианта нет, можно настроить многосайтовость и здесь. Только для разделения публичной части в корне сайта придётся создать папки для каждого сайта и фактически получится многосайтовость по первому способу .

1. Ставим продукт в любом домене один раз .

2. Для разделения публичной части создаём в папке /var/www/denis/example папки com и net . Здесь ядро имеет путь /var/www/denis/example/bitrix для обоих сайтов, и символические ссылки создавать не требуется.

3. В настройках сайтов теперь помимо домена нужно указать папку сайта: /com и /net для первого и второго сайта.

4. Создаём индексную страницу сайта по примеру из учебного курса. Эта страница по домену будет определять текущий сайт и подключать соответствующую публичную часть. Только для этого надо было указать домены в настройках сайтов. Привожу здесь код скрипта:

Много поддоменов на одном сайте

2. Создаём символьные ссылки как описано выше для многосайтовости по второму способу, но никакую дополнительную настройку Битрикса (как указание доменов в настройке сайта) делать не требуется.

3. Создаём индексную страницу в папке /var/www/denis/blogs , размещаем на ней компонент bitrix:blog.blog . Обратите внимание, это не комплексный компонент блогов, а компонент, отображающий содержимое конкретного блога.

4. На этой же странице перед подключением компонента вставляем код, который будет определять текущий идентификатор блога на примере следующего:

Далее в параметрах компонента в качестве идентификатора блога указываем переменную $BLOG_ID . Всё должно работать.

Получилось много текста, в действительности действий то совсем не много. Попытался осветить основные вопросы, которые возникают у клиентов по вопросам многосайтовости при обращении в техподдержку. Надеюсь, изложение поможет чуть лучше понять вопрос и решать проблемы используя эти знания.

Чтобы развернуть и настроить первый сайт на сервере с виртуальным окружением Битрикс, достаточно перейти по IP-адресу в браузере и ответить на несколько вопросов установщика:

Чтобы добавить дополнительные продукты Битрикс (CRM, корпоративный портал, управление сайтом), уже необходим ssh-доступ (по паролю root, который есть в инструкции к серверу).

При первом подключении по SSH необходимо задать пароль служебного пользователя Bitrix:

После подключения к серверу запускается скрипт настройки Битрикс окружения menu.sh — через него можно добавить/удалить дополнительные сайты, а также настроить параметры почты, Mysql, memcached, Sphinx.

Сначала вам будет предложено создать пул сервера:

Укажите имя пула в пункте 1. Create Management pool . По умолчанию выбирается hostname сервера.

Это можно сделать и после настройки первого сайта, его данные не будут изменены.

Для создания второго сайта необходимо выбрать пункты:

Где ввести доменное имя, под которым будет располагаться сайт. Затем название сайта — будут созданы соответствующие конфиги и директории.

После чего будет предложено выбрать тип сайта:

Если нужен дополнительный сайт в рамках многосайтовости (с общим ядром и базой данных уже имеющегося сайта), то необходимо настроить ext_kernel и link .

Выбираем второй пункт (kernel) — в этом случае, предусмотрена собственная база данных, файлы, сайт доступен извне. Уточним, что для каждого сайта необходима отдельная лицензия Битрикс.

Далее будет запрошена кодировка (по умолчанию UTF-8), выполнение агентов на хитах, или cron.

Следующим пунктом надо указать название новой базы данных и корневую директорию сайта.

Можно эти моменты уточнить либо оставить вариант по умолчанию — тогда директория нового сайта будет располагаться в каталоге /home/bitrix/ext_www/ , а база данных будет названа по имени домена.

После завершения текущей операции, список сайтов будет доступен в пуле:

На этом настройка дополнительного сайта завершена. Если такое доменное имя существует и направлено на сервер, при переходе по нему в браузере появится окно установки Битрикс:

С помощью него вы можете развернуть сайт из архива, расположенного на сервере, или удалённо. Либо же установить чистые дистрибутивы продуктов Битрикс.

Настройка любой площадки для CMS — это рутинный процесс, который должен быть доведен до автоматизма в каждой уважающей себя компании. А потому частенько воспринимается, как восход солнца — это происходит само собой. На самом деле, нельзя так относиться и надеяться на разработчиков, особенно если часть команды работает на субподряде. Они могут потратить кучу времени и денег проекта на переносах, багах и конфликтах кода.

Задача тимлида — создать команде среду для разработки и правильные условия для написания кода. Чтобы помочь с этим я решил опубликовать напоминалку, основанную на внутренних регламентах компании где я работаю.

Итак, наша задача: развернуть рабочие стенды девелоперов (dev), тестовое окружение(stage), боевой сервер (prod), наладить процесс разработки и тестирования, доставки артефактов по цепочке и деплоя стабильной версии. Для этого необходимо формализовать, привести к единому алгоритму процесс настройки площадки для разработчика, чтобы не возникало ситуации, когда каждый сам решает, что и где «подкрутить». Золотое правило управленца — если процесс повторяется больше одного раза, на этот процесс должна быть инструкция или регламент.

Расскажу на примере архитектуры, которую используем мы: main — наша основная площадка для тестов и показов. В дополнение используем несколько площадок для каждого из разработчиков — d1, d2 и так далее. Настройкой среды для Битрикс-приложения в нашей компании занимается сисадмин. Здесь нет универсального способа настройки, поэтому подробности опущу.

Шаг 1. Разворачиваем ядро Битрикс (базовое или своей версии):

Проверить кодировки. Устанавливайте сайт СТРОГО в кодировке UTF-8. При проверке сайта (Инструменты – проверка системы) шестым пунктом проверки должно выводиться «Параметры настройки UTF».

Проверить ключи. Ни в коем случае не оставляйте сайт на демо-ключе. Нужно запрашивать некоммерческий ключ для разработки у менеджера проекта, а в случае непредставления — останавливать проект. Об этом должен позаботиться тимлид, иначе про ключ все забудут и в один прекрасный момент сайт перестанет работать.

Поставить галку на версиях разработчиков. После установки продукта в админке нужно отметить, что сайт используется для разработки, а не для коммерческих целей.

Обновить до актуального состояния. Сразу после развертывания необходимо зайти в настройки Битрикс и установить все обновления системы, поскольку в аутсорс-продакшнах часто пользуются готовыми сборками (образами).

После разворачивания сайта необходимо пройти проверку системы и проверку тестирования конфигурации /bitrix/admin/site_checker.php?lang=ru. Ошибок и предупреждений не должно быть. По умолчанию агенты на тестовых площадках Extyl должны выполняться на хитах, а на бою переведены на cron (тимлид проекта решает, когда на тесте надо перевести агента на cron).

Шаг 2. Следим за тем, чтобы площадки для разработки не оказались в индексе поисковиков

Программисты, как правило, вообще не задумываются о поисковиках и последствиях индексации площадки для разработки. Нужно напоминать, что стенды разработки — это те же сайты в сети, а значит их видят роботы, Нам не нужно, чтобы служебная информация оказалась доступна в поиске. Сразу после установки не забываем изменить настройки на боевом сервере.

И в robots.txt прописать правило:

– запрещена индексация сайта;

Во время переноса сайта на боевой сервер, файл должен быть изменен (оставить запрет на индексацию только на системные папки, страницы, файлы, такие как bitrix, upload, auth и т.п.).

Шаг 3. Устанавливаем модуль миграции сущностей БД

Когда у нас уже есть ядро и мы начали делать сайт, появляются данные, с которыми нужно работать и не терять их. Возникает необходимость переноса на бой и обратно изменений сущностей БД (инфоблоки, формы и т.д.).

Ничего не вводим руками, пользуемся миграциями. Причина — миграции дают возможность сделать все, что можно сделать руками, но при этом процесс можно в любой момент времени повторить. Когда команда состоит из нескольких разработчиков, количество забытых данных растет в геометрической прогрессии. Если у заказчика есть предпрод или сроки приемки затягиваются, то без миграций невозможно обойтись в принципе.

Не ленитесь и облегчите себе жизнь установкой мигратора. Он поможет восстановить работоспособность сайта, даже если кто-то удалил базу без возможности восстановления.

Шаг 4. Настраиваем Git

В современных реалиях без GIt не может существовать не один проект, даже очень маленький. Писать код без системы версионирования сегодня невозможно — командная работа на то и командная.

Сразу после развертывания Битрикс — надо установить Git на проект и правильно его настроить:

Не все должно попадать в репозиторий, настраиваем gitignore.

.gitignore может быть изменен и дополнен в зависимости от потребностей проекта.

robots.txt, как и sitemap*.xml, .htaccess должен быть в .gitignore на бою и всех тестовых площадках.

Пара слов о гигиене процессов:

На предпроде должна быть включена ветка stage, а на бою master. В ветках stage и master мы не работаем.

Все ненужные страницы и разделы необходимо удалить перед первым коммитом.

В Git не должны попадать отладочные скрипты, логи, медиафайлы, регистрируемые в БД и др.

Очень важно первично правильно настроить Git и сделать площадку main (stage) чистой — без незакоммиченных файлов. Далее эта площадка будет копироваться на тестовые хосты, и если не выполнить эти предписания, то будут проблемы с тем, что невнимательные разработчики станут коммитить конфигурационные файлы, отладку, ядро и другие вещи, которые не должны попадать в Git. Вообще, когда в истории коммитов видно, как удаляют отладку или то, чего не должно там быть — это говорит о низкой квалификации разработчика. Подробнее о работе с Git я расскажу в следующей статье.

Шаг 5. Настраиваем CI/CD на проекте

CI/CD технология непрерывной интеграции и развертывания сегодня практически стандарт для отрасли, хотя единого алгоритма действий тут нет, и пожалуй быть не может — слишком много разных переменных для каждого проекта, каждый раз настраивать приходится по своему. Но общий алгоритм един — пишется код, покрывается тестами, отправляется в систему контроля версий (не обязательно Git), при поступлении нового коммита — тригерится запуск развертывания тестового окружения и самих тестов. Если все успешно — тригерится деплой артефактов на прод.

Разумеется, это только каркас, и этапов может быть гораздо больше, как и проверок (и автоматических и ручных) на возможность перехода к следующему этапу. Но в рамки этой статьи разбор CI/CD не укладывается, это отдельная и большая тема.

Большие проекты подразумевают настройку CI/CD, но процесс сильно зависит от потребностей проекта.

В этом мире всё, включая разработку, стремится к хаосу, а тимлиды его сдерживают и структурируют работу. Описанные мной шаги банальные, но, как ни странно, снимают огромное количество проблем. Не выполненные вовремя пункты инструкции ведут к негативу заказчика и потере драгоценного времени тимлида. Надеюсь, что материал поможет читателю сделать настройку площадок проще, а работу в команде продуктивнее.

Читайте также: