Данный метод не привязывается конкретно к 1С-Битрикс.
В 1С-Битрикс безопасность требует, чтобы в папке /upload/ не обрабатывались PHP-скрипты. Это абсолютно разумно, если взять её предназначение: хранение статического контента (картинки, видео, CSV и прочее). Но, к сожалению, их базовое решение не рассчитано на все режимы PHP.
Развитие 1С-Битрикс позволило современным магазинам осуществлять обмен заказами с "1С: Управление торговлей".
Но это создало и некоторые неудобства:
Магазин обменивается большим количеством заказов, в том числе и в статусе "Новый". Не все компании готовы перенести обработку заказов на сайт, им удобнее, чтобы менеджеры обрабатывали их в 1С. В некоторых ситуациях это логично, когда много менеджеров и нет желания переробучать их для обработки заказов на сайте (в случае с 1С-Битрикс переобучение практически минимально). Но эти ситуации создают поток заказов, зачастую тестовых, наряду с реальными заказами между сайтом и 1С.
Для некоторых магазинов характерно большое число товаров в заказе. При этом магазины не всегда следят за полноценным закрытием отгруженных заказов. Как результат: отгруженные заказы продолжают учавствовать в обмене между сайтом и 1С, а за счет большого числа товаров в одном заказе обмен осуществляется файлами, суммарный объем которых может достигать сотни мегабайт.
Обмен заказами прошлых лет. В предыдущем пункте я уже описывал, что квалификация менеджеров, а бывает и отсутствие соответствующего бизнес-процесса в обработке заказов, создает проблему увеличения объема обмена заказами между сайтом и 1С. В частности, уже середина 2016 года, а в обмене участвуют заказы 2015 года (на практике наблюдали и заказы 2011 года). Это создает большую проблему нагрузки на обмен, как в разрезе суммарного размера файлов (объем достигает сотни мегабайт), так и нагрузку на сайт, т.к. ему приходится обрабатывать заказы.
Предупреждения об отсутствии контрагента на сайте. Достаточно распространенное неудобство, когда заказы формировались в 1С, а спустя время было принято решение ввести в эксплуатацию сайт, где будут приниматься новые заказы. Разумеется настраивается обмен, но возникает "Предупреждение" в 1С, что заказ не может быть создан (не найден контрагент). Это предупреждение сообщает, что 1С выгружает на сайт информацию о заказе, который был создан в 1С, а сайт не может идентифицировать контрагента и выдает отказ импорта в 1С. Разумеется обмен проходит заказами с сайта, но каждый раз в 1С информация о неполном обмене.
В процессе технической поддержки наших хостинг-клиентов (не создавших у нас свои сайты) мы столкнулись с такой проблемой:
При выгрузке из 1С базы объёмом более 40 000 многопараметрических позиций запросы в базу "повисают", из-за чего скрипт поглощает большое количество ресурсов и "умирает".
В настройках 1С-Битрикс стоит "шаг" загрузки при импорте из 1С. Но при этом скрипт импорта больших объемов данных (более 30 000 наименований) выполняется больше времени, чем "шаг" в параметрах.
В нашу службу технической поддержки достаточно периодично поступают обращения о вирусе на хостинг-площадке.
Политика безопасности наших серверов не позволяет изменять файлы на хостинг-площадке, не имея авторизированного доступа к площадке (т.е. как извне, так и между площадками распространение вирусов исключено).
Появление вируса на хостинг-площадке наиболее часто возникает по следующей схеме:
Как известно, существует 2 наиболее популярных формата хранения баз данных MySQL - это MyISAM и InnoDB.
Но что же выбрать для наилучшего быстродействия сайтов на 1С-Битрикс?
Проводя тесты и обслуживая различной сложности проекты мы пришли к выводу, что наиболее требователен к базе (генерирует наибольшее количество запросов) модуль "Веб-аналитика" ("Статистика") системы "1С-Битрикс".
Сразу оговорюсь, что вирус не уничтожает сайт, он только мешает посетителям сайта увидеть нужный сайт (делает он это путём переадресации посетителя на другой сайт, который не существует. Следовательно пользователь видит, что страница не найдена и считает, что именно посещаемый им сайт, а не сайт, куда его переадресует вирус - не доступен).
Обслуживая проект Спортмастер (www.sportmaster.ru) мы столкнулись с тем, что 08.06.2009 страницы данного сайта либо загружались со "второго" раза (сообщали, что страница не найдена), либо стали запускать внешнее приложение Adobe Reader (PDF).
Используем лицензионный NOD32. Когда Adobe Reader (PDF) запускался, антивирус блокировал его выполнение и в целом сайт грузился. Но тесты показали, что не всё так было успешно, т.е. большинство браузеров с ошибкой загружали сайт, но Internet Explorer версии 6 и 7 версии (чаще всего 7 версия, т.к. 6-я версия после долгих раздумий загружала) ни в каком виде не запускали сайт.