Возникла потребность создать 1 купон для нескольких магазинов находящихся в одной админке, но так-как правило для каждого сайта своё, а купон должен быть уникальным немного пришлось повозится
У нас редакция Интернет-магазин + СРМ, и несколько сайтов. Вы же поддерживаете многосайтовость.... В СРМ при создание заказа и добавление товара, можно работать только с одним каталогом. Что делать менеджерам другого сайта, если им надо сделать заказ, а товар они выбрать не могут? Да даже элементарно изменить заказ клиента. Через сайт вариант не подходит, сделайте пожалуйста в СРМ!
Почему предлагаю, сейчас есть проблема и в базовом функционале она не решается:
Пользователь зарегистрирован на 1м сайте, может с этими же данными войти на 2й, 3й и не важно сколько сайтов внутри битрикса управление сайтами (в бизнес лицензии количество сайтов не ограничено), вход единый для всех (даже если убрать галочку в главном модуле Распространять авторизацию на все домены).
У нас несколько разных интернет магазинов, клиенты могут быть зарегистрированными в 1м магазине, при этом попытаться зарегистрироваться во 2м, с тем же Емайлом/телефоном/логином - в таком случае им выдает сообщение - такой логин уже занят, пользователь с таким емайлом уже существует - могут попытаться восстановить но получается войдя на 2й сайт изменят от первого.
Какой смысл в многосайтовости - если клиенты общие для всех сайтов?
Как создавать сайты с разными направлениями деятельности - где могут пересекаться клиенты?
Как реализовать - любой вариант решения - добавляйте префикс ID сайта к логину, к емайлу, к телефону.
Пользователь зарегистрирован на 1м сайте, может с этими же данными войти на 2й, 3й и не важно сколько сайтов внутри битрикса управление сайтами (в бизнес лицензии количество сайтов не ограничено), вход единый для всех (даже если убрать галочку в главном модуле Распространять авторизацию на все домены).
У нас несколько разных интернет магазинов, клиенты могут быть зарегистрированными в 1м магазине, при этом попытаться зарегистрироваться во 2м, с тем же Емайлом/телефоном/логином - в таком случае им выдает сообщение - такой логин уже занят, пользователь с таким емайлом уже существует - могут попытаться восстановить но получается войдя на 2й сайт изменят от первого.
Какой смысл в многосайтовости - если клиенты общие для всех сайтов?
Как создавать сайты с разными направлениями деятельности - где могут пересекаться клиенты?
Как реализовать - любой вариант решения - добавляйте префикс ID сайта к логину, к емайлу, к телефону.
Появилась задача разделить сайты на разные сервера (разрослись сайты), но возможности создать бэкап для переноса только одного сайта - невозможно!( Сейчас бэкап собирает всю БД и может фильтровать папки/структуру, но про дополнение дальше...
Предлагаю реализовать функционал бэкапирования определённых сайтов с вычленением нужной части БД, файлов публички, полного ядра и, в идеале, выборкой файлов из /upload/
p.s. все нюансы понимаю и про кастомность тоже помню, но для проектов по инструкции это было бы идеально! да и поможет разобраться с файлопомойкой в /upload/
Предлагаю реализовать функционал бэкапирования определённых сайтов с вычленением нужной части БД, файлов публички, полного ядра и, в идеале, выборкой файлов из /upload/
p.s. все нюансы понимаю и про кастомность тоже помню, но для проектов по инструкции это было бы идеально! да и поможет разобраться с файлопомойкой в /upload/
Нужно дать возможность менять путь к spread.php -- "/bitrix/spread.php" есть во всех базах блокировщиков рекламы, из-за чего прброс кукисов на соседние сайты не работает для тех кто пользуется блокировщиками.
В настоящий момент для склада можно выбрать либо 1 сайт, либо сразу все. Кроме того либо этот склад может быть пунктом выдачи ( и отображаться при оформлении заказа), либо не являться таковым.
Однако сейчас возникла проблема. Весь функционал заточен на склады, но для одного сайта склад является пунктом выдачи, а для другого нет.
Проблему усугубляет жёсткая привязка складов к 1С, т.е. продублировать склады я не могу, или придётся писать немалый костыль.
Вывод: Необходимо сделать привязку складов к нескольким сайтам. И для каждого сайта должны быть свои отдельные настройки (и дефолтные для всех сайтов).
Вообще, такое ощущение, что склады, системы оплат и системы доставок писали разные люди. Внешне они похожи, но способы реализации у них разные. Может ещё реально унифицировать?
Однако сейчас возникла проблема. Весь функционал заточен на склады, но для одного сайта склад является пунктом выдачи, а для другого нет.
Проблему усугубляет жёсткая привязка складов к 1С, т.е. продублировать склады я не могу, или придётся писать немалый костыль.
Вывод: Необходимо сделать привязку складов к нескольким сайтам. И для каждого сайта должны быть свои отдельные настройки (и дефолтные для всех сайтов).
Вообще, такое ощущение, что склады, системы оплат и системы доставок писали разные люди. Внешне они похожи, но способы реализации у них разные. Может ещё реально унифицировать?
БУС - многосайтовая система, но далеко не везде настройки работают на несколько сайтов. Нужно добавить возможность выбора групп пользователей для типов цен, в зависимости от выбранного сайта. Т.е. для разных сайтов различные типы групп.
Причина:
Система на строена на два сайта. Первый сайт отображает розничные цены по-умолчанию для всех пользователей, а второй - должен отображать оптовые. Если я включу права просмотра и покупки по оптовым ценам для всех групп пользователей - то и на первом сайте будут отображаться для всех в первую очередь оптовые, а не розничные.
Либо нужно изобретать велосипед в компонентах, перехватывая цены, убирая лишние и отображая правильные. Либо как решил сейчас - добавил новый тип цен, конвертировал для второго сайта все цены в новый тип, после чего включил для нового типа цен отображение для всех групп пользователей.
Добавить новый тип цен из 1С, как я понимаю, не возможно, т.к. у цен есть внешний код, и создать два разных типа цен с единым внешним кодом не получится. Хотя, может быть это вариант, если будет одновременно при интеграции прописываться два типа цен с разными правами групп а на разных сайтах использоваться разные типы цен.
Причина:
Система на строена на два сайта. Первый сайт отображает розничные цены по-умолчанию для всех пользователей, а второй - должен отображать оптовые. Если я включу права просмотра и покупки по оптовым ценам для всех групп пользователей - то и на первом сайте будут отображаться для всех в первую очередь оптовые, а не розничные.
Либо нужно изобретать велосипед в компонентах, перехватывая цены, убирая лишние и отображая правильные. Либо как решил сейчас - добавил новый тип цен, конвертировал для второго сайта все цены в новый тип, после чего включил для нового типа цен отображение для всех групп пользователей.
Добавить новый тип цен из 1С, как я понимаю, не возможно, т.к. у цен есть внешний код, и создать два разных типа цен с единым внешним кодом не получится. Хотя, может быть это вариант, если будет одновременно при интеграции прописываться два типа цен с разными правами групп а на разных сайтах использоваться разные типы цен.
В настройках главного модуля есть поле:
"Дополнительный параметр для передачи функции mail"
Да оно работает, когда 1 сайт, а когда многосайтовость, то уже возникает проблема. Я добавляю дополнительный параметр "-f" для отправки писем, чтобы не было проблем с SPF spf pass на всех почтовых серверах. Вот это "-fdomainname.ru" добавляем в поле "Дополнительный параметр для передачи функции mail" и всё отлично работает SPF spf pass на всех почтовых серверах.
Хотелось бы, чтобы в это поле можно было вбить "-f#DEFAULT_EMAIL_FROM#" и тогда бы в отправку письма в многосайтовости подставлялся бы домен сайта, от которого отправляется письмо.
Смотрите скриншоты. Когда в многосайтовости пытаюсь подставить -f#DEFAULT_EMAIL_FROM#, то ничего не получается, см.скриншот1.
А когда многосайтовости подставляю то всё в порядке и SPF pass см.скриншот2,
то есть письмо воспринимается как доверенное. Проблема в том, что нужно в многосайтовости отправлять от своего домена -f#DEFAULT_EMAIL_FROM#, а не от конкретного домена "".
"Дополнительный параметр для передачи функции mail"
Да оно работает, когда 1 сайт, а когда многосайтовость, то уже возникает проблема. Я добавляю дополнительный параметр "-f" для отправки писем, чтобы не было проблем с SPF spf pass на всех почтовых серверах. Вот это "-fdomainname.ru" добавляем в поле "Дополнительный параметр для передачи функции mail" и всё отлично работает SPF spf pass на всех почтовых серверах.
Хотелось бы, чтобы в это поле можно было вбить "-f#DEFAULT_EMAIL_FROM#" и тогда бы в отправку письма в многосайтовости подставлялся бы домен сайта, от которого отправляется письмо.
Смотрите скриншоты. Когда в многосайтовости пытаюсь подставить -f#DEFAULT_EMAIL_FROM#, то ничего не получается, см.скриншот1.
А когда многосайтовости подставляю то всё в порядке и SPF pass см.скриншот2,
то есть письмо воспринимается как доверенное. Проблема в том, что нужно в многосайтовости отправлять от своего домена -f#DEFAULT_EMAIL_FROM#, а не от конкретного домена "".
Добрый день!
Рассмотрите возможность использования на одном ядре различных версий 1c Bitrix.
Так приобретая несколько лицензий Эксперт, нужна возможность на том же ядре запустить и версию Старт.
Только в таком случай многосайтовость будет иметь смысл. Т.к. для интернет магазина нужна расширенная реализация, а для корпоративного сайта - это уже не требуется.
Служба поддержки - сообщила, что для разных версий нужно создавать разные ядра, тогда смысл многосайтовости в принципе теряется.
Рассмотрите возможность использования на одном ядре различных версий 1c Bitrix.
Так приобретая несколько лицензий Эксперт, нужна возможность на том же ядре запустить и версию Старт.
Только в таком случай многосайтовость будет иметь смысл. Т.к. для интернет магазина нужна расширенная реализация, а для корпоративного сайта - это уже не требуется.
Служба поддержки - сообщила, что для разных версий нужно создавать разные ядра, тогда смысл многосайтовости в принципе теряется.
Сейчас служебная процедура "Временное закрытие публичной части сайта" из настроек главного модуля не учитывает многосайтовость и закрывает публичную часть всех сайтов на системе управления.
Мне кажется, что достаточно очевидна необходимость выборочного закрытия публичной части для выборочных сайтов на одной системе управления.
Мне кажется, что достаточно очевидна необходимость выборочного закрытия публичной части для выборочных сайтов на одной системе управления.
Ваша жизнь превращается в ад. По порядку:
- ID сайта допускает только 2 символа. У нас почти 200 сайтов. Представьте кошмар выдумывания новых id. Мы перебрали уже половину алфавита! Смотрите скрин! Надо увеличить количество символов!
- В списке сайтов надо добавить поле "дата создания", потому что сейчас сайт можно найти только через поиск по странице!
- Когда в списке шаблонов у компонента они будут отсортированы по алфавиту хотя бы? Сейчас найти нужный щаблон невозможно вообще! Смотрите скрин.
- На странице инфоблока в админке должна быть кнопка к быстрому переходу к его настройкам! Ужас как неудобно сворачивать все инфоблоки, потом лезть вниз в настройки.
Концепция многосайтовости подразумевает, что в одной БУС находятся пользователи нескольких сайтов. Для их разделения обычно используются группы. Приходится вручную добавлять пользователя в конкретную группу после регистрации на конкретном сайте. А нужно всего лишь добавить в стандартный компонент bitrix:main.register список множественного выбора с группами, в которые помещать пользователя после регистрации. Реализуется очень просто, а пользы много =)
Данная опция в контексте многосайтовости должна быть в настройках сайта, а не главного модуля.
Также не плохо бы предусмотреть шаблоны данного сообщения для каждого сайта.
Также не плохо бы предусмотреть шаблоны данного сообщения для каждого сайта.
Здравствуйте!
На данный момент в архив резервного копирования льются все сайты на лицензии и разделить их не ту возможности. По-моему, было бы удобнее, иметь такую возможность, чтобы понимать в каком архиве какой сайт.
З.Ы.:Не нашел раздела "Инструменты", кинул сюда.
На данный момент в архив резервного копирования льются все сайты на лицензии и разделить их не ту возможности. По-моему, было бы удобнее, иметь такую возможность, чтобы понимать в каком архиве какой сайт.
З.Ы.:Не нашел раздела "Инструменты", кинул сюда.
Всем привет!
Здесь есть интересная информация в которой указано, что "На данный момент процедура удаления сайта не совсем проста для обычного пользователя, т.к. требуется самостоятельно просмотреть все объекты, которые могут быть привязаны к сайту. Это могут быть заказы, информационные блоки, форумы и прочие объекты."
Учитывая то, что объектов может быть действительно много, предлагаю сделать удаление сайтов и связанных объектов гуманным для любого пользователя, как для обычного, так и для продвинутого, а именно, сделать удаление сайтов по принципу: "если удаляется что-то большего масштаба (САЙТ), то удаляется и то, что меньшего масштаба (ОБЪЕКТЫ) и соответственно входит в структуру большего масштаба (в САЙТ)." При этом важно сделать сервисный запрос, когда система будет спрашивать и выдавать две кнопки: "Удалить без возможности восстановления?" (красная кнопка) и "Отвязать все объекты от сайта" (синяя кнопка).
Можно сделать и по-другому:
Возле строки сайта в списке сайтов сделать в выпадающем меню вкладку: "Отвязать объекты от сайта", а также "Удалить объекты сайта". В результате будет выдаваться список всех связанных объектов, где можно галочкой выбрать все и удалить (либо отвязать) или выделить только ненужные и удалить (либо отвязать).
В общем предлагаю удаление сайтов и объектов сделать масштабируемым, когда можно удалять и самые мелкие объекты и самые крупные, делать это без напряга и длительного вычисления и поиска, что привязано и к чему.
Мое предложение особенно актуально для тех, кто использует многосайтовость и имеет на одной системе более 2 сайтов, а также активно использует инфоблоки, форумы и прочие объекты.
Здесь есть интересная информация в которой указано, что "На данный момент процедура удаления сайта не совсем проста для обычного пользователя, т.к. требуется самостоятельно просмотреть все объекты, которые могут быть привязаны к сайту. Это могут быть заказы, информационные блоки, форумы и прочие объекты."
Учитывая то, что объектов может быть действительно много, предлагаю сделать удаление сайтов и связанных объектов гуманным для любого пользователя, как для обычного, так и для продвинутого, а именно, сделать удаление сайтов по принципу: "если удаляется что-то большего масштаба (САЙТ), то удаляется и то, что меньшего масштаба (ОБЪЕКТЫ) и соответственно входит в структуру большего масштаба (в САЙТ)." При этом важно сделать сервисный запрос, когда система будет спрашивать и выдавать две кнопки: "Удалить без возможности восстановления?" (красная кнопка) и "Отвязать все объекты от сайта" (синяя кнопка).
Можно сделать и по-другому:
Возле строки сайта в списке сайтов сделать в выпадающем меню вкладку: "Отвязать объекты от сайта", а также "Удалить объекты сайта". В результате будет выдаваться список всех связанных объектов, где можно галочкой выбрать все и удалить (либо отвязать) или выделить только ненужные и удалить (либо отвязать).
В общем предлагаю удаление сайтов и объектов сделать масштабируемым, когда можно удалять и самые мелкие объекты и самые крупные, делать это без напряга и длительного вычисления и поиска, что привязано и к чему.
Мое предложение особенно актуально для тех, кто использует многосайтовость и имеет на одной системе более 2 сайтов, а также активно использует инфоблоки, форумы и прочие объекты.
В новом модуле поискового продвижения есть возможность редактировать robots.txt.
Увы нельзя задать имя полученному файлу.
Это нормально, когда сайты в Битрикс имеют отдельные папки (через DOCUMENT_ROOT или SITE_DIR). Но бывает ситуации, когда папки для ряда сайтов общие - получаем общий набор файлов для сайтов.
В итоге сайтов несколько, а robots.txt у них один и нельзя сделать их разными (это удобно для указания на sitemap - его имя, к счастью, можно в настройках указать).
Более подробно . Цель - нормально поддержать работу с региональными сайтами.
Добавлено по комментариям: Отдавать разные версии robots.txt в этой ситуации можно средствами nginx. Главное в этой идее не второй шаг (я привел в пример неэффективный способ отдачи средствами PHP), а первый - сама возможность сохранить различные версии robots.txt для сайтов в такой конфигурации.
Добавлено после осмотра исходников модуля seo 14.5.0 (18.04.2014): Улучшений нет никаких. Имя robots.txt вбито в константе \Bitrix\Seo\RobotsFile::ROBOTS_FILE_NAME и ничего с этим не поделать ни с помощью событий (их нет), ни с помощью глубокой кастомизации (я имею в виду создание своего класса унаследовав от стандартного). Функционал редактирования robots.txt на сайтах с одной общей папкой сейчас неупотребим.
Увы нельзя задать имя полученному файлу.
Это нормально, когда сайты в Битрикс имеют отдельные папки (через DOCUMENT_ROOT или SITE_DIR). Но бывает ситуации, когда папки для ряда сайтов общие - получаем общий набор файлов для сайтов.
В итоге сайтов несколько, а robots.txt у них один и нельзя сделать их разными (это удобно для указания на sitemap - его имя, к счастью, можно в настройках указать).
Более подробно . Цель - нормально поддержать работу с региональными сайтами.
Добавлено по комментариям: Отдавать разные версии robots.txt в этой ситуации можно средствами nginx. Главное в этой идее не второй шаг (я привел в пример неэффективный способ отдачи средствами PHP), а первый - сама возможность сохранить различные версии robots.txt для сайтов в такой конфигурации.
Добавлено после осмотра исходников модуля seo 14.5.0 (18.04.2014): Улучшений нет никаких. Имя robots.txt вбито в константе \Bitrix\Seo\RobotsFile::ROBOTS_FILE_NAME и ничего с этим не поделать ни с помощью событий (их нет), ни с помощью глубокой кастомизации (я имею в виду создание своего класса унаследовав от стандартного). Функционал редактирования robots.txt на сайтах с одной общей папкой сейчас неупотребим.
/ru/
/en/
/de/
etc.
1 сайт, разное содержание у каждого инфоблока/статьи, редактирование соответственно в одном месте.
соответственно html lng='lng', мета, у инфоблоков доп аттрибут язык, настраиваемая часть URL (в данном случае site.ru/xx/).
Со всеми вытекающими.
/en/
/de/
etc.
1 сайт, разное содержание у каждого инфоблока/статьи, редактирование соответственно в одном месте.
соответственно html lng='lng', мета, у инфоблоков доп аттрибут язык, настраиваемая часть URL (в данном случае site.ru/xx/).
Со всеми вытекающими.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
