Настройки форума 1с битрикс
Обновлено: 06.07.2024
В этой статье, мы поговорим о создании форума на сайте с платформой Bitrix. В первую очередь, убедитесь что на сайте установлен модуль Форум. Отмечаем, что вы можете установить этот модуль во время установки платформы. Чтобы перейти к процессу создания форума, сперва перейдите в раздел Администрирование/ Форумы.
Здесь, выберите Группы форумов для того, чтобы создать группу. Как указано на изображении ниже, вы прописываете название и описание. Таких групп может быть одна или несколько, в зависимости от ваших целей.
Далее, переходите к параметрам по описанию будущего форума. Где вы, также, указываете название, описание, группу к оторой он будет относиться и сайт, где он будет расположен. (ставите галочку)
Видим, что к одной группе могут относиться сразу несколько форумов.
И так, группа и форумы созданы, но теперь нам нужно чтобы они отобразились на нашем сайте. Для этого, из администрирования переходим в раздел Сайт/Создать раздел/ По шаблону/Форум ЧПУ.
Далее, перед вами откроется окно «Мастер создания нового раздела» в котором необходимо заполнить заголовок раздела, у нас это Форум и нажимаем «Далее».
После, вам нужно будет выбрать тип меню, иными словами место где будет отображен форум в последствии. Мы выбрали Верхнее меню и Последний пункт.
Затем, выбираете какой конкретный форум, из имеющегося списка, будет отображен в пункте меню «Форум» и переходите Далее.
Теперь, вам нужно будет описать форум: чему будет посвящен, ключевые и продвигаемые слова прочее. В конце нажимаете «Готово».
В результате, вы увидите комплексный компонент форума, при нажатии на который можно задать все нужные настройки.
При чем настроек, будет много, поэтому они будет сгруппированы по разделам.
Как результат, после всех проделанных манипуляций, вы увидите, что в меню отобразиться новый раздел Форум.
Настройка любой площадки для 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, но процесс сильно зависит от потребностей проекта.
В этом мире всё, включая разработку, стремится к хаосу, а тимлиды его сдерживают и структурируют работу. Описанные мной шаги банальные, но, как ни странно, снимают огромное количество проблем. Не выполненные вовремя пункты инструкции ведут к негативу заказчика и потере драгоценного времени тимлида. Надеюсь, что материал поможет читателю сделать настройку площадок проще, а работу в команде продуктивнее.
Читайте также: