Dios__deactivated (Все сообщения пользователя)

Эм, крайне сумбурное описание проблемы. Сомневаюсь что можно будет отследить её в формате форума.
Для начала, Вы скорее всего не должны были редактировать компонент с таким опытом работы с битриксом. В 98% задач достаточно редактирования шаблона сайта и/или компонента.

showHead в общем шаблона сайта отвечает за вывод всего что может быть выведено в head, и добавляеться туда через api битрикса

Рекомендую пройти курс https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43
Возмите за основу демо версию и научитесь вносить небольшие правки. Свой компонент каталога это уж очень крутой замах

Да и для остальных полей аналогично

$APPLICATION->SetTitle($strPageHeader); // H1
$APPLICATION->SetPageProperty("keywords", $strPageKeywords);
$APPLICATION->SetPageProperty("description", $strPageDescription);

Для динамического контента, то есть генерируемого php, да. Это специально прописываеться что бы не в коем случае не закешировалась страница в браузере.

Дело в том что генерируемая, через php, html страница скачиваеться по сути на тех же условиях что и любой другой файл как картинка или стили или скрипты или видео файл. Это и есть самый обычный текстовый файл. И он может закешироваться в браузере.

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

Ситуация немного меняеться в одностраничниках, типа AngularJS, но это уже совсем другая история.

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

Если шаблон каталога Вы используете один, то думаю вам нужно писать сео теги своим кодом в шаблоне.

В СЕО шаблоны инфоблока прописать свою переменную типа "#ELEMENT_NAME#", что бы вышло
Buy #ELEMENT_NAME# cheap. Worldwide shipping | Mycompany inc

в template.php
в component_epilog.php шаблона товараКод не тестировался, так как нахаляву
Может какую мелочь не заметил, но принцип такой же.

Для разделов аналогично. Главное помните что IPROPERTY_VALUES кешированы, и не в компоненте.

---

Да и еще момент, отключите встроенные средства задания СЕО полей, что бы не было конфликтов.

Самый распространненый способ вывода контента из инфоблока это комплексный компонент news. Какие поля разделов и элементов выводить можно указать через параметры компонента. Если настроек не достаточно, то нужно отредактировать или купить шаблон.

У вас единственное усложнение, так это выравнивание картинки нужно по значению из базы, а не по центру. То есть просто смещенная точка центрирования.

https://codepen.io/anon/pen/YEdmPX

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

Позиционирование картинки не связано с адаптивностью. Совмещайте с переменной шириной экрана и медиа запросами. Одно другому не мешает.

Вариантов тысячи, конкретное решение зависет от дизайна, набросал несколько методик

https://codepen.io/anon/pen/BmvEXV

Верстка не должна содержать JS, Уже почти 2018, любая кроссбраузерная адаптивка верстаеться на чистом css, все нужные фишки уже поддерживаться подовляющим большенством клиентов. На самый крайний случай есть полифилы. Адаптивное позиционирование/маштабирование/кадрирование картинок это элементарно и не требует JS или вспомогательных html элементов.
Плюс Вы должны избегать обработчиков на частые события, типа resize.
---

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

---

Скорее всего ваша ошибка не связана с битриксом.

Для локальных тестов юзаю Vagrant с вебокружением битрикса, по мойму максимальная совместимость.

Нет, битрикс не влияет на работу jquery, за исключеним одного момента, он может подключать свою копию, что может конфликтовать с вашей копией.
Кеширование битрикса затрагивает только вывод php. Врятли он как то задевает ваш js, разве что вы его засунули в шаблон кешируемого компонента, вместо отдельного файла.

Но в любом случае так делать совершенно безграмотно.  

bitrix/modules/security/lib/filter/request.php

Самые распространненые ошибки в таких случаях:

Файл шаблона все таки не отредактирован.
Кеш таки не сброшен.
Отредактирован не тот шаблон.

Дальше уже дикая экзотика, например ошибки вебсервера, долгий кеш (opcache.revalidate_freq или аналог).

Докину дровишек в холиварчик:

Гляньте какие магазины на битриксе:
http://www.ruward.ru/ecommerce-index-2016/
Как то люди зарабатывают с таким кодом и архитектурой

Независемо от сложности проекта, всегда сводил работу php до 0.1 сек., в среднем 0.06 сек. Наверно это медленно... Будем стараться ускорять...

Как получить оперативную премиум тех-поддержку на халяву:

1) Зарегаться на форуме.
2) Прикинуться школотой.
3) Затролить дедушек.
4) Profit

Как вариант импортировать вашу базу в инфоблок и выводить компонентом news

Судя по ошибке, ваш сайт пытаеться отослать почту, но не удаеться законектиться к mail.nic.ru. Вероятных причин валом. Или сам сервис лег, или днс на вашем хостинге не работают, или вас временно забанили за частоту конекта.
Проблемы авторизации скорее всего показали бы другую ошибку, но все таки проверьте доступ для почтового аккаунта от которого шлете почту.
Похорошему, конечно, Fatal error не должно быть по такой ошибке, но это вопрос к разрабу сайта.

Очень абстрактный вопрос и не как не связан с битриксом  Получение значения элементов формы нужно через свойство value.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement

То есть сначала например querySelector(или аналог или обертка), а потом свойство value полученного элемента.

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

Я как правило не делаю serialize, так как не хочу отсылать прям все все все в форме и прям в таком формате как ввели. Как правило у меня валидация. А значит надо работать с элементами формы по штучно и каждый разбирать и валидировать, хотя бы по типу поля. Но serialize метод вполне правильный, если это в рамках приложения. Вариантов работы с формой океан и два ведерка. Самое главное - читабельность кода, помимо того, что код рабочий, быстрый и кроссбраузерный, что бы вы могли понять что писали и в будущем могли доработать.

Мой основной тезис - не циклитесь на битриксе в плане ajax. JS битрикса не просто так почти не документирован.

----
Да еще есть autocomplete с разных баз, например выбор города по кладр/фиас. А еще есть мастер настройки, навигаторы, конструкторы. А еще форма может быть сделана без элементов формы, а на дивах, какой нить интерактивный виджет. а еще... а еще... а еще.  

Пользовательские поля на элементы инфоблока? Жесть.... Зачем?  Не путаете со свойствами ?
На вскидку крайне бредовая архитектура. Посторайтесь избежать ситуации когда после разработки проекта есть необходимость добавлять пользовательские поля. И по возможности свойства инфоблока тоже не должны менятся. В каталоге товаров это нормально постоянно добавлять новые свойства, а вот в фотогалерее сомнительная потребность.

"хочется сделать через UF_" - странно, вы должны бежать от них и юзать в крайней и прямой необходимости.

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

Если это галерея то тематику лучше сделать через теги. Коллекции/подборки или элементами с множественными файлами или разделами в зависемости от нужных полей для коллекции и самих фото.

Правильней было бы сделать экспорт из старого двига в файл. Затем импорт в новый двиг с сохранением ИД и/или ссылок старых элементов в свойства.

Переадресация от ссылки с ИД на ссылку с кодом в пхп тоже просто делаеться.
Также желательно в ЧПУ иметь и код и ИД. В случае смены кода элемента или раздела, можно сделать переадресацию по ИД.

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

Классически в разделе /catalog/ у вас должен быть комплексный компонент bitrix:catalog
Он занимаеться машрутизацией запроса и вызовет bitrix:catalog.section или bitrix:catalog.element и/или другие компоненты в зависемости от ссылки.

Рекомендую пройти обучающий курс, сэкономите кучу времени

Типового функционала не видел, возможно в купленных решениях есть. Вы уверены что хотите проиндексировать эти страницы?  

Ну ты и гробокопатель

https://dev.1c-bitrix.ru/community/forums/messages/forum6/topic56979/message513971­/#message513971