Была уже сходная просьба, но к она была сожалению проигнорирована. Хотелось бы более полноценной поддержки.

Предлагаю пойти навстречу разработчикам и дать возможность установки Bitrix при помощи Composer.

Для описания в языковых файлах предлагаю
1. Использовать сами идентификаторы описываемых событий, то есть например:
без добавления дополнительных идентификаторов, типа "mymodul_" и т.д., так как по заданному стандарту предполагается присутствие всех нужных партнерских идентификаторов в имени идентификатора события.
2. Описывать событие в неопределенной форме, кратко, то есть "Добавление раздела инфоблока" можно использовать такое описание в любом месте, а вот "Событие вызываемое при добавлении раздела информационного блока", или "Вызывается при создании раздела", или "Позволяет изменить данные созданного раздела" и т.д. не универсально.
3. Описывать только стабильные события, то есть те, которые можно смело использовать, не боясь, что они будут переименованы, удалены и т.д.

Наличие языковых файлов позволит разработчикам, использующих события:
1. Упростить поиск доступных и стабильных событий.
2. Упростит получение списка событий в человекопонятном виде, а значит уменьшит время на формирование функционала, и исключит не нужны прослойки.
3. Упростит жизнь тем, кто активно работает с событиями, освободив массу времени от задач по постоянному добавлению новых событий, удалению убитых и т.д.

Ну реально наболело и отнимает слишком много времени на актуализацию и очеловечивание списка событий, особенно в части партнерских модулей!

ВАЖНО: ключи в массиве языковых значений должны полностью соответствовать символьному представлению события в коде включая РЕГИСТР, это значительно упростит написание кода, это позволит получать символьное представление событий для динамической вставки в код, равно как позволит получать человекопонятное описание события для последующей динамической вставки и вывода и т.д.

Предлагаю в методы GetProductData и OrderProduct интерфейса IBXSaleProductProvider обязательно передавать ID элемента корзины (BASKET_ID).

Читать подробнее...

Добавить в меню виртуальной машины пункт:

20. Enable xDebug (xDebug disabled)

или

20. Disable xDebug (xDebug enabled)Связано с выходом модуля отладчик и тем, что xDebug нельзя постоянно держать включенным на боевом сервере.

Время от времени xDebug приходится включать самому с мягкой перезагрузкой апача.

Есть продукт - 1С-Битрикс. Время от времени в нем возникают критичные ошибки.

Одна из неприятных - это когда сайт вернул в 1С статус "перенос строки success", а 1С написала клиенту, что обмен завершился с ошибкой.

Мы считаем себя способными разобраться в проблеме клиента и прежде чем писать в техподдержку пробуем сами исследовать.

Такие мелкие, но очень досадные ошибки должны исправляться в тот же день, как были обнаружены. Эти ошибки отбирют наше время и сокращают жизнь. Ошибки должны быть описаны в описании к обновлению.

Зачем держать цикл разработки 2-3 недели, чтобы потом выпустить дополнение? Давайте выпускать обновление в тот же день, когда обнаружена и описана ошибка.

По мотивам http://idea.1c-bitrix.ru/7925/

Проблемы при закрытии публичной части:

• невозможность тестировать сайт с пользовательскими правами (только админ)
• невозможность просмотра/тестирования сайта не зарегистрированным пользователем
• невозможность привлекать к разработке сайта сторонних разработчиков (программистов, дизайнеров, верстальщиков, контентщиков, CEOшников). Т.е. невозможность раздавать ограниченные права. А давать всем права админа - это мягко говоря.
  

Предложение:

• при закрытии публичной части дать возможность пользователям с любыми правами просматривать и тестировать сайт в рамках своих полномочий, при условии что они будут логиниться в административной части
• чтобы была возможность тестировать сайт не зарегистрированным пользователям, задавать в настройках доступ незарегистрированного пользователя/ей (можно ограничить количество таких тестеров) только с определенного IP или по маске
  

Как сейчас выглядит лицензия (выжимка):
4.1. Настоящее Соглашение предоставляет право установки (инсталляции), запуска и использования одной копии Программы в рамках ее функциональных возможностей на одном компьютере (ЭВМ). Пользователю Программы (за исключением редакции «Первый сайт») предоставляется право на базе одной копии Программы создать не более двух Сайтов, использующих общее Ядро и базу данных.     Пользователю редакции «Первый сайт» Программы предоставляется право на базе одной копии Программы создать один Сайт.

4.2. Использование Программы для создания на базе одной ее копии более двух Сайтов  (за исключением редакции «Первый сайт») возможно только в случае расширения лицензии на условиях, размещенных на сайте Лицензиара в сети Интернет по адресу www.1c-bitrix.ru, и в п. 6.5 настоящего Соглашения. Создание на базе одной копии Программы редакции «Первый сайт» более одного Сайта возможно только после перехода на другую редакцию Программы.

4.3. Программа может быть временно установлена на дополнительный компьютер (ЭВМ) с целью использования исключительно для работ по разработке, тестированию и/или наполнению Сайта при условии отсутствия любого "внешнего" доступа к ней (в том числе из сети Интернет или извне локальной сети Пользователя). Указанная копия Программы должна быть немедленно удалена после завершения вышеперечисленных работ.

Какие возникают проблемы при этом у покупателя лицензии:

• Пункт 4.1. подходит для рабочего сайта, но не подходит для разработки, т.к. БД одна.
• Пункт 4.3. ограничивает возможности разработки, т.к. во многих проектах разработка ведется постоянно (один рабочий сайт и второй для разработки, БД разные) и нет смысла удалять сайт для разработки после каждого релиза.
• Зачастую, разработка ведется географически распределенной командой, находящейся далеко друг от друга. В этом случае доступ к сайту для разработки необходим всей команде. Но сейчас закрытие публичной части сайта делает невозможным тестирование сайта с любыми правами пользователей, кроме админских. Т.е. невозможно протестировать пользователя без регистрации, с регистрацией и т.п. Фактически, тестирование невозможно. А выкатывать в продакшн не протестированный релиз чревато.
• И даже для просмотра сайта (в случае закрытия публичной части) нужно давать пользователю админские права! Наверно, не нужно объяснять, что это неадекватное решение.
• Используются распределенные системы контроля версий (Git, Mercurial), т.е. существуют еще локальные репозитории у каждого разработчика. Что будет противоречить лицензии.
  

Предлагаю изменить текст лицензии и привести его в соответствие с современными реалиями:

• ограничения внешнего доступа заменить запретом индексации в файле robots.txt
• можно ограничить запретом использования доменных имен
• в п 4.3. "дополнительный компьютер" заменить на "дополнительные компьютеры"
• или предложите свой вариант, чтобы он решал  рассматриваемые вопросы
  

У вас уже огромный продукт - с которым в одиночку вам не вылизать все баги, которых не мало. Считаю, что настало время привлеч партнеров (может даже и клиентов) для отлова багов в системе. Практически всем мы сталкиваемся с багами в системе в своей работе, причем часто это банальные опечатки/помарки из-за которых приходится кастомизировать темлпейты и компоненты.


Лично я готов прям фиксы присылать - в какой строке, что на что следует поменять.

Сейчас все работает через техподдержку - и объясню чем это плохо:
Тот баг что я нашел и применил решение - будет у вас месяцами лежать до воплощения в релиз. А видя этот баг другие ползователи давно бы сами залезли и поправили, или хотя бы увидели, что такая проблема вообще существует, а не сталкивались с ней после того как им о проблеме сказал пользователь спустя пару месяцев.

Выступлю в качестве евангелиста Битрикс...)))Большое количество багов отлавливается как партнёрами, так и клиентами. Некоторые из них решаются самостоятельно. Почему бы за это как-то не вознаграждать тех, кто уже нашёл решение.  

Читать подробнее...