В документации по вебсокетам в php указанно, что можно работать асинхронно ( ), однако в классе httpClient нет такой возможности.
Просьба добавить.
Просьба добавить.
Сейчас нужно перечислять все поля в секции 'select':
Было бы удобнее делать как-то так:
$query->addSelect(array('*', 'UF_FILE', 'UF_SAMPLE', ....)); |
Было бы удобнее делать как-то так:
$query->addSelect(array('*', 'UF_*')); |
Идея разрешить и поощрять пользователей создавать документацию.
Сейчас, чтобы почитать по d7 нужно читать курсы, потом еще гуглить сайт, форум/блоги.
Из-за этого много информации которую ищешь, просто не читаешь. А это сильно тормозит саморазвитие и увеличение навыков.
Если весь опыт будет в одном месте, уверен это очень сильно всем поможет.
Чтобы пользователи размещали именно в документацию, нужно их стимулировать бонусами.
Размещение информации - премодерируемое.
Создать свод правил по которым нужно размещать документацию.
В документации создать перелинковку с курсами.
Сейчас, чтобы почитать по d7 нужно читать курсы, потом еще гуглить сайт, форум/блоги.
Из-за этого много информации которую ищешь, просто не читаешь. А это сильно тормозит саморазвитие и увеличение навыков.
Если весь опыт будет в одном месте, уверен это очень сильно всем поможет.
Чтобы пользователи размещали именно в документацию, нужно их стимулировать бонусами.
Размещение информации - премодерируемое.
Создать свод правил по которым нужно размещать документацию.
В документации создать перелинковку с курсами.
Добрый день.
Хотелось бы "из коробки" получить возможность составлять SQL запросы для полей типа JSON в MySQL 5.7
По аналогии с
Хотелось бы "из коробки" получить возможность составлять SQL запросы для полей типа JSON в MySQL 5.7
По аналогии с
ar, ob, db по-моему только мусор добавляют а не читабельность.
Массивы следует именовать с префиксом ar, при этом следующее логическое слово в названии начинается с большой буквы. Например, $arResult, $arModifiedUsers.
Объекты следует именовать с префиксом ob, при этом следующее логическое слово в названии начинается с большой буквы. Например, $obElement, $obUser.
Объект класса следует начинать с префикса db, при этом следующее логическое слово в названии начинается с большой буквы. Например, $dbResult.
Массивы следует именовать с префиксом ar, при этом следующее логическое слово в названии начинается с большой буквы. Например, $arResult, $arModifiedUsers.
Объекты следует именовать с префиксом ob, при этом следующее логическое слово в названии начинается с большой буквы. Например, $obElement, $obUser.
Объект класса следует начинать с префикса db, при этом следующее логическое слово в названии начинается с большой буквы. Например, $dbResult.
Идея уже была высказана несколькими годами ранее:
Но она не получила достойного обсуждения поддержки. Но ввиду последних событий, а именно - было принято решение возобновить обращение к Bitrix-разработчикам.
Уже на протяжении нескольких лет партнеры молча страдают из-за этого жесткого требования от Bitrix - не всегда есть возможность применить данную конфигурацию на хостинге клиента.
Разработчики, которые хоть когда-нибудь работали с библиотекой для обработки операций с 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 пишут:
Но она не получила достойного обсуждения поддержки. Но ввиду последних событий, а именно - было принято решение возобновить обращение к Bitrix-разработчикам.
Уже на протяжении нескольких лет партнеры молча страдают из-за этого жесткого требования от Bitrix - не всегда есть возможность применить данную конфигурацию на хостинге клиента.
Разработчики, которые хоть когда-нибудь работали с библиотекой для обработки операций с 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 пишут:
| Не рекомендуется использовать перегрузку функций в контексте поддиректорий, так как добиться стабильной работы в этом случае пока не удалось, и это может привести к неожидаемому поведению приложения. |
Ответил 
Жуков Евгений 22.09.2020 16:01:50
Жуков Евгений 22.09.2020 16:01:50
Доступны дистрибутивы 20.5.393. Для существующих проектов - выпущены или тестируются обновления модулей (за исключением модуля compression - снят с использования, необходимо удалить).
У нас в веб-студии есть определененный стандарт: все обработчики хранятся в модулях в папке lib/eventhandlers/<код модуля, чье событие обрабатывается>.php
Внутри - класс с методами, чьи имена совпадают с названиями событий. Т.е. для события onBeforeUserLogin модуля main обработчик будет такой:
\Intervolga\Diving\EventHandlers\Main :: onBeforeUserLogin
Ситуацию усложняет только необходимость подключения этих обработчиков в include.php файле модуля.
Ничего не напоминает? Когда-то у нас была куча include'ов обычных классов и появился спситель - автозагрузчик D7. Может, сделаете аналогичную автозагрузку обработчиков событий?
Внутри - класс с методами, чьи имена совпадают с названиями событий. Т.е. для события onBeforeUserLogin модуля main обработчик будет такой:
\Intervolga\Diving\EventHandlers\Main :: onBeforeUserLogin
Ситуацию усложняет только необходимость подключения этих обработчиков в include.php файле модуля.
Ничего не напоминает? Когда-то у нас была куча include'ов обычных классов и появился спситель - автозагрузчик D7. Может, сделаете аналогичную автозагрузку обработчиков событий?
Считаю, что использование глобальных переменных во всех методах компонента не самый лучший подход (пример проблемы с SITE_ID в компоненте).
Для подробного изучения ядра D7 и переработки старых наработок на новое ядро было бы очень полезно, если бы в действующем Api были примеры, как тоже самое написать, используя новое ядро
Прошу добавить метод modify(), наследуемый от \DateTime в
\Bitrix\Main\Type\Date (\bitrix\modules\main\lib\type\date.php)
\Bitrix\Main\Type\Date (\bitrix\modules\main\lib\type\date.php)
© 2001-2021 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
Под каждой из страниц есть форма для добавления, даже в новой доке по D7. Пишите, никто же не против.
Бонусы - никогда не были против раздачи баллов по партнёрской программе. Более того, давали и раздавали такие бонусы за реальную помощь.
Деньгами - это уже сложнее. Не уверен, что такая идея получит поддержку у руководства.
Свод правил - не нужен, не нужно вам забивать голову стилями, оформлением и так далее. Просто выдайте то, что считаете нужным. Мы сами и отсеем и оформим.
Если нет страниц, куда надо добавить, просто шлите информацию на мой e-mail и она отобразится в курсах, документации.
Перелинковка доки и курсов - есть, может не везде и не туда, это возможно. Но для этого и создано поле для комментариев. Пишите, добавим линки.
Для донесения полезной информации до нас есть все инструменты. Вопрос в самой информации. Помниться, после того как появилось поле для комментариев, мы создали по просьбам пользователей пустые страницы в доке по неописанным методам, чтобы была возможность добавлять комментарии по этим методам. Помниться даже наполнили с десяток страниц. Но и всё, сейчас дело заглохло.
Идею с голосования снимаю, не надо придумывать какие-то дополнительные механизмы.