По моему мнению реализация многоязычности в битриксе реализована плохо, чтобы не сказать хуже. Не скажу, что в других системах ситуация чем-то кардинально отличается, но от используемого инструмента всегда хочется больше.
В битриксе проблема многоязычности сайта решается обычно многосайтовостью, т.к. каждому сайту можно применить только 1 язык. Эта "языковость" сайта проявляется в выборе битриксом папки с переводом фраз у компонента, и как следствие все управляющие интерфейсы так же переводятся на язык сайта. Создание же отдельного сайта, решает проблему статической информации редактируемой на каждой странице и возможности настроить необходимые компоненты по разному. Сам же контент требуется дублировать на других языках либо в дополнительных свойствах либо в других инфоблоках.
В финансово сложных условиях конечно никто не хочет покупать дополнительные лицензии для создания сайтов под каждый язык. Более того, различия сайтов на разных языках отличаются лишь выводимой информацией, сами макеты одни и теже. Поэтому решение в таких случаях, создавать свойства с языковым постфиксом в названии, например, PREVIEW_TEXT_RU, а в шаблоне выводить $arItem["PROPERTIES"]["PREVIEW_TEXT_".strtoupper(LANGUAGE_ID)][ "VALUE"].
Вместо LANGUAGE_ID можно использовать и сохраненный в куку параметр языка либо сам параметр из адреса. Но была бы не полноценная многоязычность если не использовать наборы переводов текстовых строк из коробки. Поэтому тут надо обзавестись модулем для php под названием "runkit". Его придётся компилировать из исходников, потому что пекловская версия устаревшая и подойдет только для php 5.2 и старших версий. Исходники находятся на гитхабе по адресу https://github.com/zenovich/runkit
После того как модуль установлен, можно менять значения констант. УЧТИТЕ, изменение констант – плохой стиль программирования и может привести к плохим последствиям. В своём модуле или файле init.php необходимо подписаться на событие OnPageStart, т.к. перед ним иницилизируются все настройки для сайта и необходимая нам константа. В теле функции, вызывающейся по этому событию необходимо задать правильное значение, например, вот так получив из параметра значение подставляем его в константу:
Это решение позволяет избежат нескольких проблем простых сайтов – дублирование шаблонов и дублирование инфоблоков, а главное удешевить разработку и поддержку сайта.
Для более изящного варианта, можно добавить в тело функции еще определение текущей локали пользователя, я это делал добавив модуль Zend_Locale из zend framework-а.
Еще важно заметить, что битрикс не учитывает обозначения языков принятых в ISO(http://en.wikipedia.org/wiki/List_of_...39-1_codes, поэтому украинский язык определяемый Zend_Locale надо заменять с 'uk'(ISO) на 'ua'(Битрикс).
Да. иногда кажется, что стоит добавить несколько полей в инфоблок и проблема решается, но не все так ласково и гладко. Самым приянтным для меня моментом в Битриксе является все таки файловая составляющая. ленги реализованы. а вот как только доходим до БД... что поделаешь. Обижаться на Битркис за то, что не решают мегахитрую проблемку, востребованную только на N% сайтах (далеко не 100%)? А кто то может предложить ее простое решение вообще? Антон вскрыл только два из проблемных камней преткновения
Антон Долганин в этом решении не стояло задачи почту рассылать на разных языках(та и вообще почта пользовалась крайне редко) и прикреплять поиск по сайту, поэтому и приемлемо было лишь продублировать свойства в 1 инфоблоке, с дополнительным языковым. С почтой думаю можно справиться написав свой обработчик отсылки, который и будет подставлять нужный языковой ключ к ключу свойства инфоблока, а вот с поиском действительно проблема. В любом случае этот вариант подходит когда клиенту очень нужно сэкономить деньги на лицензиях и можно пожертвовать неким функционалом.
Еще пол года назад я не вникал в то, как функционирует ajax в битриксе, компоненты с его поддержкой работали нормально, а те которые не поддерживали можно было кастомизировать с нужным функционалом не сложно. Вариантов как в конечном итоге реализовывать было несколько.
В один момент, мне всё же захотелось реализовать, используя подход самой цмс, и я начал использовать различные битриксовые функции. Не скажу, что от использования этого функционала я получал удовольствие, но оно работало и главное не вносило дополнительных зависимостей и это хорошо.
На днях мне в очередной раз стало необходимо сделать форму логина в отдельном окошке и соответственно это должно работать без перезагрузки. Кастомизировать компонент очень не хотелось, использовать дополнительную страницу, которая бы была контролером для ajax-запросов так же не хотелось. Про дополнительные шаблоны создавать для таких целей по мойму моветон. Поэтому по привычке стал почитывать код битрикса.
Решение оказалось очень простым. Первое, что для меня оказалось новым – компонент принял параметры не объявленные в параметрах AJAX_MODE и AJAX_OPTION_JUMP. И приняв эти параметры – обернул компонент в дополнительный блок div с уникальным атрибутом id. Но по определенным причинам, к форме внутри этого блока не применился скрипт.
Поэтому, вторым шагом было добавления ajax.js в скрипты сайта, это делается вызовом функции CAjax::Init();
Третье, в шаблоне компонента нам осталось добавить к форме событие onSubmit, в котором будем перегружать содержимое того блока, которым обернул битрикс компонент. Это выглядит следующим образом: onsubmit="return jsAjaxUtil.InsertFormDataToNode(this, 'comp_<?=$bxajaxid?>', true);" Значение $bxajaxid динамическое – оно формируется для каждого компонента, и поэтому его надо узнать, перед тем как использовать. В классе CAjax есть для этого функция GetComponentID, первым параметром задаётся имя компонента, вторым – имя шаблона. Если имя шаблона не задано используется значение ".default". И в начале шаблона пишется: <?php $bxajaxid = CAjax::GetComponentID('bitrix:system.auth.form', 'personal'); ?> После чего используется во всех нужных местах.
В конце, надо добавить в форму еще поле: <input type="hidden" name="bxajaxid" value="<?=$bxajaxid?>" />
После этих правок, форма уже будет работать.
И последнее, после того как пользователь авторизировался, необходимо обновить страницу. В возвращаемом стандартном шаблоне предусмотрено простой вывод ссылки "Выход". Тут необходимо вставить: <script>location.reload();</script>. Важно заметить, что в этом случае необходимо не отображать этот компонент для пользователей, которые уже авторизированы, потому что будет перезгружаться страница постоянно.
Вот собственно и всё – 5 строчек не сложного кода и работающий стандартный компонент без каких-либо зависимостей.
Пытаюсь реализовать авторизацию в модальном окне, сайт infera.ru. Модальное окно появляется с помощью fancybox. Но при авторизации сайт появляется в модальном окне.
Владимир Акимов, у Вас контент в FB подгружается как iframe. Открывайте окошко FB как встроенный html с параметром preload (или autoload, не помню уже как в FB этот параметр называется) и перезагрузка будет в корневом фрейме.
Добрый день, все сделала по инструкции, все работает, но: когда я нахожусь в окошке регистрации, ничего не ввожу, нажимаю зарегистрироваться -> появляются ошибки и желтый прямоугольник с загрузкой, который не пропадает, пока не перезагрузишь страницу. Что я могла сделать не так?
Время от времени встречаю феноменальные способы определения главной страницы. Конструкции достигают нескольких строк и переменных. Это очень печалит, особенно когда времени нет разбираться, что же должна содержать переменная $d, после того как её три раза пересобрали из различных параметров и вообще переменная $d - массив.
Я думаю большинство знают, поэтому этот пост всё же к тем кто не знает, эту одну функцию из документации:
<?/* Если мы находимся на главной */?> <? if ($APPLICATION->GetCurPage(false) === '/'): ?> <? endif; ?>
<?/* Если мы НЕ находимся на главной */?> <? if ($APPLICATION->GetCurPage(false) !== '/'): ?> <? endif; ?>
Надеюсь это поможет кому-то не вводить в заблуждение людей, которые будут поддерживать ваш проект в дальнейшем.
Добрый день. Подскажите пожалуйста, если мне нужно использовать для главной и всех остальных страниц разный только header.php. Как мне правильно прописать в header.php, что если сейчас главная страница, то использовать header_index.php, а если нет, то использовать header_inner.php? И соответственно со стилями, подскажите, как мне лучше сделать под разные header? Если разница будет только в высоте и некоторые пункты во внутренних страницах выключены будут? Большое спасибо за ответ!
В битриксе использование этого компонента одно из самых болезненных событий. Увы и самому порой приходится "костылить", а еще хуже поддерживать чужие фильтры. И хоть фильтрация одна из самых необходимых вещей на сайте, я особо не разбирался, что внутри. Вот и начал я своё внедрение красивого фильтра с возможностью фильтровать значения чекбоксами. Хорошая возможность немного расширить кругозор.
Сразу оговорюсь, что на сайте несколько свойств либо списки либо привязка к элементу инфоблока.
Когда-то единственный путь, который я видел это создавать в глобальном массиве $GLOBALS свой фильтр по параметрам из $_GET и далее реализовывать свою логику. Это отличный путь, которым следуют многие и для которого и сейчас есть место для существования. Но программист животное ленивое, поэтому лень берет своё и я продолжаю поиски простых решений.
Первым, что стоит отметить фильтрация в catalog.filter не поддерживает такой ход событий, поэтому надо кастомизировать компонент. А второе - кастомизировать необходимо совсем немного.
Итак, кто не знает, я расскажу что делает фильтр: 1. заполняет массивы данных из $_REQUEST-а или $_SESSION 2. делает выборку свойств инфоблока 3. для каждого свойства, в зависимости от его типа, a. формирует html и, что очень важно, б. заполняет глобальный фильтр!
Так вот это одновременное действие и не позволяет работать фильтрации после изменения шаблона компонента, путём добавления чекбоксов вместо того, что формируется самим компонентом. Конечно если бы разработчики подумали заранее и разделили представление от логики, я думаю подобный компонент был куда более эффективным.
В общем, решение очень простое - формирование шаблона делается в template.php, а вот логику можно подкорректировать тут, подставив:
Это одно нехитрое условие необходимо подставить при обработке свойств типа G и L, после чего компонент с радостью отфильтрует множественные значения свойства.
здравствуйте тоже мучаюсь с выводом чекбоксов в фильтре, если не сложно подскажите куда именно (в какой фаил) на место чего ну подставить это фрагмент и каким кодом нужно потом вызвать чекбоксы у свойства в шаблоне фильтра? спасибо.
что означает, что если задать значение "N" вместо того что по умолчанию "Y", тогда фильтр будет себя вести странно, то бишь не правильно. Данные фильтра будут накапливаться и в итоге выборка будет производится с ошибкой.
Вот такие вот пироги. Видимо разработчики забыли строчку
видимо я таки ошибся с выводом почему не правильное поведение происходит за преждевременные выводы приношу извинения, но тогда вопрос пока остался почему происходит у нас не правильное поведение при выключенном SAVE_IN_SESSION .
Примерно год назад я занимался магазином, благодаря задачам которого я многое узнал о битриксе. И даже внёс идею улучшения одного из системных компонентов. Увы год прошел, а воз и ныне там. Понятное дело у разработчиков битрикса много и так работы, но поддерживая своё решение на сайте, которое не самым лучшим образом вписывается в концепцию системы - обидно.
Уже с давних пор использую отличную связку всплывающих окон и аякс битрикса. В основном для авторизации или каких-то подобных простых действий. И как оказалось, что не сталкивался с подобной проблемой. А проблема заключается в следующем: Есть веб-форма, которая должна появляться во всплывающем окне и обрабатываться без перезагрузки. Сказано - сделано. Вывел компонент, проставил AJAX_MODE, завернул в скрытый div и запустил с функциоей $.fancybox. До этого момента всё отлично работает. Интересное начинается дальше - после того как форма отработала и вернула результат - список ошибок или сообщение, индикатор загрузки добавленный в конец документа не удаляется. Такая странность поведения сразу же заложила во мне сомнение в собственном коде и какое-то время пытался доказать это. В итоге поняв, что я не виноват, а проблему надо быстрее решать пошел по привычке читать код и выводить промежуточную информацию.
Выяснилось, что функция "submitComponentForm" из core_ajax.js вызывается дважды и что самое ужасное второй вызов создаёт индикатор загрузки не прикрепленный к DOM. Это поведение, кстати, не происходит когда форма не выводится через fancybox и важно отметить. Важно отметить как работает плагин fancybox, он переносит необходимую ветку из DOM и вставляет её в свой контейнер. И тут необходимо знать, что находится в переносимой ветке - потому что если это javascript тогда он вызовится снова! А это как видно - чревато. И как раз со стороны битрикса джаваскрипт как раз и вставляется, меня интересует в этом случае, вот эта строчка:
Думаю не стоит объяснять, дальше смысл этого странного поведения. Увы дальнейшие попытки подружить fancybox с битриксом не увенчались успехом и бороться с утечками памяти тоже не хотелось, ведь если забыть очистить лишние обработчики - какой-то зловещий тестер нажав 100500 раз кнопку отправки мог бы загрузить свой браузер, а мне бы этого не хотелось бы допустить Тогда и было решено сделать своё простое всплывающее окошко, без манипуляций с DOM, что и решило эту неприятность.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».