Обновления модуля - это архивы, которыми обновляются модули из Маркетплейс, они содержат изменённые файлы, файл описания и файл updater.php, который выполняет всю логику установки (кроме копирования основных файлов). Он как раз делается так, чтобы не переустанавливать модуль. Но это для случаев, когда у вас свой модуль выложен в Маркет (хотя бы в неактивном состоянии).
А если модуль существует только на данном сайте, такой скрипт придётся писать (и запускать) отдельно, учитывая все изменения между старой версией и новой - основные файлы модуля, скрипты и стили, база данных, изменения в публичной части. Т.е. в принципе всё то же самое что делают обычно все разработчики модулей при каждом обновлении (дополнительно нужно скопировать основные файлы), только запускать этот скрипт нужно будет самостоятельно.
ID пользователя - это как бы владелец данного агента - указанный пользователь или система (если не указано), это не от имени кого выполняется агент. Документация говорит что авторизация в агентах запрещена, хотя с подобным вопросом никогда не сталкивался. Но логически неверно подразумевать работу в агенте из-под какого-то пользователя, т.к. агенты - это код, который может быть выполнен когда угодно, на хите любого пользователя. Поэтому удаление должно быть доступно для любого пользователя. А если это недопустимо - значит, скорее всего, вариант удаления через агенты не подходит.
Добрый день. Условие не совсем корректно, нужно сначала проверять что Fetch() не пуст:
Код
if($res = CIBlock::GetByID($query_id)->Fetch()){
if($res['CODE'] == $query_symbol){
echo 'Символьный код инфоблока с ИД 22 == line';
}
}
И тут уже нужно проверить - если $res равен false, значит не может получить данные инфоблока (если $res пуст [false], то получать $res['CODE'] уже бессмысленно), т.е. тут две проверки должно быть. Если $res == false, то проблема, скорее всего, в правах доступа. В таком случае нужно использовать CIBlock::GetList вместо CIBlock::GetByID() и в фильтре указать "CHECK_PERMISSIONS" => "N". Либо нужно в настройках инфоблока дать доступ на чтение для всех.
Уже лет 10 на Timeweb, самый лучший хостинг. Но нужно понимать, что VPS это не виртуальный хостинг, там техподдержка выполняет не все задачи - часть задач лежит на вашей стороне как клиента. Подскажите что конкретно у вас подлагивает, и как это проявляется. У нас там два своих проекта, много клиентов - проблем нет.
Мои предыдущие сообщения - лишь направление для работы - не думать что есть какое-то относительно простое решение. И замечание относительно фразы "Нужно как-то избавиться от этой "фичи" битрикса" - это не фича, а архитектурное решение. Весь Битрикс сделан так, что пользователи всех сайтов - едины. А потому, чтобы решить такую задачу, нет особого смысла писать на форуме как это сделать в надежде получить какой-то готовый рецепт - нужно писать в ветке по работе - описать задачу и спросить кто за сколько готов сделать.
А описывать здесь варианты решений - вряд ли кто-то будет, только если, опять же, в виде "направлений куда копать". Но таких немного: либо полностью отказаться от многосайтовости и разделить сайты, чтобы они не были в единой админке, либо полностью поставить крест на стандартной системе пользователей и авторизации Битрикса и делать своё с нуля или на основе текущей (оставив, тем не менее, эту возможность для админов), либо пытаться везде где можно добавлять проверки пользователя на привязку к какому-то сайту (напр., можно использовать имеющееся поле «Сайт по умолчанию для уведомлений») - но я почти уверен что не обойтись без влезания в файлы ядра, т.к. этот вопрос фундаментальный, и нигде не предполагается никакого разделения пользователей по разным сайтам, цитата из документации: аудитория проектов едина, и им будет понятна сквозная авторизация на всех сайтах. Возможно, здесь можно обойтись какими-то базовыми вещами, например, добавить пользователям свою привязку к сайту (или разные аккаунты пользователя на каждый сайт), и просто запрещать авторизоваться там, где у них нет привязки - это можно сделать через обработчики. Но также придётся не забыть про восстановление пароля, страницы профиля, и др. Тут опять же можно рассматривать подварианты - либо единый аккаунт с привязками, либо на каждый сайт свой аккаунт.
И, кстати, ещё вариант: не разделять и ничего не менять в авторизации. А только добавить привязку, и проверять это уже на сайте, и просто не разрешать то, что не нужно.
Многосайтовость - не для того чтобы сделать независимые сайты в одной админке, а чтобы сделать систему сайтов. Например, Битрикс - куча сайтов, и там при регистрации не нужно спрашивать к какому сайту привязать аккаунт - к главному или к сайту маркетплейса.
А делать в одной админке одновременно сайт по продаже алкоголя и сайт школы - совсем неправильно.
Если уж нужно сделать так, то допиливайте функционал индивидуально на своих сайтах, но это будет очень больно..
Вопрос в другом. Вы написали "Перестала работать возможность для админа авторизоваться под любым пользователем", а по факту если вы видите "Ошибка авторизации! Доступ запрещен. Просмотр файла /bitrix/admin/user_edit.php запрещен" то вы уже авторизованы под новым пользователем.
Исследуйте вопрос и проверьте это: узнайте, что получаете после такой авторизации: либо просто она не работает, либо она сработала и вы просто неверно трактуете сообщение об ошибке.
Другими словами, если неделю назад вы успешно авторизовывались от имени контент-менеджера или администратора интернет-магазина (которым разрешили доступ к редактированию своего профиля), а сейчас пытаетесь то же самое сделать с пользователем, который не имеет прав к редактированию своего профиля, то тут нельзя говорить что перестало работать.
Всё просто: вы авторизовываетесь от имени того, кто не имеет права на просмотр страницы профиля пользователя в админке. Просто перейдите, например, в публичную часть сайта - увидите логин авторизованного. Если это, например, контент-менеджер - увидите и в админке некоторые возможности. А конкретно к странице профиля пользователя доступа нет у этого новоавторизованного пользователя.
Новая страница создается с расширением .php на конце адреса, как исправить?, Новая страница создается с расширением .php на конце адреса, как исправить?
Значит у вас чуть более хитрая логика - действует некое правило обработки адресов, которое обрабатывает эту ситуацию (тогда дальше первой строки кода файла /404.php запрос не идёт).
Если не совсем понятно какое именно правило не работает, можете попробовать последовательно поотключать каждое (в файле urlrewrite.php), только не забудьте изначально создать бэкап этого файла.
Нужно отлаживать, подозреваю что ошибка где-то по невнимательности. Для начала убедиться что $eventManager->addEventHandler() здесь вообще срабатывает, т.е. что обработчик вообще назначается. Вы написали что назначается в методе класса, может банально туда выполнение не доходит. Если тут всё в порядке, то отлаживать сам метод CCatalogProduct::GetOptimalPrice(), запуская его напрямую.
Добрый день. В этом файле устанавливается код 404, а далее подключается файл /bitrix/header.php, т.е. всё ядро Битрикса - все скрипты, модули и т.д. - и там легко поменять статус на любой другой, в т.ч. на 200. Попробуйте в файле 404.php перенести эти две строки:
Код
CHTTP::SetStatus("404 Not Found");
@define("ERROR_404","Y");
чуть ниже, под строку с подключением /bitrix/header.php. Если не поможет - нужно будет исследовать, какой же код устанавливает статус 200.
При этом на VirtualBox есть некоторые вещи, которые делают повседневную работу удобнее. Например, работа в фоне, запуск/остановка по горячей клавише, и т.д.
Добрый день. PHP-функция each, согласно документации, удалена из PHP8, поэтому её использование теперь приводит к ошибке. Лучше всего обратиться к разработчику модуля mcart.bpfromtask. Если такой возможности нет - придётся самостоятельно. Нужно открыть файл /bitrix/modules/mcart.bpfromtask/include.php на строке 71, понять для чего используется each, и потом сделать то же самое, но без each.