Андрей Николаев

Если хотите извращаться то, вот тут дали нормальный ответ.



Но как уже сказал Вам Алексей Емельянов - предупредите, что из-за этого внутренние механизмы платформы могут быть сломаны, интернет-магазин перестанет нормально работать/продавать и сайт выпадет из выдачи. Возьмите письменное распоряжение утвержденное Вашим руководителем, что ответственный будет SEO-шник. Скорее всего его это напугает и он отстанет.

Для начала нужно осознать, что проблема не на всех страницах. Например главная очень даже хорошо отображается.
Что касается остальных:
1) Для начала держим битрикс обновленным (иначе некоторые фишки могут не всегда корректно работать)
2) В настройках главного модуля нужно обязательно отметить опции "Объединять CSS файлы" и "Объединять JS файлы". В идеале конечно все из блока "Оптимизация CSS", но на практике иногда после этого большие проблемы с кешированием в браузерах.
3) Затем необходимо проверить форму входа - капча именно там выводится:


4) Далее нужно разобраться с картинками - слишком тяжелые. На странице каталога видел по 3МБ. Вообще в легкую без потери качества можно сжать минимум в 2х раза (а то и больше). Всякие JPEG 2000/XP и WebP не предлагаю, так как битрикс не работает с ними, но банально снизить качество (хотя бы до 80%) и разрешение можно.
5) Проведите рефакторинг в компонентах. В идеале inline javascript и css кода на странице быть не должно, а у Вас его куча.

Вариантов масса и все зависит от конкретной задачи (Вашу задачу я интерпретировал 3 способами)
Навскидку, можно сделать так:
1) Использовать включаему область для фона (и другого html-содержимого).
2) Можно через свойства страницы
3) Можно сделать компонент с параметром (типа файл) и через отложенные функции изменять код

$eventManager = \Bitrix\Main\EventManager::getInstance();

$eventManager->addEventHandlerCompatible('search', 'BeforeIndex',    ['\\CatalogProductIndexer','handleBeforeIndex']);


class CatalogProductIndexer
{
	/**
	 * @var int Идентификатор инфоблока каталога 
	 */
	const IBLOCK_ID = '30';

	/**
	 * Дополняет индексируемый массив нужными значениями
	 * подписан на событие BeforeIndex модуля search
	 * @param array $arFields 
	 * @return array
	 */
	public static function handleBeforeIndex( $arFields = [] )
	{
		if ( !static::isInetesting( $arFields ) )
		{
			return $arFields;
		}

		/**
		 * @var array Массив полей элемента, которые нас интересуют
		 */
		$arSelect = [
			'ID',
			'IBLOCK_ID',
			'PROPERTY_TEST1',
			'PROPERTY_TEST2'
		];

		/**
		 * @var CIblockResult Массив описывающий индексируемый элемент
		 */
		$resElements = \CIBlockElement::getList(
			[],
			[
				'IBLOCK_ID' => $arFields['PARAM2'],
				'ID'        => $arFields['ITEM_ID']
			],
			false,
			[
				'nTopCount'=>1
			],
			$arSelect
		);

		/**
		 * В случае, если элемент найден мы добавляем нужные поля 
		 * в соответсвующие столбцы поиска
		 */
		if ( $arElement = $resElements->fetch() )
		{
			$arFields['TITLE'] .= ' '.$arElement['PROPERTY_TEST1_VALUE'];
			$arFields['BODY'] .= ' '.$arElement['PROPERTY_TEST2_VALUE'];
		}

		return $arFields;
	}

	/**
	 * Возвращает true, если это интересующий нас элемент
	 * @param array $fields 
	 * @return boolean
	 */
	public static function isInetesting( $fields = [] )
	{
		return ( $fields["MODULE_ID"] == "iblock" && $fields['PARAM2'] == static::IBLOCK_ID );
	}

}

У Вас происходит подмена понятий.
Если Вы хотите интегрировать верстку (т.е. заменить верстку корзины, на свою), то Вам совершенно не обязательно писать код получения товара из корзины. Вам нужно создать отдельный шаблон для уже существующего компонента корзины и манипулируя доступными $arResult и $arParams переменными в шаблоне вывести корзину. Подробнее в главе по Интеграции дизайна в курсе Разработчик Bitrix Framework

Если Вы хотите написать корзину с нуля (собственный компонент), то придется сильно попотеть, так как это задача отнюдь не для начинающего разработчика. Придется разобраться в том, как устроен битрикс изнутри, как взаимодействуют модули и многое другое. Иными словами пройти почти все курсы от Контент-менеджера до разработчика Bitrix Framework

Или может кто-нибудь знает другие способы создания активности на портале?

За 1тысячу рублей в год покупаете самый дешевый VPS и пишете на нем selenium скрипт (или phantomjs) который заходит на портал, создает лид, двигает его по статусам и удаляет.

Подскажите, где находятся настройки модуля структуры компании и как починить?

Это не таблицы, а разделы инфоблоков.
В админке: Контент - Оргструктура - Подразделения
Если с технической точки зрения, то орг.структура строится из разделов инфоблока, код которого лежит в b_option (модуль: intranet. название: iblock_structure)

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

Во-первых, не ясно почему в таблице встречаются дубли, да еще и на колонке id.
Де-факто во всех проектах, что я видел, при наличии этого поля оно уникально (как минимум autoincement).

Во-вторых, подобный вопрос легко ищется поисковиком. Например тут.
Если хотите узнать больше, гуглите "Составной первичный ключ mysql"

У нас стартовая для виртуального сервера:
- 4GB RAM
- 2vCPU 2.4 (min)
- 20GB SSD
- KVM (не OpenVZ!)
В год выходит около 12 тысяч.

Дополнительно берем: Selectel (обачно хранилище).
Туда КП сгружает все загруженные/сгенерированные пользователем данные. У нас там порядка 80ГБ уже, и в год все это счастье ест где-то 2-3 тыс.руб.

Всего весь портал ест где-то 15 тыс. рублей в год.

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

P.S. Если нужные собственные модули/разработки, то окупается во много раз

Нормально это не будет работать никак.

Для того, чтобы это хоть как-то работало нужно соблюсти ряд условий и ограничений:
1) Вы должны хорошо разбираться в nginx, чтобы развести root path в зависимости от адреса домена. Вы же не подумали, какая админка должна открываться по /bitrix/ ? Это уже не типовая конфигурация, которую Вам, к слову, еще и поддерживать.
2) Вы забудете об авторизации, то есть пользователь одного сайта это не пользователь другого сайта и переходя между страницами Вы потеряете авторизацию, ровно как и часть действий будет недоступна (например с сайта 1 вы не сможете редактировать статью У если она не на сайте 1, а на сайте 2, соответственно сайт 1 не будет видеть статей сайта 2 и наоборот). То есть - вся динамическая информация (записи инфоблоков и т.п.) должна переносится сразу (а не по 1-2 элемента)
3) Помимо этого еще и системные скрипты будут некорректно работать. Если на сайте нет авторизации, и только гости, то проблем вообще не будет, а если Вы таким образом захотите обновить интернет магазин, то займет это у Вас и времени и сил больше, чем написать с 0 новый и разработать скрипт миграции данных.

ИМХО, Ваша затея имеет место быть но в оочень редком случае (меньше 0.01%), а неудобств и ограничений Вы получите существенно больше.
Поверьте, я знаю о чем говорю - мы обслуживали 2 портала Битиркс24 (коробочная версия), на одном из которых Была 15 версия с CRM, а на другом 17 с остальной частью портала.

Ну... все относительно просто.

1) Изучаете API Хорошопа (на уровне "посмотреть что может")
2) Изучаете API Битрикс24 (на уровне "посмотреть что может")
3) Определяете что именно из Хорошопа должно уйти в Битрикс24 и что должно уходить из Б24 в Хорошоп.
4) Покупаете сервер, к нему домен и ssl сертификат. Устаналиваете все что необходимо для работы (например nginx, php, mysql и т.п.).
5) Пишете приложение обмена. Сначала в одну сторону (Хорошоп - Битрикс), потом если нужно - в другую.

Эм... есть несколько вопросов по Вашему "чуду".
Отбросив велосипедизм и костылестроение есть пара вопросов по логике работы.

То что у Вас есть константа MAX_AGE_IN_YEARS (кстати почемы бы просто не спрашивать дату рождения?) это ок (смущает конечно _IN_YEARS, но да ладно), то что у Вас 3 пола это тоже допустимо (по крайней мере в нашей адекватной России), то что у Вас есть допустимый ростовой диапазон тоже, но во чего я точно не могу понять, так это блин STATUSES.

Почему бы не сделать 2 "статуса" (на самом деле эт о скорее "признак жизни субьекта") - DEAD или ALIVE, то есть живой или не живой.
child, adult, old и т.п. можно получить при помощи отдельного метода исходя из возраста обьекта (ведь они же зависят от возраста, а не от каких либо правил).
"Статусы" buried и cremated это не статусы, а виды погребения.

Велосипедизм вызван именно нежеланием разделять физические сущности на их логические составляющие.

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

1) Проверьте настройки складского учета и что-то я не вижу класса провайдера при создании товара. Вы его передаете? Проверьте актуальные данные тут - https://dev.1c-bitrix.ru/community/blogs/vws/about...
2) А в paymentCollection после изменения цены все норм?