Это значит запускать файл search_reindex.php каждые 24 часа, результат записывать в файл search_reindex.log. Абсолютные пути и названия файлов, естественно, прописываете свои.
Как только увидел анимацию при прокрутке, открыл сайт в мобильном Chrome. Там все очень плохо.
Далее, что бросилось в глаза: такой красивый и крупный email в верхней части сайта — и не кликабельный.
Нелогичное поведение верхнего меню. Кликабельным должен быть весь блок ссылки, который подсвечивается синим цветом. А по факту ссылкой является только сам текст.
Еще обратил внимание, что спрайты не используются, из-за этого при наведении на некоторые объекты, они сначала пропадают на долю секунды, и только потом подгружается новый бэкграунд для hover'a.
В левой колонке выводится содержание (дерево разделов и элементов), в правой детальный текст раздела или элемента. Добавьте к этому простейшее ЧПУ, стандартное кеширование. Для документации вполне достаточно.
Сработало, спасибо! Правда в версиях php > 5.3 нет возможности менять параметр mbstring.func_overload через ini_set(), поэтому пришлось ставить ее в настройках сервера. Но это уже вторично.
На всякий случай приведу полную финальную версию скрипта, которая работает:
Код
ini_set('mbstring.func_overload', '2'); // для версий php < 5.3
ini_set('mbstring.internal_encoding', 'UTF-8');
set_time_limit(0);
ignore_user_abort(true);
$_SERVER['DOCUMENT_ROOT'] = '/var/www';
define('NO_KEEP_STATISTIC', true);
define('NOT_CHECK_PERMISSIONS',true);
define('BX_CRONTAB', true);
define('BX_NO_ACCELERATOR_RESET', true);
define('SITE_ID', 's1');
define('LANG', 'ru');
require($_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php');
if (!CModule::IncludeModule('search')) {
die('Search module not included');
}
$time_start = time();
$progress = array();
$max_execution_time = 10000; // все элементы индексируются только при большом шаге
while (is_array($progress)) {
$progress = CSearch::ReIndexAll(true, $max_execution_time, $progress);
}
$total_time = time() - $time_start;
echo 'reindex finished. total time: ' . $total_time . ' seconds, indexed elements: ' . $progress . "\r\n";
h.diver пишет: Попробуйте запускать через /usr/bin/php -f Или можно запустить от пользователя веб-сервера, преварительно дав ему права на исполнение скрипта.
К сожалению, не прокатило. Пробовал запускать от имени root'a, пробовал от имени пользователя сервера (www-data), безрезультатно.
Цитата
Возможно, есть какая-то разница в настройках локали для веб-сервера и для консоли.
Спасибо за наводку. Такое чувство, что связано действительно с этим, потому что запрос, содержащий только английские символы, например "kitchen", дает результат.
Использовал следующий код, чтобы определить локаль:
Код
$locale = setlocale('LC_ALL', 0);
echo $locale;
При запуске из браузера в переменной $locale значение "C". При запуске из консоли — "LC_CTYPE=en_US.UTF-8; LC_NUMERIC=C; LC_TIME=C;LC_COLLATE=C; LC_MONETARY=C; LC_MESSAGES=C; LC_PAPER=C; LC_NAME=C; LC_ADDRESS=C; LC_TELEPHONE=C; LC_MEASUREMENT=C; LC_IDENTIFICATION=C"
Я надеялся, что принудительная установка локали в значение "С" решит проблему, но нет. Добавил строчку setlocale('LC_ALL', 'C'); в самое начало скрипта. Русскоязычные поисковые запросы по прежнему не дают результата.
Пробовал еще варианты ru_RU.UTF-8, ru_RU, также безрезультатно.
Чем дальше, тем интереснее. Поставил max_execution_time = 10000 и запустил тот же самый скрипт в браузере. Пользователь — не админ, даже не авторизован. В итоге время работы скрипта оказалось меньше, чем при запуске через консоль, и поиск стал работать нормально.
Навскидку, может у вас там с правами доступа проблемы? Попробуйте в методе CIBlockSection::GetList указать в arFilter параметр "CHECK_PERMISSIONS" => "N".
Приветствую всех. Передо мной стоит задача организовать регулярную переиндексацию сайта, которая должна выполняться в фоновом режиме, когда-нибудь ночью.
Пошарил в гугле, нашел примеры и документацию, набросал вот такой скрипт:
Скрипт тестировался из командной строки, т.е. проблем с time_limit'ами вроде быть не должно.
Теперь о проблемах.
Проблема №1. После переиндексации этим скриптом поиск перестает нормально работать. На запрос вида "электрочайник" выдается пустой результат, хотя в каталоге этих электрочайников вагон. При этом, если переиндексировать сайт через админку, с теми же настройками, то поиск прекрасно находит эти самые электрочайники.
Проблема №2. Если верить документации, то установка шага ($max_execution_time) в ноль заставляет функцию ReIndexAll проиндексировать все элементы за один шаг. При этом индексируется 1885 документов. Но если поставить ненулевой шаг (например 60 или 10000), то индексируется 3867 документов. Нахожу этот момент довольно странным.
Далее, при установленном ненулевом шаге происходит следующее: если все делается через админку, то процесс длится минуты 3, и поиск работает отлично. Если же индексация делается скриптом из консоли, то процесс занимает около 15 минут, и поиск ищет очень плохо.
Буду очень рад, если кто-нибудь объяснит мне возможные причины такого поведения и укажет на мои ошибки.
Кастомизируйте шаблон компонента, который используете для оформления заказа. Например, если используется компонент sale.basket.order.ajax, в шаблоне нужно отыскать файл basket_confirm.php и в нем закомментировать все, что связано с платежной системой:
Насколько я помню, остатки по складам только для информации используются. Основное поле — CATALOG_QUANTITY, наличие считается по нему, оно и уменьшается при покупке.
Файл /bitrix/php_interface/init.php подключается при каждом исполнении страницы. Там можно объявить все что нужно. Вот, почитайте про порядок выполнения страницы.
Если индексация подвисает, попробуйте консоль браузера открыть, возможно вы там увидите сообщение об ошибке 504 Gateway Timeout. Я попадал в такую ситуацию, проблема решилась, как ни странно, выставлением большого шага (10000 секунд), и полной индексацией. Либо наоборот, поставьте шаг поменьше, например 60 секунд, и переиндексируйте.
Можно в result_modifier.php переопределить службы доставки. Установите какое-то значение местоположения по умолчанию, например Москву, и исходя из этого делайте выборку служб доставки методом CSaleDelivery::GetList.
Длинный список местоположений это совершенно неудобно. Во-первых, сложно искать нужный вариант, во-вторых малых деревень там действительно может просто не оказаться. Как правило в большинстве случаев достаточно минимума местоположений — Москва и Московская область, Питер и Ленинградская область, регионы. Эти три пункта можно вывести радио-кнопками, и на основании их считать стоимость доставки. Дополнительно нужно сохранить в свойстве заказа текстовый адрес. А если, к примеру, прикрутить к полю адреса автозаполнение от яндекс.карт, то будет совсем удобно для покупателя.
Проблема наблюдается в Google Chrome (версия 32.0.1700.107) и Opera (версия 19.0.1326.59). В Firefox и последнем IE все в порядке.
Ядро проекта не модифицировалось, и я подозреваю, что все началось после недавнего масштабного обновления webkit'a, когда в Chrome перерисовались стандартные контролы, типа чекбокса, скроллов и т.п.
Версия Bitrix: Управление сайтом 12.0.6
Может быть кто-то сталкивался с подобной проблемой? Я, признаться, немного в растерянности. Бросаться дебажить js-код в админке не хочется совершенно, хотя скорее всего проблема именно там.
По сути вам нужно заменить использование этого метода на что-то свое: 1. Вы можете искать пользователя по email и, если такой пользователь найден, привязать заказ к нему. Потенциально это дыра в безопасности, такого пользователя ни в коем случае нельзя авторизовать, т.к. зная email админа, злоумышленник может оформить на него заказ и авторизоваться на сайте под админской учеткой. Кроме того, злоумышленник может завалить любой чужой email письмами о заказах.
2. Также вы можете самостоятельно генерировать уникальный логин, добавляя случайную строку к email'у, обрезанному до знака @. Главное не забыть в настройках главного модуля поставить флаг "Не проверять уникальность email при регистрации". При таком раскладе у вас будет куча пользователей с одинаковыми email'ами и разными логинами.
Если он выдает ошибку "Элемент не найден", значит подключается файл element.php, который находится в шаблоне комплексного элемента каталога. В принципе вы можете сделать там проверку текущей страницы методом CMain::GetCurPage, и в зависимости от результата подключить либо компонент детального просмотра товара, либо что-то другое, список разделов например.
В нем вы можете получить id заказа. Вариантов тут несколько, но хоть один должен сработать — $arResult['ORDER_ID'], $arResult['ORDER']['ID'] или $_REQUEST['ORDER_ID'].
По id заказа вы можете вытащить все нужные вам данные. Если речь о списке товаров, то поможет функция CSaleBasket::GetList.
А то что решить задачу можно только с использованием сессии, и другого способа нет — это неправда.