При обновлении платформы "Битрикс Управление Сайтом", число обновлений отображалось правильно на закладке «Установка обновлений», но перейти на закладку «Список обновлений» было нельзя, при нажатии возникала ошибка в браузере, см. первый снимок экрана.


Одновременно с этим, незаметно в журнале ошибок PHP появлялась ошибка Illegal string offset “VERSION”. Ошибка была в файле update_system.php, из-за чего он, очевидно, прекращался, выводился не до конца, и, как результат, не выводил скрипты, с помощью которых можно переходить на другие закладки.

Illegal string offset 'VERSION' (0)
/home/site/public_html/bitrix/modules/main/admin/update_system.php:2022
#0: require_once(string)
/home/site/public_html/bitrix/admin/update_system.php:2
----------



Я в коде 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)

Во всех методах Add, Update, Delete, сделать возможность отключать отработку событий OnBefore* и OnAfter*

По умолчанию конечно все должно срабатывать.