Иногда возникают ситуации, когда нет пароля от учетной записи администратора, но есть ftp. В этом случае можно использовать простенький скрипт, который авторизует пользователя и удаляет себя, для исключения потенциальных дыр в безопасности.
<? require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php");
global $USER;
$USER->Authorize(1);
@unlink(__FILE__);
LocalRedirect("/bitrix/admin/");
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");?>
Не работает авторизация под пользователем с ID 1 с помощью этого кода. Не знаю почему, всю жизнь так логинился когда не мог войти. Пользователь такой точно есть. Посмотрел в MySQL Workbench.
Создаю файл /test/auth/index.php В нём вот такой код:
<? require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php"); global $USER; $USER->Authorize(1); LocalRedirect("/bitrix/admin/");
Редирект на /bitrix/admin происходит - но я попадаю не в административный раздел, а на форму ввода логина и пароля.
Лазил в файле /home/bitrix/www/bitrix/modules/main/include.php - так там вообще какой то минифицированный код. Попробовал найти там "session control from security module" - так такого вообще нет.
Помогите, не знаю уже что делать, как залогиниться то?
Используем PhpStorm для разработки На текущий момент есть много замечательных IDE с поддержкой PHP/JS/HTML, но я с давних пор пользуюсь PhpStorm Далее - подробная инструкция как начать работу с этой замечательной IDE.
Доброго времени суток ) Решил таки опубликовать модуль для подключения доктрины к битриксу - ссылка на гитхаб, инструкция по установке и использованию там же.
Пара слов зачем это нужно и кому может пригодиться. Я с этим модулем делал два крупных проекта, сейчас делаю сайт турфирмы - в базе на текущий момент уже 12 таблиц со сложными связями, которые невозможно реализовать на инфоблоках, а orm битрикса сильно проигрывает по удобству и функционалу doctrine orm.
Мокрушин Алексей, сперва бы доделать там на самом деле очень много надо сделать, а времени нет. Хотя бы доделать апи для связки elasticsearch и битрикса (добавление в индекс и получение из индекса). После этого уже можно говорить о каких-то компонентах и модулях. И то, это всё очень специфично. А в битриксе сейчас появились фасеты, поэтому уже часть задачи отпало. Хотя с elasticsearch можно забабахать офигенный поиск с ранжированием и фильтрацией.
Гаврилов Евгений, там отличный дашбоард на Кибане можно замутить. И это же практически рилтайм отображение характеристик. Ко всему прочему ту же Кибану можно и под отображение разных моментов приспособить
Для php довольно давно существует менеджер зависимостей под названием composer, который позволяет одной командой устанавливать и обновлять библиотеки вместе с зависимостями. Подробно о нем можно прочитать здесь: http://habrahabr.ru/post/145946/ . я же в этом посте хочу показать как подключить его к битриксу на примере одного пакета, который использую в каждом проекте.
Я работаю под линуксом, поэтому примеры команд привожу для него, для windows думаю отличий будет немного.
Итак. Сначала необходимо установить composer. В корне проекта выполняем команду:
Теперь можно приступать к установке пакетов. В этом посте для примера будем использовать пакет для вывода отладочной информации - leeoniya/dump-r. Устанавливаем его командой:
В корне проекта появилась папка vendor, в которую composer скачивает библиотеки, также там расположены служебные файлы и автозагрузчик классов, который необходимо подключить в /bitrix/php_interface/init.php:
Последнее время на меня валится большое количество шаблонных проектов и становится скучно. Приходится развлекаться на стороне =) Сразу оговорюсь - подключение к битриксу шаблонизатора это скорее теоретические изыскание, на практике нигде не применял, поэтому особенно интересно мнение сообщества - какие вы видите в этом плюсы и минусы. Также цель поста - попиарить проект https://github.com/dizzy7/bitrix-libs =)
На наших проектах мы используем схему, когда верстальщик верстает отдельно на своем сервере, где использует все удобные ему технологии (SSI, SAAS, LESS, Foundation, и др), благорадя чему верстает очень быстро, до 5 страниц среднего сайта за день.
Потом программист эту верстку программирует.
Когда на проекте возникают доработки где нужно править рабочий код (например, изменился внешний вид страницы товара) то верстальщик вносит правки на своем сервере для верстки, и комитит изменния через систему контроля версий в Битбакет. Программист когда приступает к внесению правок - полностью перезаливает все стили и js с сервера верстки (так как изменений в них может вносить только верстальщик) и изменяет html-структуру запрограммированного шаблона (видя через историю контроля версий в каких местах вносились правки).
Как правило, это работает быстро и надежно и достаточно программиста даже начального уровня чтобы перенести правки с верстки на рабочий сервер. Но как всегда - хочется автоматизации, поэтмоу рассматриваем вариант когда даже такого ручного переноса не понадобится.
По поводу 10-ти уровней - я имел ввиду такую структуру: /bitrix/templates/s1/components/bitrix/catalog/main-cat/bitrix/catalog.section/.default/template.php (тут даже 12 каталогов вышло) поэтому ищем способ чтобы все шаблоны (все файлики /template.php) лежали в одном месте на проекте (максимум с одним уровнем вложенности), например, так:
/local/html_templates/ - prodlist.tpl - category.tpl - subcategory.tpl - body.tpl - feedback.tpl - ... и тд чтобы верстальщик видел все шаблоны в одной папочке, и для него было просто и комфортно их править.
верстальщику проще править костяк шаблона когда это один файл (где видно структуру вложенности дивов), а если он должен помнить что в header.php он открыл 4 дива, и должен их закрыть в footer.php то это усложняет и запутывает разработку.
Типичная, хорошая схема. Но её слабость заключается в том, что после каждого чиха верстальщика нужен бэкэнд-разработчик. Как ни крути, но внёсший правки в вёрстку быстрее поправит шаблоны. Это особенно удобно на горячих проектах: каждый занимается своими делами, никого не надо дёргать из-за мелких правок.
Вот вы говорите про объединение шапки и подвала в один файл. Честно, мне кажется, это надуманная проблема. «Чистая» вёрстка собирается отдельно (просто ХТМЛ-страницы или компилирование, не важно), а потом уже её куски перетаскивают в шаблоны. Копи-паст, в общем.
С шаблонами в /local/html_templates/, думаю, могут возникнуть подводные камни, если проект будет расти. Тут надо учитывать те же зоны компонентов, многосайтовость.
Тема автоматизации широка и интересна. Главное, автоматизируя, как минимум, не терять того функционала, который был ранее : )
Поскольку ссылка на библиотеку автора давно уж не работает, позволю себе запостить ссылку на нашу библиотеку той же направленности. https://github.com/maximaster/tools.twig
Легко подключается через composer, psr-4 внутри, все дела ..
Сижу, никого не трогаю, в очередной тысяча-первый раз пишу $APPLICATION->AddHeadScript(), и вдруг phpstorm его перечеркивает... Разработчики битрикса наконец-то узнали о тэге "deprecated" и определение этого метода выглядит как /** @deprecated use Asset::getInstance()->addJs($src, $additional) */ function AddHeadScript($src, $additional=false)
Что же, отрадно, неужели и правда жизнь налаживается? =)
Цупко Игорь, в целом про разные среды мысль здравая, хотя в целом на локальных машинах можно использовать puphpet для создания идентичных сред у разработчиков и на продакшене. Для меня разрабатывать- на локальной копии очень удобно - нет задержек на заливку файлов, с локального компа сайт открывается в разы быстрее, чем с удаленного.
Цупко Игорь, а как вы отладкой пользуетесь? Ведь для нормальной отладки через xDebug нужен весь стек вызовов страницы. Ну и плюс в разных ядрах разный набор модулей/функций. Лишний автокомплит ведь ни к чему
@deprecated заметил тоже когда-то давно еще на GetIBlockElement()
Зацепин Евгений, согласен про разработку на локальной копии с ядром (правда у нас еще все синхронизируется с девелоп-сервером, и по сути код лежит локально, а работает - на сервере). Всегда можно внести изменения в ядро, полопатить его как следует.
Доброго времени суток. Набросал на коленке сервис генерации прокси-классов для работы с SOAP (генерация производится на основе wsdl). Сервис основан на доработанной библиотеке.
Как водится кратко - зачем, почему, и какая польза =) 1. Прокси-классы предоставляют удобный ООП интерфейс 2. У всех soap-функций работает автодополнение в любой IDE 3. Возвращаемые данные также оборачиваются в соответствующие классы.
Зайцев Артемий, если перечислять только функции, то конечно можно обойтись и одним файлом. Здесь же обернуты в классы в том числе и параметры и возвращаемый результат, что и создает возможность удобной работы. Например можно писать такие запросы
$result = $soap->SendDemand(new \KTSoap\SendDemand(
11766,
'http://google.com',
new \KTSoap\TouristsToDemand([
new \KTSoap\TouristToDemand(
'Иванов'
'Иван'
'Иванович'
]
),
false
));
По параметрам кострурторов сразу понятно какие параметры нужны на входе, в т.ч. вложенные сущности. На выходе определенный объект, по которому так же понятно какие данные вернул сервер.
Смысл экономить на файлах? Да, все классы можно объединить в один файл, но зачем?
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».