Хочу остановиться на этом важном вопросе отдельно.
[spoiler]
Например, имеем некий модуль, который предоставляет компоненты.
Затем поправили шаблон, при этом добавилось несколько языковых фраз.
Выделенный серым фрагмент кода был добавлен. Обратите внимание, что слово "Да" уже присутствовало ранее в языковом файле.
Перед сборкой обновления надо выделить языковые фразы. Можно это сделать вручную, а можно при помощи
Для этого открываем Шаг 2 "Выделение языковых фраз" и выбираем свой модуль в списке. Он показывает список файлов (за пределами /lang), которые содержат кириллические символы.
Жмем "Продолжить"!
Теперь языковые фразы оказались в языковом файле шаблона. Старые фразы были использованы, а новые дописаны в конец.
Ваши компоненты могут лежать или непосредственно в /intall/components, или в /install/components/<мое пространство имен>.
Поиск языкового файла идет автоматически на основе стандартной структуры компонента 2.0 (комплексные компоненты также поддерживаются).
Теперь переходим к Шагу 4 через меню (третий шаг сборки архива модуля пропускаем).
Он использует дату и версию модуля из файла /install/version.php для сборки обновления.
Если включить соответствующую опцию, эти данные будут обновлены автоматически.
Если были изменены уже установленные компоненты модуля в /bitrix/components, на этом этапе можно автоматически скопировать изменения в модуль.
Тут есть два варианта: если компоненты модуля лежат без указания пространства имен (как в моем примере), то надо указать пространство имен для синхронизации изменений (оно же подставится в код updater.php). Иначе ничего указывать не надо (например, /install/components/bestpartner/news.line).
Обратите внимание, если разработка компонентов велась в публичной части, а языковые фразы не выделены, то надо сначала перейти на шаг 4. Собрать обновление без изменения файла version.php. Потом выделить языковые фразы на шаге 2. И уже после этого вернуться на шаг 4 для окончательной сборки обновления.
Если что-то пошло не так, руками измените дату и версию модуля в файле /install/version.php.
P.S. На счет транслита. Почему транслит режет глаз? Потому что показывает некоторую некомпетентность разработчика. А когда его использует машина - восприятие совсем другое.
Если делается простое и быстрое решение для конечного пользователя, совершенно не важно, какие там ключи в коде для языковых фраз. А для коробочного решения - да, код должен быть хорошо читаем и удобно поддерживаемым.
у функции OnBuildGlobalMenu не хватает проверки прав пользователей,
При авторизации пользователем с минимальными правами и переходе в папку /bitrix/
видно список файлов админа
конечно доступ запрещен, но все же не хотелось бы чтобы кто-нибудь видел админку...
Как вариант в начале функции "OnBuildGlobalMenu" поставить хотя бы
Спасибо, Вам, за полезные модули!
Думаю, мне не стоит объяснять - что громадное количество файлов в модуле достаточно сложно держать в голове, и даже уже при наличии хорошего опыта написания модулей - лазить постоянно по папкам, чтобы найти нужный файл, заметно снижает скорость разработки. А ведь большую часть рутины можно было бы переложить в некие видуальные средства разработки. В частности там же можно было бы задавать названия для языковых констант.
Там же можно было бы сделать более удобной вставку таких элементов, как например, таблица с данными или панель с закладками в административном интерфейсе, ну то есть все встроенные объекты - которые сейчас вставляются исключительно написанием кода (хотя код стандартизирован, но иногда его достаточно много, что ухудшает читабельность файла модуля).
Ну я уже не говорю про какие-то типовые шаблоны.Причем желательно это должно быть не онлайн-решение в виде mp.builder - а некое десктопное приложение. Я например, в большинстве случаев редактирую файлы битрикса минуя встроенные редакторы - десктопными HTML-редакторами. Этим достигается скорость разработки раза в 2 большая, чем если бы я ковырялся в окошках битрикса. Согласитесь, это существенная разница. Но во внешних редакторах не хватает инструментов, делающих разработку на битриксе более удобной.
Писать свою очередную IDE смысла нет. Может быть, как развитие этой темы, плагины для популярных редакторов.
Потому как большинство разработчиков пользуются связкой ftp-клиент + текстовый редактор. Я думаю не мне одному будет интересен выбор ваших разработчиков.
Или например более банальный пример - при редактировании модуля иметь возможность быстро открыть языковый файл к нему - не ковыряясь в дереве файлов.