При обновлении платформы "Битрикс Управление Сайтом", число обновлений отображалось правильно на закладке «Установка обновлений», но перейти на закладку «Список обновлений» было нельзя, при нажатии возникала ошибка в браузере, см. первый снимок экрана.
Одновременно с этим, незаметно в журнале ошибок PHP появлялась ошибка Illegal string offset “VERSION”. Ошибка была в файле update_system.php, из-за чего он, очевидно, прекращался, выводился не до конца, и, как результат, не выводил скрипты, с помощью которых можно переходить на другие закладки.
Я в коде update_system.php добавил проверки существования массива “VERSION”, внес изменения, после чего ошибки прекратились, обновления проверились, на закладку «Список обновлений» перейти смог.
Почему не работал скрипт и почему не было массива “VERSION” – мне неизвестно. Скорее всего, что update_system.php не предусматривал варианта, при котором не будет массива “VERSION”, и поэтому не работал, когда не было массива “VERSION”. После того, как я добавил проверку наличия массива “VERSION”, как показано на снимках, всё заработало.
Предлагаю разработчикам "Битрикс Управление Сайтом" доработать update_system.php, чтобы когда нет массива “VERSION”, скрипт нормально отрабатывал.
P.S. Там же нашел файл update_client.php – думал сначала что это троян, у него там идут хакерские конкатенации, декодирование из base64 и eval() – так себя маскируют трояны. Какой смысл так делать?
P.S.S. И не даёт создать обращение через техподдержку http://www.1c-bitrix.ru/ , говорит "не выбрана категория обращения", предлагает приобрести тариф за 990 рублей, хотя у нас на www.ritlabs.com лицензия действующая. Если у вас на http://www.1c-bitrix.ru/ выбираю категорию "обновление", получаю ошибку "не выбрана категория", следовательно не даёт создать обращение. То есть фактически не могу создать ниодного обращения. Поэтому написал сюда.
Сейчас система обновлений и установки модулей/решений работает так, что последовательно скачиваются и устанавливаются все промежуточные версии.
Гораздо быстрее было бы сразу загружать и устанавливать финальные версии.
При регулярной установке обновлений проблема не так заметна.
Зато, при установке небольшого решения/модуля с большим количеством версий или обновлении решения/модуля после длительного перерыва приходится довольно долго ждать.
Видишь примерно такое: установка версии 1.0.0 потом 1.0.1 .... 1.1.0 ... 1.2.0 ... 2.0.0. ... 2.0.1 ... 2.1.0 ... 3.0.1 и т..д.
Огромное количество лишних соединений и операций. Можно в десятки/сотни/(возможно)тысячи раз их сократить загружая сразу финальный вариант..
Несколько раз сталкивался с ситуацией, когда надо связать функционал какого-либо модуля с инфоблоками, и проще всего это сделать через обработчики событий, но тут мы можем столкнуться с зацикленностью, и вот в этой ситуации сабж. бы сильно помог.
Артем, этот вопрос рассматривался неоднократно и решение давно выработано. Отключение событий невозможно - сам продукт их использует. Как избежать зацикленности - тоже известно.
В настоящий момент ORM поддерживает только Update/Delete по первичному ключу.
В результате если вам нужно удалить 10000 из 1 миллиона при определенном условии приходится или писать говнокод (перебор в цикле, а при указанных объемах это уже пошаговый процесс) или писать говнокод (sql-запрос ручками с поддержкой 3х баз даных).
В общем даешь методы bulkUpdate и bulkDelete которые смогут: а) обновлять/удалять записи по условиям а не по ключам б) смогут использовать в запросах свои же поля (например, увеличить значение целочисленного поля НА 1, т.е. SET x = x + 1)