Описание новых АПИ функций не сразу появляется в документации. Есть объективные причины, почему это именно так, мне не хочется сейчас лишний раз перетирать вопрос снова. Между тем, сам не испытываю на этот счёт никаких проблем: при наличии исходников можно всегда посмотреть код. Правда, надо знать, где смотреть и что искать. Мне пришла идея написать скрипт, который будет сканировать текущие файлы ядра и выводить список доступных АПИ функций и событий всех модулей. Это значит, что любые доступные модули, написанные по идеологии Битрикс, можно будет "просмотреть".
Не стал делать сканирование всех файлов модуля, т.к. АПИ содержится в классах. Кроме того, могут быть определены локальные функции, используемые, например, внутри компонента, только там и доступные. Так и работает быстрее. Выбираем модуль, тут же происходит сканирование и выводится список событий модуля и методов.
По списку аргументов можно легко догадаться, что они означают. Например, метод CCurrency::GetList имеет два обязательных параметра: поле сортировки и порядок сортировки. Оба передаются по ссылке. Третий параметр язык, по умолчанию принимает значение текущего языка.
По клику на функцию открывается её описание в новом окне. Код функции читается прямо из файла, при этом уже скрипты не парсятся, вся необходимая информация передаётся в URL.
По клику на событие открывается метод, где оно инициируется. Вызов события подсвечивается.
Скрипт можно скачать с сайта.
Обновление от 31.02.2012 Сейчас решение доступно через marketplace
А почему нельзя саму документацию автоматизированно апдейтить по результатам этого скрипта? Я понимаю, что "человеческие" (написанные человеком) описания функций/событий появляются не быстро, но можно было бы хотя бы создать о них заметки. Преимущества: - их уже можно будет начинать комментировать, а комментарии бывают ценнее, чем даже "человеческое" описание. - по ним будет работать централизованный поиск.
Если пользователи могут менять элементы инфоблока, администратору может быть удобно быть в курсе этих изменений. Ранее писал решение одной из таких задач, где форма обратной связи делалась на инфоблоках. Как раз там мне указывали на то, что править код для каждого инфоблока не удобно.
Теперь решил обобщить задачу и сделать возможность интерфейсно выбирать, любой инфоблок. За одно можно будет фиксировать изменения в журнале событий, тем более, способ теперь известен
Стандартный модуль документооборота отправляет уведомления почтой, но не всегда он есть и не всегда удобно его включать только ради почтовых уведомлений.
В зависимости от ситуации, может потребоваться уведомлять о добавлении, изменении или удалении элемента. Скрипт настройки уведомлений можно положить в любое место на сайте, доступ открыт только для администратора. Получаем такой интерфейс:
Название инфоблока сделано ссылкой, при клике по нему можно включать/выключать сразу все опции. Раз уже стал делать "для ленивых", почтовое событие IBLOCK_ELEMENT_CHANGE_NOTIFY и шаблон для него создаются автоматически В шаблон передаются все поля элемента.
В файл /bitrix/php_interface/init.php надо добавить код (создайте файл, если его нет):
После изменений элементов в журнале событий получим сообщения вида:
За одно сделал такую фишку: при удалении элемента обработчик вешается но событие до удаления, а не после, как в остальных случаях. Это позволяет отправить администратору на почту данные элемента (на случай их последующего восстановления).
Когда речь заходит о поисковой оптимизации, возникает ощущение, что касаешься чего-то волшебного. SEO оптимизаторы для меня - это некие шаманы, пытающиеся ублажить могучих Богов поиска. Они не говорят иначе как "поисковики любят" и "поисковики не любят" SEO рекомендации зачастую противоречат здравому смыслу, но они работают. Примечательно, что на основе "анализа" сайтов оптимизаторы часто дают одни и те же рекомендации. Пару из них мне посчастливилось выполнить.
На этом заканчиваю лирику и перехожу к сухому изложению. Базовые SEO рекомендации:
При запросе любых адресов, содержащих неосновные хосты (например, http://1c-bitrix.ru/ без префикса www) необходимо, чтобы сервер отдавал ответ HTTP/1.1 301 Moved Permanently. При этом в поле Location должен быть прописан URL, содержащий основной хост ресурса (http://www.1c-bitrix.ru/).
На сайте присутствуют повторяющиеся страницы вида: http://www.1c-bitrix.ru/ и http://www.1c-bitrix.ru/index.php. Данные страницы проиндексированы поисковыми системами и отдают ответ сервера HTTP/1.1 200 ОК. Необходимо оставить первый вариант страниц, а для страниц-дубликатов настроить переадресацию с ответом сервера HTTP/1.1 301 Moved Permanently на соответствующие страницы.
Или попросту говоря, надо чтобы при открытии сайта "без www" он перебрасывал на адрес "с www" и при переходе на index.php перебрасывал на папку (адрес с "/" на конце).
Разумно использовать для этого mod_rewrite. Модуль почти всегда доступен на хостинге, и не требуется дополнительная обработка в php.
То со второй оказалось не так просто. Нам надо проверить переменную {%REQUEST_URI}, если она заканчивается на "/index.php", перенаправить на "/". Всё дело в том, что почти всегда на Apache ставится модуль mod_dir, который открывает файл index.php при обращении к папке, его содержащей. А хуже всего то, что этот модуль переопределяет{%REQUEST_URI} так, что в обоих случаях (http://bitrix.ru/ и http://bitrix.ru/index.php) срабатывает правило:
заканчивается на "/index.php"
Но как известно, mod_rewtite это тоже "Damned cool voodoo"
Готового решения в сети не нашёл, но в результате экспериментов было выявлено, что при обращении к папке срабатывает условие:
заканчивается на "/"
(Т.е. получается двойственность: срабатывают оба условия).
После долгих мытарств, подробности которых пропущу, получилось вот такое условие:
прервать обработку, если обращение идёт к папке (URI заканчивается на "/");
прервать обработку если уже был сделан внутренний редирект (без этого условия уходит в бесконечный цикл, почему, не знаю);
если метод запроса GET (мы не хотим, чтобы потерялись данные формы, пришедшие через POST) и URI заканчивается на /index.php - сделать редирект на тот же URI, но без "index.php";
Теперь оба правила и включение модуля mod_rewrite для тех, кто любит сразу получать готовые решения
Вся эта борьба за переменные между модулями mod_dir и mod_rewrite в совокупности с магией вопроса напомнила мне игру из детства Mortal Combat, в которую играл на Dendy. Чтобы пост не выглядел скучно, напоследок вставляю скрин игры
В моём случае mod_rewrite - это LIU KANG, он победил!
изза наличия у апача порта 8888 переход происходит на сайт:8888 - такой адрес не обрабатывается из вне (к ури добавляется хост плюс порт) пока попробовали модернизировать с явным указанием хоста без порта
помогло, но вот странички с адресом типа 1c-bitrix.ru/products/index.php/ахинея открывается главная страница компонента, вместо 404, вот как с этим бороться?
В старых версиях продукта мы писали уведомления в живую ленту о новых файлах в группах соцсети. Это было неудобно при большом числе загружаемых файлов, и многие пользователи жаловались на захламленность живой ленты. Мы это восприняли как недоработку, и в текущей версии функционал убрали.
Оказалось, что ряд компаний использовали уведомления в живой ленте в рабочих процессах внутри компании. Мы будем возвращать этот функционал, но в другом виде: уведомления будут идти в виде нотификаторов в мессенджер и они будут гибко настраиваться.
Для тех, кого этот вариант не устраивает, предлагаю решение, которое не изменяя ядро продукта вернёт старое поведение уведомлений. Для этого надо добавить один обработчик в файл /bitrix/php_interface/init.php.
Если этого файла нет, создайте его со следующим содержанием:
Денис, а просто вебдав (библиотека документов), не в группах? Уже несколько идей с просьбой вернуть функционал просто с возможностью отключения, кому не нужно (ну или включения, кому нужно. Сперва так и было, кстати, зачем вырезали - непонятно) и обсуждение на форуме.
Как-то мне пришлось работать с проектом, на котором после сбоя на хостинге, нескольких восстановлений базы и переносов с кодировками стало всё плохо. Нормального бэкапа нет, а данные в базе перемешаны: часть данных отображается нормально, часть кракозябрами. Т.е. выполнить какую-то конвертацию таблиц не представляется возможным. Мне пришлось включить голову и найти решение. Сразу скажу, что не дам простого готового инструмента, наподобие того, что делал для перекодировки сайта в utf8. Тут нужно хорошо понимать, что делается. Но, надеюсь, программист разберется. Главная цель этого сообщения - донести, что в любой ситуации можно найти решение.
Итак, имеем сайт, где файлы нормальные, а в базе данных часть информации хранится нормально, а часть испорчена перекодировкой.
0. Сделайте бэкап
Все знают, но не всегда помнят: какая бы плохая ситуация не была, её всегда можно сделать хуже. Поэтому не спешите что-то исправлять когда что-то сломалось. Начните с сохранения того, что есть.
1. Выясните, каким образом испорчены данные
Есть ряд сервисов, позволяющих определить, как произошла перекодировка текста. Мне понравился и помог сервис Артемия Лебедева. Скопируйте туда плохой текст и поймете, как его можно восстановить.
2. Проверьте на фрагменте текста восстановление используя свой метод перекодировки
Прежде всего нужна функция, которая будет проверять, хороший ли текст к нам пришел. У меня сайт работал в utf-8, поэтому функция имела вид:
function good($str)
{
return preg_match('#[а-яА-Я]#u',$str);
}
У нас в корпоративном портале есть библиотека документов. Этот модуль позволяет работать с документами компании и редактировать их в Office открывая непосредственно из браузера. Для этого используется технология webdav, которая по умолчанию работает для Internet Explorer в связке с MS Office 2010. Или через плагин для браузера FireFox. Но есть определенное неудобство. Дело в том, что доступ ко всей информации портала возможен только по паролю, и чтобы пользователь оставался авторизованным не вводя пароль на каждый хит, в куки браузера передаётся уникальный идентификатор сессии. Но вот офис ничего не знает об этом, поэтому требует от пользователя ввода пароля. [CUT]
Что, согласитесь, не очень удобно. А когда надо часто работать с документами, может вообще сильно досаждать.
Что можно сделать
Самое очевидное решение - настроить NTLM для работы с порталом. Тогда все приложения компьютера (в том числе Office) будут передавать специальные данные авторизации на портал. Но настройка NTLM сопряжена с определенными техническими трудностями. А кроме того, в организации может быть не установлен AD сервер. И могут быть пользователи портала вне домена AD. Иными словами, не всегда это возможно.
Можно сделать иначе: передавать офису в ссылке на документы идентификатор сессии, а на стороне сервера незаметно для основного функционала подменять его. Открываться будет всегда без пароля, но при сохранении может потребоваться ввод пароля если текущая сессия истекла (это будет особенно актуально если в настройках модуля проактивной защиты включена смена идентификатора сессии).
Просто так в качестве параметра передавать идентификатор сессии нельзя т.к. протокол webdav подразумевает несколько последовательных запросов к серверу, в процессе которых параметры запроса теряются.
Решение
Нам потребуется сделать две правки: подменить ссылку на документы и научиться правильно понимать такие ссылки.
Для надо:
1) Скопировать шаблон компонента bitrix:webdav.section.list в шаблон сайта .default (или текущего сайта). Или, говоря проще, папку /bitrix/components/bitrix/webdav.section.list/templates/.default копируем в /bitrix/templates/.default/components/bitrix/webdav.section.list Теперь вместо стандартного шаблона библиотека документов будет использовать наш собственный.
2) Создать файл result_modifier.php в папке /bitrix/templates/.default/components/bitrix/webdav.section.list/.default со следующим содержимым:
Убедитесь что нет пробелов и переносов строк до "<?" и после "?>", иначе можете получить "ошибку в типе содержимого". Всё! Теперь документы можно открывать и сохранять без дополнительного запроса авторизации!
чтобы пользователь оставался авторизованным не вводя пароль на каждый хит, в куки браузера передаётся уникальный идентификатор сессии.
Небольшое дополнение: если при авторизации пользователь ставит галочку "Запомнить меня на этом компьютере", то IE (обычно) передает куку браузера в MS Office. С Firefox это 100% не работает.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Я понимаю, что "человеческие" (написанные человеком) описания функций/событий появляются не быстро, но можно было бы хотя бы создать о них заметки.
Преимущества:
- их уже можно будет начинать комментировать, а комментарии бывают ценнее, чем даже "человеческое" описание.
- по ним будет работать централизованный поиск.
Почему нет английской локализации?