Когда требуется выполнить синхронизацию с внешним источником данных (например, с 1С), то 1С Битрикс может выдать следующую ошибку: «Время на сервере базы данных отличается от времени на веб-сервере больше, чем на 10 минут». Это означает, что необходимо проверить и настроить правильные временные зоны.
Разберем эту проблему детальнее. Можно выполнить простой фикс (грабли) в виде хука в файле /bitrix/php_interface/after_connect_d7.php
указать принудительно:
$connection->queryExecute("SET LOCAL time_zone='".date('P')."'");
Но мы рекомендуем разобраться детально в причинах проблемы, для этого подключитесь к серверу по SSH и проверьте командой ‘date’ время в операционной системе (здесь и далее мы работаем в CentOS 7.
В консоли мы сначала забекапим временные файлы:
[root@sx ~]# mv /etc/localtime /etc/localtime-backup
потом делаем линк на нужную нам часовую зону:
[root@sx ~]# ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime
И далее проверяем командой ‘date’ корректность нового времени.
Вот как это выглядит в терминале:
[root@sx ~]# mv /etc/localtime /etc/localtime-backup [root@sx ~]# date Wed Apr 8 17:19:38 UTC 2020 [root@sx ~]# ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime [root@sx ~]# date Wed Apr 8 20:19:46 MSK 2020
Далее подключаемся в MySQL / MariaDB и проверяем тайм-зону командой:
select current_timestamp;
В консоли это выглядит так:
[root@sx ~]# mysql Welcome to the MariaDB monitor. Commands end with ; or g. Your MariaDB connection id is 104506 Server version: 5.5.64-MariaDB MariaDB Server Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or 'h' for help. Type 'c' to clear the current input statement. MariaDB [(none)]> select current_timestamp; +---------------------+ | current_timestamp | +---------------------+ | 2020-04-08 20:24:41 | +---------------------+ 1 row in set (0.00 sec) MariaDB [(none)]>
Если в MySQL / MariaDB неверное время, то выполняем следующее по определению default_time_zone: идем в /etc/my.cnf (CentOS) или /etc/mysql/my.cnf (Ubuntu) и после:
[root@sx ~] sudo /etc/init.d/mysqld restart
Сложные случаи конфликта во времени в SysConfig
Иногда так происходит, что еще одна отсылка ко времени сервера есть в:
/etc/sysconfig/clock
Вы можете поменять тайм-зону через ‘tzselect’, а в SysConfig, например, может быть прописано: ZONE=America/New_York
Это решается достаточно просто:
[root@sx ~]# vim /etc/sysconfig/clock ZONE="Europe/Moscow" UTC=true ARC=false
Временные зоны в PHP
Сейчас переходим к PHP, здесь тоже может быть нюанс, поэтому смотрим: /etc/php.ini
(из него билдится уже /etc/php.d/bitrixenv.ini) в ini-файле корректируем или добавляем:
timezone = Europe/Moscow
После изменений в php.ini нужно рестартнуть Апач:
service httpd restart
Recommend Projects
-
ReactA declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
TypescriptTypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlowAn Open Source Machine Learning Framework for Everyone
-
DjangoThe Web framework for perfectionists with deadlines.
-
LaravelA PHP framework for web artisans
-
D3Bring data to life with SVG, Canvas and HTML. 📊📈🎉
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
FacebookWe are working to build community through open source technology. NB: members must have two-factor auth.
-
MicrosoftOpen source projects and samples from Microsoft.
-
GoogleGoogle ❤️ Open Source for everyone.
-
AlibabaAlibaba Open Source for everyone
-
D3Data-Driven Documents codes.
-
TencentChina tencent open source team.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
- Pick a username
- Email Address
- Password
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Подскажите — где проблема- начал делать очередную резервную копию- вылезла эта ошибка. в списке копий- архив создается — но меня смущает что из за этой ошибки архив окажется не дееспособен… |
|
Пользователь 302684 Постоянный посетитель Сообщений: 94 |
#2 0 23.08.2016 12:08:37 Попробуйте после бекапа скачать архив на компьютер (если он адекватных размеров) и распакуйте. Проверьте, все ли файлы в папке /bitrix/themes/.default/public/panel_new/icons на месте. Или откройте архив прямо в папке хостинга, если файловый менеджер это позволяет и так же проверьте, все ли там на месте.
вкладка «Проверка доступа» Если сообщение было для Вас полезным, лучшая благодарность это кнопка «Мне нравится» |
||
по вашему совету запустил проверку доступа- отписались ошибки- Недоступны для чтения или записи (показаны первые 10):
/home/bitrix/www/bitrix/themes/.default/public/panel_new/icons |
|
затем провел тестирование конфигурации. показало два красный значения- |
|
Если Вы управляете хостингом, то Вам нужно сменить права на эти каталоги. Не знаю, под каким пользователем у Вас запущен веб-сервис, по этому попробуйте поставить права 775 Если сообщение было для Вас полезным, лучшая благодарность это кнопка «Мне нравится» |
|
есть помощь по данным ошибкам? сам пока не лезу..жду коментариев..спс за совет как проверить конфиги.сам пока не очень разбираюсь |
|||||
session.cookie_httponly — в файле php.ini указать off у этого параметра, или в файле .htaccess php_value session.cookie_httponly off По второй ошибке — я так понимаю у Вас многоуровневая архитектура, и сервер БД — это отдельный сервер/виртуалка. Проверьте время на сервере БД и сервере приложения (сервер где папка bitrix) Если сообщение было для Вас полезным, лучшая благодарность это кнопка «Мне нравится» |
|
Пользователь 170796 Заглянувший Сообщений: 5 |
#8 0 30.08.2016 11:22:17 спасибо за помощь. проблема решилась путем установки прав 775 на папку через ftp |
«1С-Битрикс: Управление сайтом» — одна из самых популярных коммерческих CMS. Как и в случае с любой другой CMS, при работе с Битриксом возникают разные ошибки, мешающие нормальной работе сайта. Выявить их можно с помощью встроенного функционала проверки системы в панели администратора Битрикс.
Чтобы запустить проверку системы, перейдите в панель администратора по ссылке https://example.com/bitrix/admin (замените example.com на ваш домен), введите логин и пароль учетной записи администратора сайта, перейдите в Настройки — Инструменты — Проверка системы и нажмите на кнопку Начать тестирование. Дождитесь окончания проверки. В форме Проверка системы могут быть ошибки, которые, на первый взгляд, не влияют на работу сайта, однако требуют внимания владельца или системного администратора сайта.
В данной статье рассмотрим способы устранения популярных ошибок, возникающих в CMS Битрикс.
- Ошибка «The script encountered an error and will be aborted. To view extended error messages, enable this feature in .settings.php.» при переходе на сайт
- «Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron» при проверке системы
- Ошибка работы с сокетами при проверке системы
- Ошибка! Не работает «Отправка почты» и «Отправка почтового сообщения больше 64Кб» при проверке системы
- «Служебные скрипты в корне сайта. Ошибка! Файл существует» при проверке системы
- Ошибка «Загрузка файла» и «Загрузка файла больше 4Мб» при проверке системы
Ошибка «The script encountered an error and will be aborted. To view extended error messages, enable this feature in .settings.php.» при переходе на сайт
Такая ошибка в большинстве случаев означает некорректное подключение к базе данных. В первую очередь проверьте, работает ли СУБД, введя следующую команду в терминал:
# systemctl status mysql
Если СУБД работает, проверьте файлы, расположенные в /home/bitrix/www/bitrix/.settings.php
и /home/bitrix/www/bitrix/php_interface/dbconn.php
(при необходимости замените /home/bitrix/www
на корневую директорию вашего проекта, далее в статье будут использованы относительные пути вида /bitrix/php_interface/dbconn.php
). В этих файлах указываются доступы для подключения к базе данных сайта.
Для файла .settings.php
'host' => 'localhost', 'database' => 'database_name', 'login' => 'user_name', 'password' => 'secret_password',
Для файла dbconn.php
$DBHost = "localhost"; $DBLogin = 'user_name'; $DBPassword = 'secret_password’; $DBName = "database_name";
Проверьте корректность указанных данных:
- хост базы данных (должен быть localhost, если СУБД установлена локально),
- название базы данных (замените в обоих файлах
database_name
на название своей базы данных), - имя пользователя базы данных (замените
user_name
на имя своего пользователя базы данных) - и пароль пользователя базы данных (замените
secret_password
на пароль пользователя вашей базы данных).
Иногда бывает, что при развертывании сайта из бэкапа на новом сервере вместо данных указываются звездочки. В таком случае просто укажите свои данные в обоих файлах.
«Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron» при проверке системы
При проверке системы Битрикс часто возникает замечание выполнения агентов на cron. Данное замечание не мешает работе сайта, однако может повлиять на выполнение разных функций вашего проекта, например, на отправку почты.
Как правило, для настройки выполнения агентов на cron достаточно следовать рекомендациям проверки системы. Для этого нажмите на вопросительный знак справа от уведомления:
Однако такой способ срабатывает не всегда. Если в файле /bitrix/php_interface/dbconn.php
есть строка define('BX_CRONTAB_SUPPORT', true);
и в cron есть задание на ежеминутный запуск скрипта /var/www/bitrix/modules/main/tools/cron_events.php
, попробуйте следующее решение.
Отключим выполнение агентов на хитах, для этого в панели администратора Битрикс переходим в Настройки — Инструменты — Командная PHP-строка, вводим следующую команду и нажимаем Выполнить:
COption::SetOptionString("main", "agents_use_crontab", "N"); echo COption::GetOptionString("main", "agents_use_crontab", "N"); COption::SetOptionString("main", "check_agents", "N"); echo COption::GetOptionString("main", "check_agents", "Y");
Результат выполнения PHP-команды должен быть «NN».
Далее в файле /bitrix/php_interface/dbconn.php
закомментируем следующие строки (добавьте перед строками знак #):
define("BX_CRONTAB_SUPPORT", true); define("BX_CRONTAB", true);
После чего в этот же файл dbconn.php добавьте строки:
if(!(defined("CHK_EVENT") && CHK_EVENT===true)) define("BX_CRONTAB_SUPPORT", true);
Далее необходимо из учетной записи владельца сайта (если вы работаете в консоли сервера из-под учетной записи root, что не рекомендуется, после создания файла измените владельца файла с помощью команды chown
) создать новый файл cron_events.php в директории /bitrix/php_interface/
и добавить в него следующий код:
<?php $_SERVER["DOCUMENT_ROOT"] = realpath(dirname(__FILE__)."/../.."); $DOCUMENT_ROOT = $_SERVER["DOCUMENT_ROOT"]; define("NO_KEEP_STATISTIC", true); define("NOT_CHECK_PERMISSIONS",true); define('BX_NO_ACCELERATOR_RESET', true); define('CHK_EVENT', true); define('BX_WITH_ON_AFTER_EPILOG', true); require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php"); @set_time_limit(0); @ignore_user_abort(true); CAgent::CheckAgents(); define("BX_CRONTAB_SUPPORT", true); define("BX_CRONTAB", true); CEvent::CheckEvents(); if(CModule::IncludeModule('sender')) { BitrixSenderMailingManager::checkPeriod(false); BitrixSenderMailingManager::checkSend(); } require($_SERVER['DOCUMENT_ROOT']."/bitrix/modules/main/tools/backup.php"); CMain::FinalActions(); ?>
После того, как файл создан с нужными правами, добавляем его в cron. Обязательно делаем это для владельца сайта, так как задания cron для пользователя root могут стать серьезной угрозой безопасности для сайта и сервера. Выполним следующую команду (в нашем случае владелец сайта — bitrix, замените это значение на имя пользователя своего сайта при необходимости):
# crontab -ubitrix -e
Откроется файл с заданиями crontab пользователя сайта. Вставьте следующую строку:
*/1 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cron_events.php
В данной строке значение */1 * * * *
означает выполнение скрипта раз в минуту, вы можете скорректировать частоту выполнения в зависимости от ваших требований к проекту.
Путь /usr/bin/php
— путь для PHP, оставьте его таким же, если у вас на сервере нет альтернативных версий PHP. Если вы используете панель ISPmanager, возможно, ваш сайт работает на альтернативной версии PHP. Проверить версию можно в панели ISPmanager, а узнать корректный путь для PHP — с помощью команды whereis php
в консоли сервера. Например, для альтернативной версии PHP 8.1 путь может быть таким: /opt/php81/bin/php
. Замените путь к скрипту /home/bitrix/www/bitrix/php_interface/cron_events.php
на свой в случае необходимости.
Если в cron есть запись для выполнения скрипта /var/www/bitrix/modules/main/tools/cron_events.php
— ее лучше закомментировать.
Ошибка работы с сокетами при проверке системы
При проверке системы в панели администратора Битрикс может возникнуть ошибка «Работа с сокетами. Ошибка! Не работает».
Также из-за ошибки работы с сокетами другие тесты проводятся некорректно, выдавая ошибку «Замечание. Не удалось проверить из-за ошибки в работе с сокетами».
В большинстве случаев такая ошибка появляется после переноса проекта на новый сервер или при развертывании проекта на локальном компьютере для тестирования. Возникает данная ошибка из-за того, что IP-адрес сервера отличается от IP-адреса, указанного в А-записях домена на серверах DNS. Если вы переносите проект на новый сервер, необходимо указать IP-адрес нового сервера в А-записях и дождаться глобального обновления DNS.
Если А-записи указаны корректно, возможно в файле /etc/hosts
на сервере указан неверный IP для вашего домена. Проверьте файл и укажите правильное значение:
1.2.3.4 example.com
Замените 1.2.3.4
на IP адрес вашего сервера, а example.com
на доменное имя вашего сайта.
Бывает, что на сервере может возникнуть проблема с корневыми сертификатами. Можно попробовать обновить их. В CentOS 7 ведите в консоли сервера:
# yum install ca-certificates -y # update-ca-trust
Ошибка! Не работает «Отправка почты» и «Отправка почтового сообщения больше 64Кб» при проверке системы
Из описания ошибки понятно, что она означает. В большинстве случаев для устранения данной ошибки требуется вмешательство системного администратора или технической поддержки Битрикс. Проблем, из-за которых почта не работает, много. Они могут быть на стороне сервера, в настройках проекта, либо из-за некорректно работающих модулей отправки почты.
Битрикс использует стандартную функцию php mail()
для отправки почты, однако нередко используются другие способы, например, через внешний почтовый сервер. Для проверки работы php mail()
можно воспользоваться инструкцией из ответов на часто задаваемые вопросы на форуме Битрикс.
Также можно выполнить проверку с помощью следующего кода PHP (вставьте его в командную строку PHP в панели администратора Битрикс):
$mail="test@testmail.ru"; // укажите ваш почтовый ящик, на который нужно отправить тестовое письмо $subject ="test" ; // укажите любую тему письма $text= "test message"; // укажите любой текст письма if( mail($mail, $subject, $text) ) { echo 'Письмо отправлено!'; } else{ echo 'Ошибка! Не отправлено'; }
Если письмо не пришло, но вы получили уведомление «Письмо отправлено», значит, письма уходят и проблема в настройках CMS либо в модуле отправки почты. В данном случае можно обратиться в техподдержку Битрикс для выявления проблем в настройках CMS или к разработчику модуля отправки почты.
Не исключено, что письмо просто попало в спам. Можно попробовать отправить на другой почтовый ящик (с другим почтовым доменом). Если письмо пришло — значит, адрес отправителя в черном списке почтового домена, до которого письмо не дошло. Если письмо не дошло — возможно, ваш почтовый домен или IP-адрес попали в глобальные черные списки.
Если письмо не пришло, а вы получили уведомление «Отправка не удалась» — необходимо более детальное изучение проблемы. В таком случае потребуется вмешательство системного администратора.
«Служебные скрипты в корне сайта. Ошибка! Файл существует» при проверке системы
Такая ошибка говорит о наличии в корне сайта служебных скриптов, например, restore.php. Данные скрипты, как правило, добавляют временно для проведения каких-либо работ (например, restore.php — для восстановления сайта из резервной копии). Так или иначе, после выполнения работ такие скрипты необходимо удалить с сервера, так как они представляют угрозу безопасности сайту и данным.
Проверка системы Битрикс загружает файл размером более 4Мб. В большинстве случаев такая ошибка говорит об ограничениях в параметре upload_max_filesize
для PHP.
Необходимо в файле конфигурации PHP установить данное значение выше 4Мб и перезапустить веб-сервер. В зависимости от окружения файл конфигурации PHP может находится в разных местах. Обычно данное значение устанавливается в файле /etc/php.ini
.
Если вы используете панель ISPmanager — поправить конфигурацию можно прямо в ней: выберите нужный сайт, нажмите на кнопку PHP в верхней панели, найдите параметр upload_max_filesize
и укажите нужное значение. Если вы используете окружение BitrixVM, необходимо вносить изменения в специальные файлы конфигурации, чтобы после перезагрузки сервера они не вернулись в исходное состояние. Подробнее можете узнать по ссылке.
На чтение 6 мин Просмотров 1.3к. Опубликовано 07.05.2019
Содержание
- Обновление файла php.ini
- Редактирование файла .htaccess
- Изменение файла wp-config.php
- Изменение лимитов в WHM
- Заключение
- Не выгружаются цены
- Не выгружаются разделы
- Не выгружаются фото
- Задваиваются свойства
- 502 или белый экран
- Символьные коды не создаются
- Много ошибок 404 после обмена с сайтом
- Подразделы перемещаются в корень сайта из родительских разделов
По умолчанию WordPress устанавливает небольшой лимит на размер загружаемых изображений, видеороликов и других файлов. Аналогичная ситуация с PHP memory limit , который сказывается на возможности запускать плагины и скрипты.
Если вы запускаете сайт с большим количеством контента, эти лимиты могут стать проблемой. Можно получить ошибку при загрузке:
Если достигнут предел выделяемой памяти, то выведется другое сообщение об ошибке:
Рассмотрим наиболее эффективные способы увеличения этих лимитов на сервере. Начнем с memory limit php ini .
Обновление файла php.ini
Если вы используете CPanel , перейдите в раздел « Файлы » и нажмите кнопку « Диспетчер файлов ». Убедитесь, что установлен флажок « Показать скрытые файлы », а затем нажмите на кнопку « Перейти ».
Выберите папку wp-admin и найдите файл php.ini или php5.ini . Если такого файла нет, создайте его, нажав на кнопку « Создать файл », расположенную в верхнем левом углу. Назовите файл php.ini и нажмите во всплывающем окне кнопку « Создать файл »:
Если ошибка не исчезла, попробуйте переименовать файл в php5.ini . Когда файл будет открыт, добавьте в него приведенные ниже строки, а затем сохраните изменения и закройте файл:
M — означает мегабайты. Измените лимиты 1000M, 2000M и 3000M на значения, которые необходимы. Изменение значения max_execution_time ограничит время загрузки скрипта.
Во многих случаях используемые значения должны увеличиваться по мере перехода в списке от первой до третьей строки. Upload_max_filesize должен быть самым маленьким, memory limit php ini — самым большим. При этом post_max_size должен иметь среднее значение.
Прежде чем проверить, не исчезла ли ошибка, очистите кэш браузера.
Редактирование файла .htaccess
Если редактирование php.ini не помогло, попробуйте изменить файл .htaccess . Добавьте приведенный ниже код в конец файла:
Измените значения php ini set memory limit так, как вам нужно. Не забудьте сохранить файл и очистить кэш браузера.
Изменение файла wp-config.php
Если оба способа не дали результата, попробуйте отредактировать файл wp-config.php , добавив следующий код в самый низ, перед строкой « happy blogging «:
Сохраните файл и очистите кэш браузера.
Изменение лимитов в WHM
Если сайт размещен на VPS или выделенном сервере, можно попробовать изменить лимиты в WHM .
После того, как вы вошли в систему, перейдите в раздел Конфигурация сервера> Настройки > PHP .
Введите нужные вам значения и нажмите кнопку « Сохранить ».
Затем перейдите в раздел Конфигурация служб> Редактор конфигурации PHP . Прокрутите страницу вниз до разделов memory_limit и upload_max_filesize :
Введите необходимые значения. В разделе « Параметры и информация » найдите memory_limit и задайте то же значение, которое вы установили в memory limit php ini и .htaccess .
Нажмите кнопку « Сохранить » и очистите кэш браузера.
Заключение
Мы рассмотрели все способы решения данной проблемы. Наслаждайтесь возможностью загружать большие файлы и продолжайте использовать на своем сайте плагины WordPress . Внесенные в php memory limit htaccess изменения должны вступить в силу через несколько минут, после чего можно будет приступить к работе с новыми параметрами.
Если нужно загрузить большие файлы только один раз, попробуйте сделать это через FTP . Обычно файлы, загруженные через FTP в каталог /wp-content/uploads/ , не отображаются в библиотеке медиа. Но с помощью плагина Media from FTP можно отобразить их всего в несколько кликов.
Если ни один из вариантов не дал результата, свяжитесь со своим хостинг-провайдером.
Данная публикация представляет собой перевод статьи « How to Increase the Maximum Upload and PHP Memory Limit » , подготовленной дружной командой проекта Интернет-технологии.ру
Столкнулся с такой проблемой, мой проект не хочет грузить файлы больше 2х мб, при валидации формы выходит ошибка «File ‘img’ exceeds the defined ini size». Поиски в интернете привели всего к одному решению, добавить строку
addValidator(‘Size’, false, 5000000)
к полю загрузки файла, но это не решило проблему.
В этой статье мы собрали основные проблемы обмена с 1с и простые чек-листы по их решению
Статья будет полезна как программистам 1С, так и Битрикс разработчикам.
Текст структурирован по принципу: проблема — варианты решения. Если есть конкретная задача, то сразу переходите по внутренней ссылке.
Перед тем, как перейти к описаниям сначала проверьте сайт тестами битрикс (проверка системы и проверка прав доступа). Примерно половина проблем после этого исчезают.
Не выгружаются цены
- Проверяем на стороне 1с, что
- Разрешены типовые соглашения с контрагентами
- Создано типовое соглашение с контрагентами, доступное внешним пользователям
- В нем выбран тип цены
- В товаре есть цена с этим типом цены
- В «отборе и сортировке» в товаре указано это соглашение в поле «цены»
- Если у вас Битрикс Малый бизнес, то тип цен обязательно должен быть один
Не выгружаются разделы
То есть товары попадают на сайт без разделов
Варианты причин и решений
- В разделах могут быть обязательные поля, которые из 1с не могут приходить (например, фото). Тогда при обмене не создастся раздел из-за ошибки
- В Битрикс Малый бизнес может в выгрузке быть настроено больше одного типа цен. В этом случае выгрузка не будет проходить из-за того, что сначала выгружаются цены, а потом структура разделов и если на выгрузке цен выгрузка вернет ошибку, то и разделы не загрузятся.
Не выгружаются фото
Задваиваются свойства
Одно и то же свойство приходит 2 и больше раз.
Причина в том, что в 1с свойства прикрепляются к видам номенклатуры и если их несколько, то и свойств создается несколько для одного И того же.
Как решать
В 1с нужно создавать свойство через копирование предыдущего и при этом обязательно указывать, что «прикрепить именно это свойство к новому виду номенклатуры»
502 или белый экран
Сайт падает с ошибкой 502 или с ошибкой превышения объема выделенной памяти.
В настройках обмена с 1С на стороне сайта время одного шага обмена поставить от 1 до 5 секунд
Если не помогло, то провести обмен без картинок.
Обмен может не проходить из-за того, что сайт не может нарезать превью из очень большой картинки.
Символьные коды не создаются
Скорее всего на сервере не настроен mbstring. Проверьте сайт внутренним тестом битрикс.
Много ошибок 404 после обмена с сайтом
Скорее всего у вас установлена галочка «транслитерировать символьный код из названия при обновлении раздела».
Из-за этого при изменении названия, меняется и адрес, что очень плохо для SEO
Подразделы перемещаются в корень сайта из родительских разделов
Скорее всего это происходит при обмене в режиме «только изменения» при установленной галочке «Не импортировать верхний уровень группы товаров, если он единственный»
Список дополняется по мере выявления новых проблемных мест.