Может быть предлагаю что-то революционное, но прошу рассмотреть возможность увеличения минимальной версии php для работы. Для сохранения обратной совместимости предлагаю начать с версии php5.4
То есть: - В конце 2017 года объявить минимальную поддерживаемую версию - php5.4 - В конце 2018 года отказаться от php5.4 - 5.6 выставив минимальной версию - php 7.0
P.S. А то просто непонятно как так получается - всем рекомендуете перейти на php7.0, при этом в тот же маркетплейс требуете php5.3
Часто для обслуживания сайта требуется использование рутинных скриптов, которые используются лишь время от времени, а потому забываются, но каждый раз писать их где-то, потом находить сложно. Если бы заготовки хранились прямо на сайте, это было бы удобно.
Предлагаю добавить возможность писать модули только с определёнными версиями php. Например, модуль может работать только в php >5.5.
Надоело просто писать array() вместо [] и хочется использовать новые возможности языка. Я думаю, все адекватные люди следят за актуальность версий php на своих серверах и кастомизируют сайты использяю последние возможности php.
Для PHP на https://packagist.org/statistics выложено уже порядка 100 тысяч (!) библиотек, компонентов, бандлов и фреймворков. При разработке проектов, в том числе на Битриксе логично использовать готовые решения, если они помогают в решения задачи. Все подобные пакеты ставятся через Composer, который генерирует файл autoload.php в соответствии с PSR-0.
Для разработчиков было бы большим подспорьем, если бы битрикс уже шел с composer.json и поддержкой автозагрузки вендорных библиотек, чтобы можно было легко подключать опенсорсные решения в проект.
На официальном сайте 1С-Битрикс уже давно висит заметка о правилах написания исходного кода. http://dev.1c-bitrix.ru/docs/php_recommendation.php Будем откровенны - следуют им далеко не все программисты. Не раз видел такой сайт-чудище Франкенштейна - сколько программистов - столько и стилей расставления {}, отступов и наименований.
Как же заставить всех следовать правилам? Мои идеи: 1) Ввести в монитор качества тест, который проверял бы оформление всего php-кода в папках local, bitrix/templates, bitrix/php_interface. Хочешь-не хочешь, а люди начнут вспоминать про существование этих правил. 2) В маркетплейсе ввести аналогичную проверку для загружаемых решений. По результату проверки либо совсем запрещать публикацию модуля, либо как-то визуально выделять в маркетплейсе такие решения. Например, если решение прошло проверку на оформление кода, добавлять бейджик "100% следование стандарту" (метод пряника) или наоборот. (метод кнута).
Уже на протяжении нескольких лет партнеры молча страдают из-за этого жесткого требования от Bitrix - не всегда есть возможность применить данную конфигурацию на хостинге клиента.
Разработчики, которые хоть когда-нибудь работали с библиотекой PHPExcel для обработки операций с XLS помнят, какой это тяжелый труд - переводить весь сайт с UTF-8 на WINDOWS-1251 только из-за того, что эта библиотека не работает с mbstring.func_overload. Или воовсе приходилось отказываться от работы с XLS.
Итак, когда разработчики Symfony ввели требование не поддерживать mbstring.func_overload - это полностью сломало совместимость рабочего окружения Bitrix и всех инструментов, которые используют в своей базе те или иные компоненты от Symfony.
Я понимаю. Сделать это изменение сейчас - не представляется возможным, так как уже есть куча клиентов у которых заинтегрированны алгоритмы с использованием mbstring.func_overload.
Но скоро будет выпуск php7, который итак сломает весь код клиентов. Я предлагаю включить это изменение в релиз Bitrix, который будет работать с php7 (если таковой вообще планируется).
В будущем я собираюсь призывать PHP-сообщество к запрету и удалению функционала mbstring.func_overload. Даже сами разработчики PHP пишут:
Не рекомендуется использовать перегрузку функций в контексте поддиректорий, так как добиться стабильной работы в этом случае пока не удалось, и это может привести к неожидаемому поведению приложения.
Доступны дистрибутивы 20.5.393. Для существующих проектов - выпущены или тестируются обновления модулей (за исключением модуля compression - снят с использования, необходимо удалить).
Вы внедрили замечательный механизм ORM, благодаря которому создавать свои сущности стало очень просто (с точки зрения программиста). Но раз вы разработали "стандарт" ORM для Битрикса, может, сделаете и набор стандартных компонентов для работы с ним (список записей, страница записи, добавление записи)? В том числе и стандартные страницы для админки со списком записей, фильтром, страницей редактирования записи.
В файле \bitrix\modules\main\classes\general\module.php есть код
if (!function_exists("__autoload"))
{
function __autoload($className)
{
CModule::RequireAutoloadClass($className);
}
define("NO_BITRIX_AUTOLOAD", False);
}
else
{
define("NO_BITRIX_AUTOLOAD", True);
}
Так вот функцию __autoload лучше заменить на spl_autoload_register. Таким образом появляется возможность добавлять свои автолоадеры без перерегистрации стандартного битрикса.
Сейчас в веб окружении используются «консервативные» версии софта. MySQL 5.0.51, PHP 5.2.6, eAccelerator 0.9.5. Apache 2.2.8,
Оно используется для тестов.
Пакет «Битрикс: Веб-окружение» удобно использовать для тестирования демо-версий продукта. Удобный и понятный мастер автоматически установит все, что необходимо для работы с продуктом
Почему бы не включать в него последние стабильные версии?
У БУС есть возможность при работе системы обновления запрашивать версию PHP и MySQLЯ считаю, что статистику по использованию версий ПО на активных лицензиях показывать надо для разработчиков маркетплейса. Например - в карточке партнёра.
Так мы будем видеть, что имеет уже смысл вести разработку с учётом новых версий ПО.
Максим, для партнерской системы обновлений такая информация сейчас не собирается. Подумаем над этим или, возможно, будем публиковать общую информацию по используемым версиям ПО клиентов. Спасибо.