В простейшем варианте организации командной работы над проектом нам необходим — один основной сайт на сервере — будем называть его продакшеном, один сайт для тестирования (девелоперский сайт) — на сервере рядом с ним (дев. сайт) + по локальной копии сайта у каждого разработчика. (Девелоперских сайтов на сервере может быть несколько, но по поводу дополнительных дев. сайтов необходимо предварительно консультироваться с технической поддержкой Битрикс по поводу правомерности такой системы с точки зрения лицензионного договора).
Каждый разработчик будет работать над проектом в своей локальной копии сайта, в отдельной ветке Git для каждой решаемой задачи. В конце дня каждый разработчик делает коммит в репозиторий, хранящийся на github.com и только один разработчик — ведущий, проверяет и объединяет ветки сначала на девелоперском сайте на сервере, а потом выкатывает полученный результат на продакшен. (По моему субъективному мнению, двоевластие на интернет-проекте — недопустимо. Даже если слияние веток и тестирование будет отнимать все рабочее время ведущего разработчика проекта — никто кроме него не должен вносить изменения на продакшен — сайт) В начале дня — разработчики обновляют свои репозитории с гитхаба.
В случае, когда необходимо изменение структуры БД, разработчики сначала вносят изменения в своих локальных копиях, пишут список изменений ведущему разработчику, ведущий разработчик вносит их на продакшене, делает бекап БД продакшена, который затем накатывается на дев-сайт и на все локальные дев-сайты. Дополнительно настраивается репликация БД (но это уже тема для другой статьи).
Итак, мы имеем выделенный сервер, два настроенных виртуальных хоста и установленное серверное ПО git — это, как правило, могут сделать для нас сотрудники хостинга, на котором мы покупаем сервер.
В директории основного сайта разворачиваем бекап сайта стандартными средствами Битрикс (или руками), директория девелоперского сайта пока пусть будет пустой.
Регистириуем корпоративный тариф на github.com Для системы, рассмотренной в данной статье, нам хватит тарифа за 25$ в месяц. Заводим приватный репозиторий, добавляем существующих пользователей githab к организации (или заводим новых пользователей) — это все делается очень прозрачно и удобно, поэтому не будем подробно заостряться на этом моменте.
После того, как корпоративный приватный репозиторий заведен, нам нужно сделать первый коммит в него.
Заходим по ssh на наш сервер под пользователем с правами на запись в папки сайтов, переходим в директорию, в которой мы намерены инициировать репозиторий.
Репозиторий можно инициировать непосредственно в папке сайта (тогда важно не забыть потом защитить папку .git в файле .htaccess от скачивания), а можно инициировать его в наддиректории (вариант, когда файлы каждого сайта лежат не сразу в директории www или директории dev, а в подкатологе, к примеру, dev/httpfiles, www/httpfiles А репозитории мы инициируем соответственно в директориях www и dev. Если сервер настраивается с нуля или если админу не лень перепрописать виртуальные хосты— этот вариант предпочтительнее).
Перед тем, как инициировать репозиторий для основного сайта, необходимо определиться, какие папки и файлы необходимо включать в репозиторий, а какие — нет — сформировать файл .gitignore.
Пример (упрощенный) файла .gitignore для 1С-Битрикс для случая, когда репозиторий инициируется в директории сайта:
То есть мы не будем контролировать изменения в папке бекапов (/bitrix/backup), папках кеша (/bitrix/cache, /bitrix/managed_cache, /bitrix/managed_flags, /bitrix/stack_cache), папках с заданиями крону (/bitrix/crontab), папке с логами (/logs), папке с загрузками (/upload). Папку с загрузками /upload на всех девелоперских копиях сайта, расположенных на одном с ним сервере, имеет смысл делать симлинком на папку /upload продакшен-сайта.
Символическую ссылку в директории /dev/ — корневой директории девелоперского сайта создаем командой
ln -s /path/to/www/upload
К слову о символических ссылках. При конфигурировании многосайтовой системы на одном ядре 1С-Битрикс по 2му типу, папку bitrix мы так же должны будем исключить из основного репозитория. Потому что физически эта директория будет существовать только на одном сайте системы, а на других — будут символические ссылки на нее. Но так как контролировать изменения файлов этой папки все равно нужно, целесообразно будет завести для нее отдельный репозиторий.
Файл /bitrix/php_interface/dbconn.php содержит индивидуальные для каждого виртуального хоста настройки (в частности настройки соединения с БД), поэтому этот файл мы добавляем в исключения git.
Файл /urlrewrite.php — это файл с правилами обработки ЧПУ адресов Битрикс — он может быть перезаписан (сортируется внутри) самим движком, поэтому исключим и его.
Файлы .gitignore и .htaccess тоже должны лежать в исключениях. В исключения так же стоит добавить файлы логов, текстовые файлы, xml-файлы – все то, что не относится непосредственно к программному коду.
После того, как мы определились с содержимым .gitignore и создали файл .gitignore в директории будущего репозитория можно инициировать репозиторий для продакшен-сайта. Для этого нам сначала необходимо позаботиться об авторизации нашего серверного ssh-пользователя на githab — сгенерировать для него ключ.
Выполняем команду
ssh-keygen -t rsa -C "bitrix@имя.сайта"
email можно вписать любой, но с email вида bitrix@имя.сайта легче идентифицировать ключ на гитхабе.
Переходим на github.com/settings/ssh и добавляем новый ключ — данные самого ключа берём из файла /path/to/.ssh/id_rsa.pub
Проверяем подключение:
ssh-T git@github.com
Инициируем репозиторий в директории основного сайта (или в наддиректории): переходим в /path/to/www/ и выполняем команды:
После того, как репозиторий для основного сайта инициирован, зальем все файлы проекта в репозиторий гитхаб:
git add . git commit -m “second commit” git push
Теперь клонируем репозиторий в директорию девелоперского сайта:
git clone git@github.com:организация/имя_репо.git dev
После этого в директории девелоперского сайта создадим символическую ссылку на папку upload как было описано выше. Затем стандартными средства Битрикс сделаем бекап БД основного сайта, и развернем его на девелоперском — файл, хранящий подключение к БД при этом создастся для дев сайта автоматически.
Теперь аналогичным образом можно создать клоны репозитория на локальных машинах разработчиков. Для этого им необходимо поставить любой комплект ПО git на свою локальную машину (командная Git строка идет в любом комплекте), запустить командную строку, сгенерировать ключ, добавить его на гитхаб, клонировать репозиторий в директорию виртуального хоста на локальной машине, а папку upload просто слить с основного сайта, накатить дамп БД с основного сайта.
После этого можно расслабиться и наслаждаться командной работой, выстраивая с коллегами дружеские отношения без ссор и споров, оперативно откатывая некорректные изменения — без поиска виноватых.
P/S: с некоторых пор я предпочитаю гитхабу битбукет
но по поводу дополнительных дев. сайтов необходимо предварительно консультироваться с технической поддержкой Битрикс по поводу правомерности такой системы с точки зрения лицензионного договора).
Кто - то консультировался? Так можно делать? Может надо какое - то письмо им писать или есть уже стандартная процедура?
Задача интеграции магазинов на Битрикс с несколькими информационными базами 1С Предприятие - возникает достаточно часто. Например, когда необходимо настроить работу 2х и больше интернет-магазинов на одном ядре Битрикс или в случае, когда каталог магазина должен наполняться товарами от разных поставщиков. На данную тему написано не мало статей, и я не буду подробно останавливаться на общей технологии настройки обмена в данном случае. Напомню, как делают:
Как вариант: создают несколько копий файлов http://<сайт>/bitrix/admin/1c_import.php и http://<сайт>/bitrix/admin/1c_exchange.php , а затем в настройках со стороны 1с прописывают для каждой базы свой путь.
А дальше и возникают некоторые проблемы, перед которыми пасуют многие разработчики. Дело в том, что если просто сделать несколько копий скриптов обмена, каждая база сможет отдавать свои товары на сайт, но нельзя будет запустить обмен данными из нескольких баз одновременно. Часто эту проблему можно решить, настроив расписание запуска обмена на стороне 1С. Но вот однажды я столкнулась с ситуаций, когда клиенту было необходимо загружать товары из 9ти информационных баз, каталог товаров в каждой базе был обширным, и клиенту хотелось, чтобы данные об остатках товаров на складах передавались на сайт как можно чаще. В этой ситуации было не обойтись без одновременного импорта товаров из нескольких информационных баз.
И тогда я подумала: "Не может быть, чтобы для Битикс было невозможно это сделать. Разработчики должны были предусмотреть возможность для этого". Я скопировала компонент catalog.import.1c в свою область видимости и занялась его кастомизацией.
Первое, что бросилось мне в глаза в исходном коде компонента – это вот это строка №374
$rs = $DB->Query("sel ect count(*) C fr om b_xml_tree where PARENT_ID = ".intval($NS["XML_ELEMENTS_PARENT"]));
Здесь явно прописано имя временной таблицы, куда в процессе импорта загружается xml файл, пришедший от 1с. Естественно, если несколько баз одновременно начнут писать свои данные в одну и ту же таблицу – импорт не пройдет корректно. Поэтому я добавила к своему кастомизированному компоненту новый параметр IB_ID – уникальный идентификатор, чтобы иметь возможность разнести процесс импорта из разных баз по разным временным таблицам, и переписала эту строку следующим образом:
$rs = $DB->Query("select count(*) C fr om b_xml_tree”. $arParams["IB_ID"].” wh ere PARENT_ID = ".intval($NS["XML_ELEMENTS_PARENT"]));
Но это еще не все: имя таблицы b_xml_tree прописано в качестве параметра по-умолчанию в конструкторах вот этих двух классов: CIBlockCMLImport и CIBlockXMLFile
Но при создании объектов этих классов в компоненте можно передать им другое имя таблицы. В стандартном компоненте написано так: (не в одном месте)
После этого я подключила свой кастомизированный компонент в скрипте импорта вместо стандартного. 1С программист из IT отдела клиента придумал, как сделать мой метод красивее: вместо того чтобы создавать несколько файлов импорта, я создала один, а параметр IB_ID 1C Программист передал в GET – запросе, кастомизировав 1С обработку на своей стороне.
Но если нет возможности передать этот параметр из 1С, можно просто создать несколько файлов импорта, в каждом из них указать при подключении компонента импорта любой придуманный IB_ID – главное, чтобы для каждого файла, он был уникальным, и указать в каждой информационной базе путь к своему скрипту импорта. После этого импорт каталога из 1С Предприятия в Битрикс может идти одновременно из нескольких информационных баз.
Данное решение было внедрено мной в ЗАО «ИСТОК» http://www.istoksochi.ru/ Для этого же интернет-магазина, мною был кастомизирован и компонент экспорта заказов из Битрикса в 1С для того, чтобы каждая база могла забирать с сайта свои заказы. Возможно, я напишу об этом подробнее в одном из будущих постов.
С детства я очень везучий человек - это передо мной не открываются автоматические двери, это я всегда вытягиваю число 13 при любой жеребьевке и это я сажусь на единственный сломанный стул из множества. Поэтому, когда я внедряю какой-либо программный продукт, обстоятельства обязательно складываются так, что всплывают, если не все его "баги" и "фичи", то добрые 90%. Я уже привыкла к этому - и это делает мою жизнь похожей на фильм.
Мое сказочное везение не подвело меня и на моем недавнем внедрении коробки Битрикс24. Внедряла в строительной компании средней величины. Пользователей AD (Active Directory) около 400 человек, и 105 из них являются так же пользователями корпортала, остальным корпортал для работы не нужен.
Как известно, корпортал коробка лицензируется по количеству активных пользователей, поэтому импортировать в портал лишних пользователей было нельзя. Это обстоятельство в корпортативном портале Битрикс24, слава богу, предусмотрено - в настройках AD/LDAP интеграции можно исключить определенные группы пользователей AD из импорта. Исключили, пользователи синхронизировались отлично, однако структура компании построилась не правильно:
Присутствовали пустые департаменты, у пользователей - тесок - перемешались подчиненные, а один отдел был создан 2 раза.
Стала разбираться, вставлять отладочные скрипты, писать в техническую поддержку и даже Юрию Волошину (спасибо ему за оперативные ответы).
Оказалось, что с тесками - известный баг, а у меня - первый такой реальный случай в истории. (Хотя это странно. Полные тески на руководящих должностях - далеко не редкость, особенно, когда они - отец и сын. Когда я работала в одном из подразделений РЖД, у нас там чуть ли не у каждого крупного начальника был сын, названный в честь отца, работающий начальником помельче. Мы обычно называли их между собой "старший" и "младший", но ведь в документах так писать не будешь, поэтому программное обеспечение должно предусматривать такие случаи).
С тесками мы расправились, добавив пробел к имени одного из них на стороне AD.
Дальше - интереснее. Стала я отлаживать скрипт импорта пользователей из AD, и поняла, от куда появляются пустые департаменты. Это департаменты, в которых работают пользователи, которые входят в те группы AD, которые в настройках интеграции записаны в исключения.
Дело в том, что до импорта каждого пользователя под него создается раздел в структуре компании, и только потом, когда пользователь уже непосредственно импортируется происходит проверка на его вхождение в группы - исключения. Этот момент я кастомизировала.
Скопировала скрипт /bitrix/modules/main/admin/user_import.php, переименовала его в user_customimport.php, в скрипте /bitrix/admin/user_import.php подключила свой скрипт вместо стандартного. Глубоко переписывать алгоритм не стала - просто вставила после импорта всех пользователей удаление пустых департаментов:
Вместо одного отдела ITC упорно создавались 2, сколько мы ни перепроверяли на стороне AD заполненность менеджеров и департаментов для каждого пользователя по всей иерархии. Да. на каком-то этапе мы с админом нашли множество ошибок на стороне AD, но их исправление так и не повлияло на импорт структуры.
Тогда в своем скрипте импорта пользователей я завела класс-наследник
class CLDAPCustom extends CLDAP
{...}
И переопределила функцию GetDepartmentIdForADUser функция бешеная - нечитабельная, а кроме того - рекурсивная, легче умереть, чем ее отладить, поэтому я просто изменила механизм проверки перед вставкой нового департамента. В оригинале поиск совпадения департамента велся только в определенном поддереве (а искало, как показала отладка, не в том поддереве, почему - так и осталось не ясно). Так как в моей компании все подразделения названы уникальными именами, сделала, чтобы искало совпадение по всей структуре.
В итоге структура департаментов из AD все же импортировалась в том виде, как должна была быть.
На самом деле получилось все равно не так, как было задумано. В компании есть департаменты, в которых нет начальника, а все сотрудники - равноправны и подчиняются напрямую сотруднику другого отдела. Система же в таких случаях "назначает" департаменту случайного руководителя. С этим решили смириться, техподдержка Битрикс пообещала учесть это как пожелание при будущих обновлениях продукта.
Во время моей учебы в университете СИАОД казался мне скучнейшим предметом. Мы лежали на партах и не знали, куда себя девать, считая секунды до конца. Спустя годы я понимаю, что должна быть благодарна нашему преподавателю, который не позволял нам пропускать свои заунылые лекции. Потому что, занимаясь оптимизацией web-проектов на битрикс, я сплошь и рядом вижу ситуации, когда незнание такого простого алгоритма, как обход естественного дерева, вынуждает разработчиков делать лишние запросы к базе данных.
Естественное дерево - это направленный граф, каждый узел которого может содержать неограниченное число потомков. Разделы инфоблока в Битрикс с их неограниченной вложенностью по факту представляют собой естественное дерево.
В исходниках типового древовидного меню Битрикс мы можем видеть один из алгоритмов обхода естественного дерева, но он мне, честно говоря, не очень нравится - он не достаточно нагляден и не очень гибок. Мои стажеры испытывают трудности, когда им нужно видоизменить этот алгоритм. Поэтому я хочу описать другой - самый простой, на мой взгляд.
Сначала я выбираю все активные разделы из инфоблока
Многие думают, что функция CIBlockSection::GetTreeList или CIBlockSection::GetList с сортировкой "left_margin"=>"asc" сразу возвращает нам дерево. Но она возвращает не дерево, а один из вариантов его обхода. Хорошо, если этот обход совпадает с тем путем, по которому вам нужно обойти дерево, но часто нужно обойти его в другом порядке. В массиве же $map каждый потомок содержит ссылку на предка, но предок не содержит ссылок на потомков.
В массиве $map сейчас потомки идут сразу за своими предками - то есть прямой ссылки нет - она определяется порядком следования элементов в массиве. Да, можно обойти дерево как угодно и в этом его представлении - примеров в исходниках Битрикс - масса. Но это, как я уже говорила - громоздкие алгоритмы. Поэтому я преобразую дерево к другому очень удобному для работы виду - гроздьями.
В массиве $arResult['MAP'] у нас естественное дерево в виде гроздей - каждый предок содержит ссылки на своих потомков. Вот к нему мы уже можем применять классические алгоритмы работы с деревьями в их неизменном виде.
Функция рекурсивного обхода такого дерева будет выглядеть следующим образом:
if (count($category_arr[$value["ID"]]['CHILDS'])>0){ //Рекурсивно вызываем эту же функцию, но с новым $parent_id outTree($category_arr,$value["ID"]); } else{ //Выводим листик }
}
}
}
Теперь для того, чтобы вывести ветку дерева, начиная с любого узла $id_uzla достаточно написать:
outTree($arResult['MAP'],$id_uzla);
то есть мы можем выводить ветки дерева в любом порядке, в каком они нужны нам в шаблоне.
В практическом плане. Данный метод (с несколькими модификациями, естественно) я использовала для представления иерархии каталога товаров в виде вот таких вложенных закладочек. И вложенность там ничем не ограничена (только фантазией дизайнера).
Обращение к базе - только единожды (одна функция CIBlockSection::GetList) - и все построено на результатах ее работы. Работающий пример тоже покажу - ближе к запуску проекта, для которого писала это.
Наконец-то хоть кто-то решил эту проблему. Спасибо за код, несколько часов не могу нормально дерево построить относительно родителя, хотя с битриксом работаю давно. Не думал что тут это так проблематично
Помогая своим близким друзьям делать интернет магазин, я столкнулась с задачей импорта данных в Битрикс из формата YML (из формата файлов, который обычно применяется для экспорта в Яндекс.Маркет). За деньги, наверное, не согласилась бы писать такой импорт. А по дружбе – святое дело, и я стала копать. И очень интересные вещи накопала, которые, как ни странно, слабо освещены в документации 1С Битрикс.
А вещи элементарные на самом деле. Оказывается, чтобы добавить возможность собственного импорта в магазин на Битрикс, достаточно добавить в директорию
bitrix/php_interface/include/catalog_import
Два файла
имя_нового _импорта_setup.php – с настройками импорта имя_нового _импорта _run.php – собственно импорт
И у них должен быть именно такой формат имен, как я указала выше – иначе не получится.
После того, как эти 2 файла добавлены, система САМА добавит новый вид импорта в админку на страницу импорта товаров в магазин (/bitrix/admin/cat_import_setup.php) – пометила на рисунке зеленой стрелочке.
А вот оранжевой стрелочкой я пометила результат своего эксперимента с функцией CCatalogImport::Add Страница с документацией по этой функции пока практически пуста, но, читая код ядра, я поняла, что она применяется для добавления нового профиля для того или иного вида импорта, позволяет добавить его в меню или посадить на крон.
На данный момент мой модуль импорта данных из YML практически готов, и я допиливаю его для публикации в Маркетплейс.
Благодарю, как раз в тему заметка пришлась для экспорта!)
Может, кому-то ещё такой момент пригодиться: у Яндекса если в YML стоит available="true"
<offer id="1677" available="true">
То в каталоге будет выведено "В наличии", а если
<offer id="1677" available="false">
то будет выведено "Под заказ". Однако, если у вас товар закончился и больше не предвидится пока, и вы не работаете с предзаказом - то вам нужно выводить фразу "Нет в наличии", а для этого в аттрибует available нужно не передавать ничего:
Вот такую веселую ошибку при обмене заказами могут наблюдать Битрикс-администараторы, накатившие свежие обновления на Битрикс, но не обновившие модуль обмена на стороне 1С
Обмен заказами начинается с того, что 1С посылает http-запрос вместе с http-авторизацией следующего вида: http://<сайт>/bitrix/admin/1c_exchange.php?type=sale&mode=checkauth
На этот запрос система 1С-Битрикс отвечает тремя строками (используется разделитель строк "\n";):
слово "success";
имя Cookie;
значение Cookie.
Примечание: все последующие запросы к 1С-Битрикс сопровождаются выставлением со стороны 1С имени и значения Cookie, полученными по команде "checkauth".
Далее следует запрос 1С вида: http://<сайт>/bitrix/admin/1c_exchange.php?type=sale&mode=init
В ответ 1С-Битрикс выдает две строчки:
zip=yes, если сервер поддерживает обмен в zip-формате. В этом случае файлы на следующем шаге должны быть упакованы в zip-формате или zip=no, в таком случае файлы не должны быть упакованы, а передаются каждый по отдельности.
file_limit=<число>, где <число> - максимально допустимый размер файла в байтах для передачи за один запрос. Если размер файла больше, то он должен быть порезан на части.
Затем отправляется запрос вида: http://<сайт>/bitrix/admin/1c_exchange.php?type=sale&mode=query
Сайт отдает заказы в формате CML 2. В случае успешного получения и записи заказов в 1С совершается запрос вида: http://<сайт>/bitrix/admin/1c_exchange.php?type=sale&mode=success
Затем из 1С отправляется запрос вида: http://<сайт>/bitrix/admin/1c_exchange.php?type=sale&mode=file&filename=<имя файла> который загружает на сервер файл обмена, посылая содержимое файла в виде POST.
Конечно, странно, что сейчас битриксоиды полностью отказались от поддержки модуля обмена, который идет в 1С УТ 11 без дополнений
Что делать, если такое произошло на вашем проекте с ранее настроенной интеграцией? Конечно, если интеграция вашего сайта сделана без кастомизации на стороне 1С, проще всего накатить на 1С свежее битриксовое дополнение. Что же делать, если модуль обмена на стороне 1С у вас кастомизирован, и в ваши планы сейчас не входит делать всю работу на стороне 1С заново на основе нового модуля обмена (а ее придется делать заново – изменения модуля обмена глубоки, и обычным слиянием с использованием 1С-совской системы контроля версий тут не обойдешься - проверила), тогда проще использовать на стороне сайта модуль обмена, выдранный из старой версии Битрикс.
Я думаю, каждый, кто захочет сделать себе деградацию модуля обмена на стороне Битрикс – сделает ее. А я сейчас расскажу, как сделать, чтобы ваш модуль обмена на стороне сайта был зафиксирован, никогда не обновлялся, не преподносил сюрпризов вашей кастомной 1С-ке при сохранении возможности обновления всех остальных модулей.
Идем в папку /bitrix/components/bitrix/ (на сайте, на котором обмен уже настроен и версия обмена вас устраивает) и копируем компоненты обмена
в свое пространство имен. Соответсвенно я копирую их в папку
/local/components/bedrosova/
Далее нам необходимо скопировать классы обмена. Мы не будем их наследовать в этот раз, а сделаем копии. Заводим свой файлик, не важно по сути, где он будет лежать и как называться, к примеру, можно положить его в /local/php_interface/lib/exchange.php
Открываем файл /www/bitrix/modules/iblock/classes/general/cml2.php и копируем класс class CIBlockCMLImport в свой файлик с другим именем, например с именем CIBlockCMLImport2, аналогично поступаем с файлом CIBlockCMLExport из того же файла.
Аналогично поступаем с классом CAllSaleExport из файла /bitrix/modules/sale/general/ export.php и с классом CSaleExport из /bitrix/modules/sale/mysql/export.php (делаем ему class CSaleExport2 extends CAllSaleExport2)
Далее в наших компонентах обмена из нашего пространства имен подключаем наш файл с нашими классами-копиями, после чего заменяем в компонентах все вызовы CIBlockCMLImport, CIBlockCMLExport и CSaleExport на вызовы CIBlockCMLImport2, CIBlockCMLExport2 и CSaleExport2
После этого идем в /bitrix/admin/ содаем там новый файл 1c_exchange2.php, копируем туда содержимое файла /bitrix/modules/sale/admin/1c_exchange.php
Заменяем в нашем файле /bitrix/admin/1c_exchange2.php вызовы стандартных компонентов битрикс bitrix:sale.export.1c, bitrix:sale.export.1c и bitrix:catalog.export.1c на вызовы наших кастомных (я заменяю на bedrosova:sale.export.1c, bedrosova:sale.export.1c и bedrosova:catalog.export.1c), прописываем в 1С путь к нашему скрипту обмена /bitrix/admin/1c_exchange2.php
Наслаждаемся! Теперь можем спокойно обновлять битрикс, и не ждать сюрпризов по части обмена с 1С.
Примечание! Наши скопированные классы продолжают использовать стандартные языковые файлы.
Бедросова Юлия, Битрикс после обновления не требует обновлять 1С УТ? Тогда задача по прежнему актуальна. Ну не знай, я добавил языковые файлы, и ваше решение заработало.
Наверное, каждому разработчику и владельцу интернет-магазинов, приходилось не раз слышать от SEOшника: «нужно сделать ЧПУ для фильтра, как на розетке, как на розетке, как на розетке...». Не знаю уж, почему именно пресловутая розетка так нравится SEO-специалистам, но спрос породил предложение. Прежде, чем рассказать о нашем опыте реализации ЧПУ для фильтра и о нашем новом модуле под маркетплейс (который сейчас на стадии бета-тестирования), я хотела бы немного рассказать о самой сути задачи.
Имитация статичности динамических страниц, сформированных фильтром. У страниц каталога, к которым применен фильтр — красивые человекопонятные URL-адреса.;
Перелинковка за счет использования ссылок в качестве лейблов чекбоксов фильтра;
Возможность указания отдельного заголовка, мета-описания и ключевых слов для каждой фильтрованной страницы каталога.
Поисковым системам очень нравится такая организация каталога. В индекс попадает бешеное количество (число страниц потенциально равно количеству сочетаний значений свойств раздела без перестановок) перелинкованных друг с другом страниц с уникальным описанием и уникальными метатегами и, как следствие, высокорелевантных низкочастотным поисковым запросам.
Проанализировав работу фильтра на сайте http://rozetka.com.ua/ мы поняли, что, используя мощь движка 1С-Битрикс, мы можем сделать и точно так, и даже красивее (а именно: на розетке количество свойств раздела, для фильтрации по которым организуется ЧПУ — ограниченно небольшим числом, и ЧПУ — не мнемонично — человекопонятным его можно назвать лишь с натяжкой. Мы же нашли решение для неограниченного числа свойств, а так же предусмотрели вариант автоматической генерации метатегов на тот случай, когда контент-менеджер не успевает их придумывать).
Однако в силу различий в архитектуре интернет-магазинов, на которых нам приходилось организовывать подобный фильтр, каждый раз нам приходилось изобретать этот велосипед практически с нуля. Порой мне казалось, что универсальное и одновременно изящное решение данной задачи — невозможно.
К примеру, в интернет-магазине электроники kfk.ru нам пришлось учитывать наличие в системе предсозданных SEO-страниц, на которые пользователь должен был попадать, выбирая определенную комбинацию фильтра.
http://kfk.ru/podborki/sat-50m-koaksi...nyj-kabel/ Сняв же галочку фильтра на такой посадочной странице или выбрав другой фильтр, пользователь должен был попадать обратно — на динамическую страницу каталога.
В интернет-магазинах http://uptosport.ru/ и http://uptodream.ru/ нам пришлось дать контент-менеджерам инструмент для присвоения свойствам и их значениям символьных кодов (они не велись ранее), а так же контролировать их уникальность.
В итоге получились вот такие красивые ЧПУ-ссылки на фильтрованные разделы:
В некоторых интернет-магазинах задача осложнялась так же тем, что контент-менеджеры работали только на стороне 1С Предприятия, и хотели вбивать символьные коды свойств и значений свойств только там.
Мы придумали, как расширить выгрузку из 1С УТ для того, чтобы можно было передавать символьные коды свойств и их значений, не нарушая формата CML2 и не ломая налаженный на проектах обмен с 1С. Дополнили выгрузку XML следующим образом:
И, естественно, мы добавили поддержку выгрузки символьного кода свойств и значений свойств в свой модуль интеграции http://marketplace.1c-bitrix.ru/solut...tegraciya/ (выйдет на днях в составе фундаментального обновления 3.0.0).
После этого мы подумали (и измерили), что если хранить символьные коды значений всех свойств в одном highload инфоблоке, это позволяет организовать фильтр с ЧПУ чрезвычайно эффективно, и мы добавили в свой модуль интеграции опцию, позволяющую создавать и заполнять для нашего ЧПУ фильтра highload инфоблок прямо в процессе импорта из 1С Предприятия.
В своем же модуле фильтра «какнарозетке» (мы еще думаем над его официальным названием) мы добавили поддержку своего модуля интеграции. То есть, если в системе будут установлены оба наших модуля — они будут работать совместно, и производительность ЧПУ-фильтра увеличится в разы. Но если в системе будет установлен только наш модуль ЧПУ, он будет выбирать символьные коды свойств из вспомогательного инфоблока или highload-инфоблока-справочника значений каждого конкретного свойства.
Об обновлении нашего модуля интеграции 3.0.0 я напишу в отдельном посте.
Владимир, а кто-то думаешь парился? Пришли SEOшники и сказали заказчика, что надо ЧПУ. Заказчик сходил на SEO конференцию и ему там сказали что надо ЧПУ.
Гаврилов Евгений написал: Но что происходит в дальнейшем? Яндекс и гугл добавляют страницу в поиск, дальше анализируют их, а после выясняют, что контент неуникальный. Яша выкидывает ее из поиска, гугл накладывает на нее фильтр. Изменение блоков местами не есть уникальность.
Зае**** вы со своим уникальным контентом. Правило поисковый систем- сайт для людей. Контент одинаковый (дубль), когда страница 1 к 1 повторяет себя - всё остальное уникальное.
К примеру: дешевые диваны - отображается страница с товарами где сортировка товаров по возрастанию цены. еще можно добавить всеми так любимые текста для seo вниз страницы.
дорогие диваны - отображается та же самая страница с товарами, где сортировка товаров по убыванию цены. еще можно добавить всеми так любимые текста для seo вниз страницы.
Это дубли? Нет. Не верите - практикуйтесь. А если есть на практике опровержение, то покажите сайт, посмотрим, проанализируем и попытаемся понять почему так.
Виталий Вайти написал: Зае**** вы со своим уникальным контентом. Правило поисковый систем- сайт для людей. Контент одинаковый (дубль), когда страница 1 к 1 повторяет себя - всё остальное уникальное.
К примеру: дешевые диваны - отображается страница с товарами где сортировка товаров по возрастанию цены. еще можно добавить всеми так любимые текста для seo вниз страницы.
дорогие диваны - отображается та же самая страница с товарами, где сортировка товаров по убыванию цены. еще можно добавить всеми так любимые текста для seo вниз страницы.
Это дубли? Нет. Не верите - практикуйтесь. А если есть на практике опровержение, то покажите сайт, посмотрим, проанализируем и попытаемся понять почему так.
Тема стара, как обмен между 1С Предприятие и 1С-Битрикс, но продолжает будоражить умы. Расскажу по шагам, как это делаю я. Мы провели выгрузку каталога из 1С и видим, что наряду со старым товарным инфоблоком в админке сайта создался новый. Что делать?
1) Идем в настройки – Настройки модулей – Информационные блоки и включаем галочку «Показывать код загрузки из внешних источников»
2) Далее идем в Магазин – Интеграция с 1С На самой первой вкладке если тип инфоблока не выбран, выбираем тип инфоблока catalog
3) Удаляем новый инфоблок и новый тип инфоблока и запускаем импорт из 1С по-новой.
4) Теперь мы видим, что инфоблок создался уже в нужном нам типе инфоблоков. Идем дальше Открываем новый инфоблок на редактирование, копируем его внешний код Открываем в соседней вкладке старый инфоблок на редактирование – вставляем туда внешний код
5) Открываем вкладку Свойства обоих инфоблоков в соседних вкладках Аккуратно ищем в новом инфоблоке свойства, которые есть в старом – по коду, и если такие совпадающие свойства есть – копируем для них внешний код из нового блока в старый. А если они разных типов – то в простом варианте просто удаляем такое свойство из старого инфоблока. В сложном – там надо думать о кастомизации импорта.
Осталось разобраться с ценой. Если это малый бизнес, то открываем файл обмена сохраненный в логах, ищем там внешний код цены и вписываем его во внешний код единственной цены в битриксе.
6) Снова удаляем новый инфоблок, запускаем импорт заново – наслаждаемся попаданием импорта «туда»
7) После этого в настройках каталога в публичной части сайта нужно вывести нужные свойства, перевыбрать тип цены, настроить, какие свойства должны отображаться в умном фильтре а какие – на детальной странице.
P/S: в редких случаях, если не применяются типовые решения из маркетплейс или если публичка сайта еще не разработана и инфоблок товаров - по сути пустой и вам все равно, какое свойство, куда попадает, можно направить выгрузку сразу в нужный инфоблок (и если из 1С импортируется только 1 каталог в 1 инфоблок) (для реальных и серьезных проектов я это делать не рекомендую, но все же):
В поле внешнего кода нужного инфоблока пишем FUTURE-1C-CATALOG и при первой же выгрузке из 1С все товары попадут в него. В ИБ товарных предложений в поле внешнего кода пишем FUTURE-1C-OFFERS и товарные предложения - пойдут в него.
Журавский Сергей написал: Подскажите где смотреть этот файл логов?
Путь к файлу логов Вы задаете сами при создании узла обмена с сайтами (это в 1с). Там в папке reports формируются файлы логов обмена, ищете там файл, содержащий в названии слово Exchange_, смотрите дату обмена, это и есть искомый файл. Открываете его и ищете слово prices. После этого слова идет внешний код цены.
Журавский Сергей написал: второй вопрос внешний код цены указывать тут http://название сайта/bitrix/admin/cat_group_admin.php?lang=ru
Добрый день. делаю всё по инструкции, но в итоге экспорт идёт в новый каталог, причём создаётся внешний код с префиксом "shop-" к внешнему коду старого каталога. подскажите, в чём может быть дело? внешний код каталога куда надо выгружать товар: 0b466bfe-d5a1-4416-8fd1-2ca96912fb63 внешний код каталога куда выгружается товар: shop-0b466bfe-d5a1-4416-8fd1-2ca96912fb63 если во внешний код каталога выгрузки записать "shop-0b466bfe-d5a1-4416-8fd1-2ca96912fb63", то создастся каталог с внешним кодом "shop-shop-0b466bfe-d5a1-4416-8fd1-2ca96912fb63"
Отлично! Нашёл что искал. Только было бы хорошо предупредить, что структура каталога если не настроена в 1С (в моём случае это МойСклад) как и на сайте и не связана внешним кодом - слетает (со всеми настройками).
Продолжая тему нестандартной интеграции 1С Битрикс и 1С Предприятия, хочу рассказать о том, как я кастомизирую экспорт заказов. Это тоже довольно востребованная и распространённая задача, и, что интересно, практически всегда заказчиков не устраивает экспорт «из коробки», и они просят пусть какие-то мелочи, но переделать.
Например, недавно я столкнулась с такой задачей. Оптовые покупатели интернет-магазина (на 1С Битрикс Бизнес 11й версии ядра) обладают дополнительными свойствами: номерами договоров и датами заключения этих договоров. При оформлении заказа они выбирают один из своих договоров, на основании которого будет происходить сделка. Номер договора и его дата – должны передаваться в 1С предприятие при экспорте заказов.
Формированием xml-файла заказов, который передается в 1С Предприятие, занимается функция из ядра Битрикс ExportOrders2Xml, которая описана в файле bitrix/modules/sale/general/export.php
Конечно, соблазн исправить пару строк в ней прямо там на месте – велик. Это займет 5 минут. НО ядро битрикс станет модифицированным и каждый раз, обновляя ядро, нужно будет помнить об этой модификации и вносить ее снова. Каждый раз. А если проект перейдет на сопровождение другой студии или разработчику (как частенько бывает), и заказчик забудет о том, что ядро его проекта модифицировано, в один прекрасный день это может обернуться серьезными проблемами. Поэтому, я думаю, что лучше сразу потратить 30 минут вместо 5, но кастомизировать экспорт так, чтобы ядро не было затронуто, и чтобы об этой модификации не нужно было помнить.
Как я делаю? Я копирую компонент sale.export.1c из папки /bitrix/components/bitrix/ в свое пространство имен /bitrix/components/bedrosova/, затем в папке компонента создаю еще 1 файлик
В этот файлик я копирую полное описание функции ExportOrders2Xml из файла bitrix/modules/sale/general/export.php и незамысловато переименовываю ее в ExportOrders2Xml2 (а здесь нужно отметить, что исходная функция ExportOrders2Xml – это статический метод класса, и именно поэтому описываемый мною способ применим. Если бы этот метод не был статическим, то пришлось бы либо копировать весь класс, содеражщий его, либо заводить класс – наследующий его. Наследование – это, конечно, спорный механизм, но не в сравнении с модификацией исходного класса) и затем уже в своей скопированной функции вношу все необходимые мне модификации.
в своем компоненте /bitrix/components/bedrosova/sale.export.1c/components.php
Затем заменю вызов статического метода класса
CSaleExport::ExportOrders2Xml на вызов свой функции ExportOrders2Xml2
Все, остается только не забыть заменить в файле обмена вызов стандартного компонентаsale.export.1c на вызов кастомизированного.
Кастомизация экспорта заказов описанным методом не слетает даже при переходе с 11й версии ядра на 12ю, в которой стандартный экспорт организован с использованием классаCIBlockCMLExport. О его кастомизации без модификации ядра я напишу как-нибудь в другой раз.
Однажды, отец призвал к себе трех своих сыновей и попросил разломать пополам веник. Сначала попробовал старший сын, но, сколько он ни старался — ничего не получилось. Такие же неудачи постигли среднего и младшего. Тогда отец развязал веник, и попросил каждого сына разломать по несколько соломинок...
К чему я это? Дело в том, что у меня возникла одна идея. Я не оценивала ее критически и пока не знаю, реализуема она или не реализуема. Вернее, она реализуема на 100%, но никак не одним человеком, поэтому мне нужна Ваша поддержка и помощь, господа и дамы, товарищи, Сообщники.
Я расскажу, что я чувствую и о чем я думаю. А вы - судите сами.
Недавно я с удивлением открыла для себя такой интересный ресурс, как http://habrahabr.ru/ (шутка). Я и раньше знала о его существовании. Но недавно я узнала, что этот ресурс можно рассматривать не только в качестве приятного чтения на ночь, но и как офигенное место для самопиара (возможно, это прозвучит немного цинично, но, я думаю, что ни меня, ни Вас - Сообщники, не было бы здесь, если бы мы не нуждались в пиаре). Здесь - в блогах веб-разработчиков мы с вами делимся интересными наработками, устраиваем дискуссии, радуемся, написав удачный пост и печалимся, если пост раскритиковали. Мы гордимся своими партнерскими рейтингами... и считаем друг друга - конкурентами.
Но там - для них мы все равны, потому что для них мы - никто, ноль без палочки, пустое место, недопрограммисты, люди второго сорта. Почему? А вот почему - я приведу скрин:
Хаб "1С-Битрикс". 34 поста. Авторов - и того меньше. И те - предпочитают вести себя тихо и не ввязываться в холивары в то время как нас с вами и систему, с которой мы предпочитаем работать поливают г......м (и я бы не стала борьться в одиночку - затратно и бесполезно). Хотя... есть один достойный восхищения человек, который не боялся отстаивать на Хабре свое мнение об 1С-Битрикс. Но он был один...
Да, я понимаю, что сейчас кто-то скажет мне, что нам нужно просто смириться с тем, что Битрикс на Хабре "не любят", что нельзя пытаться остановить поезд своим телом, а лучше отойти в сторону. Но есть и другие варианты, чтобы заставить поезд ехать в другую сторону.
На скрине ниже - тарифы Хабра для организаций:
Мне нравится тариф "Гигант". Это тариф на 20 человек, которые обладая достаточно подвешенным языком, уже смогли бы любому "показать на пальцах, что к чему", как говорит один мой друг по сообществу. Тем более, что на корпоративном тарифе пиариться куда комфортнее, а минусы в карму - не особенно страшны.
Собственно, моя идея состоит в том, чтобы создать и зарегистрировать как организацию Ассоциацию независимых Битрикс-программистов или Клуб независимых Битрикс-программистов или Союз независимых Битрикс-программистов. Установить небольшой фиксированный членский взнос, а потом попробовать отстоять себя, свою честь, свои идеалы на внешних IT-ресурсах.
Для того, чтобы начать с малого, ищу 19 умных и наглых компаньонов, с богатой лексикой и горячим сердцем, готовых скидываться по 4200р раз в 3 месяца для ведения совместного блога на Хабре, а в перспективе для захвата мира.
Бедросова Юлия, О том и речь, что подобный подход - в назидание молодым холиварщикам. С другой стороны, одна из слабых сторон Битрикса - он распространяется по принципу сетевого маркетинга. И тут холивары неизбежны. Это как орифлэймщики, которые воюют с эйвонщиками. Как харизматы, переубеждающие баптистов. А вот Хабрахабр, как ни странно, освобождает от этого иллюзорного сектантства. Но, пока жив Битрикс, будет жить холивар.
Долганов Николай, было время, когда я готова была порвать глотку, доказывая свою правоту тем, кто не согласен с моим мнением. Сейчас - повзрослев, я считаю, что каждый человек имеет право на свое мнение, и вообще нет смысла ни с кем холиварить.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».