16.07.2014 07:54:37
Родино Маркелов, должно быть что-то типа этого:
|
|||
|
12.07.2014 08:06:42
Ну или вот адрес от корня - /bitrix/admin/partner_modules.php |
|||
|
11.07.2014 14:26:36
Тимур Шепетовский
|
|||
|
10.07.2014 21:35:09
Серега Абаев, возможно, это поможет -
|
|
|
25.04.2014 09:50:41
|
|||||||
|
10.04.2014 16:19:02
Да, то, что предлагает Екатерина Субботина будет работать - это улучшенная вариация второго пункта.
Но всё равно проблемы с пересортировкой могут возникнуть рано или поздно. |
|
|
10.04.2014 15:01:27
Но у меня для вас плохие новости - при добавлении эти правила сортируются по длине по убыванию, поэтому "#^/catalog/(male)/([^/]+)/.*#" (29 символов) будет всегда после "#^/catalog/([^/]+)/([^/]+)/.*#" (30 символов). Варианта решения три: 1. Прописать правило "#^/catalog/(male)/([^/]+)/.*#" в .htaccess и вообще не обрабатывать такие url в urlrewrite.php 2. Добавить в правило "#^/catalog/(male)/([^/]+)/.*#" пустышек, то есть сделать его длиннее, но при этом не сломать регулярное выражение. 3. Вручную изменить порядок в urlrewrite.php и надеяться, что они внезапно не пересортируются (а они пересортируются). Все три варианта - костыли, спасибо тому, кто решил, что правила нужно сортировать =) |
|||
|
02.10.2013 17:04:43
Это если вам нужно получить значения полей связанных элментов или отфильтровать по ним. Что-то более экзотическое, скорее всего, придется делать руками. |
|||||
|
13.09.2013 19:56:56
Мы храним в корне сайта всю статику, не важно сколько на сайте шаблонов.
Причин несколько: - унификация процесса (верстальщику не нужно думать о том как сайт будет поделен на шаблоны, программисту не нужно вырезать css и js из общего файла и делить по шаблонам) - гораздо проще натравить sass-компилятор, js-минификатор и т.д. на одну директорию, чем на n шаблонов - проще ориентироваться в стилях и скриптах, когда все файлы перед глазами - не нужно дублировать спрайты, используемые в нескольких шаблонах, аналогично с общими скриптами Проблем пока не возникало никаких. На мой взгляд, хранить все в шаблоне имеет смысл по двум причинам - чтобы разработчик всегда знал где искать стили и скрипты (в нашем случае он тоже знает) и чтобы можно было легко и безболезненно копировать шаблоны на другие сайты (пока не приходилось). P.S. Вспомнил третью причину - если в компоненте используется какой-то мелкий скриптик, который сложно будет найти в общем файле скриптов, то его стоит оставить вместе с компонентом для простоты последующей доработки. |
|
|
30.01.2013 06:38:24
Нужно еще иметь ввиду, что кроме контента есть еще языковые файлы компонентов, которые, скорее всего, тоже нужно переводить.
Мы в каждом компоненте завели отдельный файл для каждого языка и подключали его через $this->IncludeComponentLang("/путь/к/файлу", "язык"). На практике поддерживать это очень сложно, по крайней мере в масштабах этого проекта, поэтому хотим перенести все переводимые фразы в один файл и обновлять уже только его. Кастомные свойства инфоблока очень помогли, кстати, в этой задаче - я потратил пару дней, чтобы в них разобраться и написать все обработчики, но теперь создание, настройка и заполнение любого инфоблока на сайте, где требуется перевод - дело нескольких минут. |
|
|
29.01.2013 15:01:04
С многоязычностью все очень печально...
У нас один из сайтов переводится на 10 языков для 11 стран (причем внутри одной страны может быть два-три языка) - пришлось конструировать адскую машину и вставлять костыли во все свои компоненты, а системными вообще не пользоваться. Делать под каждый язык свой домен или шаблон, понятное дело, не вариант. Мы пошли по пути, который описан appar61, только развили его - создали кастомные свойства инфоблоков, позволяющие заводить контент на разных языках в формате текста и html. |
|
|