Я так понимаю вы предлагает для начала создать сущность поверх таблице местоположений? Как?
Я бы не хотел клонировать местоположения в отдельную таблицу (сущность ORM) - я хотел бы работать с имеющейся штатной реализацией.
Или я не понял :(
g905, да я вроде вкурсе. Но почему вызовы идут до загрузки самого BX?
Вобще /bitrix/js/main/core/core.js подключается одним из первых, если не самым первым скриптом - до него вызовов BX не должно быть. А если и есть, то это что-то вроде if(!window.BX) window.BX={}
Возможно какие-то решения установленные в админке влияют либо на загрузку скриптов либо еще на что-то.
Если меня попросили погадать на кофейной гуще, то я сказал бы что вероятнее всего у вас в главном модуле стоит галка "Переместить весь Javascript в конец страницы" при этом есть решение которое цепляется на событие завершения формирования страницы и делает какое-то зло. Или еще что-то не дает обработать страницу до конца. Может func_overload не 2 в настройках PHP равен...
Что вообще выдает /bitrix/admin/site_checker.php?lang=ru ?
Есть ошибки?
Да оно-то конечно так, но всякий раз когда речь заходит про то, что нам надо использовать опросы, модуль обучения или блоги я отвечаю что я лучше напишу все сам с нуля.
Ребята, ну это ужос, ужос же внутри.
Недавно статью на Хабре видили? Да - я имею ввиду "Нам нужен другой Битрикс". Так вот - 90% придирок в ней полное ерунда - автор просто не умеет готовить, но заголовок вполне применим к отдельным модулям или возможностям.
Если бы я писал статью хейтерескую - там бы обязательно был бы модуль опросов.
1 Отправка curl'ом прямо из PHP во время генерации результата
2 Если у вас confirm.php грузится не по ajax - перейти на ajax - таким образом у вас не будет загружаться вся страница, и все скрипты сайта, а прогрузится только шаблон sale.order.ajax и сработаются только скрипты в нем.
3 Сделать прокладку между отправкой заказа и confirm.php, которая будет только забивать цели счетчиков
4 Перейти на полноценный ajax, с обаменом данными в json и забивать цели колбэком срабатывающим по приходу данных.
5 Использовать битиркс-аналитику
6 Использовать собственную аналитику
В цело проблема в следующем - вы отправляете данные на сервер, там созадется заказа, после чего данные отправляются клиенту, там обрабатываеются и забиваются цели, отправляя данные счетчиком - вот все что написано boldom это действия между созданием заказа и регистрацией его в аналитике. Если там что-то пойдет не так, данные не будут зарегистрированы. Вам надо минимизировать путь от регистрации до аналитики или разработать такую систему, которая не будет нуждаться в регистрации заказа в аналитике - это еще один путь - можно например забивать цель в момент отправки заказа на сервер, добавляя туда некоторый uid который также сохранять в заказе. Тогда у вас будет другая картина - не все заказы на стороне аналитики будут реальными заказам на сайте, но их можно будет отфильтровать по набору uid.
ANTO, и не должно. Это будет работать только в шаблоне где выводятся товары. Измените верстку так чтобы выводить это там.
В противном случае вам надо будет продублировать компонент внутри section.php - не очень разумно.
ragnar_ok, да - нормальное. Хотя если перенести add и update будет локоничнее, незаметно быстрее, и менее требовательно к памяти.
С другой стороны вам надо будет создать $el заранее. Однако вы и так его создаете, в любом случае даже если оба массива окажутся пустыми.
Обычно вариант с массивами используется когда надо что-то над ними дополнительно выполнить или что-то сделать если ни одного объекта на обновление/добавление нет.
armodim, не слушай VicTHOR - используй SetPropertyValuesEx
Если в update не передашь значение всех свойств - то они сбросятся. А передавать их может быть муторно.
Нет причин в общем случае использовать update для обновления свойств, если ты не хочешь обновить все свойства.
ragnar_ok, ну смотрите, на каком-то масштабе вы все равно столкнетесь с проблемой, какой бы подход не использовали, поэтому улучшить ради улучшения, чтобы было решить проблему на любых машстабах не выйдет.
Следовательно решать ее надо на наиболее вероятном масштабе. Простое добавление 1000 элементов - не проблема.
Возможно в каких-то условиях проблемой может стать добавление предположим 10'000 элементов и пусть есть оптимизация позволяющая ускорить код в 2 раза (хотя вряд ли для данного случая), тогда применив эту оптимизацию вы сможете сдвинуть границу проблемы на 20'000.
Предположим масштабы с которыми будет работать ваше решение от 1000 до 100'000 элементов. Выходит проблему вам придется как-то обходить (например делать импорт пошаговым) и с оптимизацией и без нее, при этом ища способ оптимизации вы пытаетесь улучшить работы решение в очень узком диапазоне значений, по сути только в 10% случаев
Оно того стоит?
Это лирика была. На практике используйте CIBlockElement::Add и не парьтесь.
ragnar_ok, для тысячи? Вы шутите? Ладно если бы там хотя бы 100'000 было, можно бы было задуматься об оптимизации какой-то.
Просто проверить было бы в 10 раз быстрее чем спрашивать, честно слово.
VicTHOR, надо еще добавить что это ключи вызова для компонента вроде news или news.list, но если у ТС каталог - там ограничение количества элементов другим ключом, не NEWS_COUNT.
Честно говоря я ожидал что это будет очевидно, что это ключи.
Евгений Григорьев, тогда тем более никакого отношения к данному параметру.
А блоки вне контейнера - это практически всегда не закрытый или лишний закрывающий тег. Внимательно изучите сгенерированный исходный код страницы. Скормите его какому-нибудь валидатору
Я бы не хотел клонировать местоположения в отдельную таблицу (сущность ORM) - я хотел бы работать с имеющейся штатной реализацией.
Или я не понял :(