Денис Сон (Все сообщения пользователя)

На мой взгляд, подставляете клиента. Когда этот проект перейдёт от вас к другому программисту, начнётся экшен..

Пока не поздно, лучше переделать.. Чем свойства инфоблока не устроили?

С такой ошибкой никогда не сталкивался, но, судя по ошибке, нужно проверить правила обработки адресов в /urlrewrite.php - возможно, там где-то регулярное выражение некорректное указано.

Получается, ни сейчас, ни в ближайшем будущем - переводить БУС-сайты на PostgreSQL не стоит?

Обычно в таких случаях быстрее просто посмотреть ситуацию вживую, чем текстом перебирать возможные варианты проблемы )

В таком случае нужно смотреть много всего. Начать с правил обработки адресов - проверить корректность их указания для новостей. На странице детальной новости посмотреть - отдаёт ли страница 404 или нет; включить режим правки, посмотреть - доступна ли кнопка «Изменить элемент». Если да - значит, новость определяется, но не показывается, если нет - значит, новость и не определяется.

В общем, нужно провести мини-отладку по следующему общему алгоритму: корректно ли настроены правила обработки адресов? корректны ли настройки шаблонов адресов в настройках инфоблока и в компоненте? применяются ли эти шаблоны Битриксом для страницы детальной новости? Активны ли в целом инфоблок и элемент?

Если показывается только шапка сайта, а подвала нет - вероятно, на странице происходит ошибка, и выполнение прерывается. Откройте исходный код страницы (Ctrl-U) и прокрутите до конца - там может быть либо текст ошибки, либо сообщение что произошла ошибка (и что нужно в /bitrix/.settings.php включить вывод ошибок - в таком случае нужно временно сделать так, как написано, чтобы потом увидеть полный текст ошибки).

Добрый день.
По сути, можно реализовать. Но нужно понимать какие будут ограничения: в первую очередь, будут недоступны фильтры по данным свойствам. Плюс разные другие побочные эффекты и неудобства. Также придётся в админке делать какое-то отображение свойств, чтобы контент-менеджер мог контролировать данные.
Т.е. по сути это будет отдельный функционал для карточки товара в публичной части.

Суть в том, что процесс обновления товаров в случае разных импортов (и при обновлении в форме товара) заключается в том, что сначала обновляется товар (вызывается, в числе прочего, OnBeforeIBlockElementUpdate, где меняется значение товара в торговом каталоге), а сразу после этого выполняется обновление товара в торговом каталоге.

Т.е. выполняется запись, и почти сразу же выполняется запись значением из импорта (или из формы). В данном случае нужно использовать событие обновления продукта в торговом каталоге.

Вопрос уже много раз обсуждали, легко гуглится, например: https://ru.stackoverflow.com/questions/556838/403-forbidden-к-папке-default-Битрикс

Суть в том, что веб-сервер по умолчанию блокируют доступ к файлам и папкам, начинающимся с точки (т.е. если в запросе есть обращение к .../themes/.default/modules.css - такой запрос будет заблокирован веб-сервером). На локальном сервере можно совсем это отключить, либо добавить туда проверку на папку .default.

Обновления модуля - это архивы, которыми обновляются модули из Маркетплейс, они содержат изменённые файлы, файл описания и файл updater.php, который выполняет всю логику установки (кроме копирования основных файлов). Он как раз делается так, чтобы не переустанавливать модуль. Но это для случаев, когда у вас свой модуль выложен в Маркет (хотя бы в неактивном состоянии).

А если модуль существует только на данном сайте, такой скрипт придётся писать (и запускать) отдельно, учитывая все изменения между старой версией и новой - основные файлы модуля, скрипты и стили, база данных, изменения в публичной части. Т.е. в принципе всё то же самое что делают обычно все разработчики модулей при каждом обновлении (дополнительно нужно скопировать основные файлы), только запускать этот скрипт нужно будет самостоятельно.

ID пользователя - это как бы владелец данного агента - указанный пользователь или система (если не указано), это не от имени кого выполняется агент.
Документация говорит что авторизация в агентах запрещена, хотя с подобным вопросом никогда не сталкивался. Но логически неверно подразумевать работу в агенте из-под какого-то пользователя, т.к. агенты - это код, который может быть выполнен когда угодно, на хите любого пользователя. Поэтому удаление должно быть доступно для любого пользователя. А если это недопустимо - значит, скорее всего, вариант удаления через агенты не подходит.

Добрый день. Условие не совсем корректно, нужно сначала проверять что Fetch() не пуст:И тут уже нужно проверить - если $res равен false, значит не может получить данные инфоблока (если $res пуст [false], то получать $res['CODE'] уже бессмысленно), т.е. тут две проверки должно быть. Если $res == false, то проблема, скорее всего, в правах доступа. В таком случае нужно использовать CIBlock::GetList вместо CIBlock::GetByID() и в фильтре указать "CHECK_PERMISSIONS" => "N". Либо нужно в настройках инфоблока дать доступ на чтение для всех.

Уже лет 10 на Timeweb, самый лучший хостинг. Но нужно понимать, что VPS это не виртуальный хостинг, там техподдержка выполняет не все задачи - часть задач лежит на вашей стороне как клиента.
Подскажите что конкретно у вас подлагивает, и как это проявляется. У нас там два своих проекта, много клиентов - проблем нет.

Добрый день. Посмотрите этот модуль: https://marketplace.1c-bitrix.ru/solutions/webdebug.seo/ - там, в числе прочего, есть генератор карты сайта с возможностью выгрузки картинок, работает в том числе по cron.

Мои предыдущие сообщения - лишь направление для работы - не думать что есть какое-то относительно простое решение. И замечание относительно фразы "Нужно как-то избавиться от этой "фичи" битрикса" - это не фича, а архитектурное решение. Весь Битрикс сделан так, что пользователи всех сайтов - едины. А потому, чтобы решить такую задачу, нет особого смысла писать на форуме как это сделать в надежде получить какой-то готовый рецепт - нужно писать в ветке по работе - описать задачу и спросить кто за сколько готов сделать.

А описывать здесь варианты решений - вряд ли кто-то будет, только если, опять же, в виде "направлений куда копать". Но таких немного: либо полностью отказаться от многосайтовости и разделить сайты, чтобы они не были в единой админке, либо полностью поставить крест на стандартной системе пользователей и авторизации Битрикса и делать своё с нуля или на основе текущей (оставив, тем не менее, эту возможность для админов), либо пытаться везде где можно добавлять проверки пользователя на привязку к какому-то сайту (напр., можно использовать имеющееся поле «Сайт по умолчанию для уведомлений») - но я почти уверен что не обойтись без влезания в файлы ядра, т.к. этот вопрос фундаментальный, и нигде не предполагается никакого разделения пользователей по разным сайтам, цитата из документации: аудитория проектов едина, и им будет понятна сквозная авторизация на всех сайтах. Возможно, здесь можно обойтись какими-то базовыми вещами, например, добавить пользователям свою привязку к сайту (или разные аккаунты пользователя на каждый сайт), и просто запрещать авторизоваться там, где у них нет привязки - это можно сделать через обработчики. Но также придётся не забыть про восстановление пароля, страницы профиля, и др. Тут опять же можно рассматривать подварианты - либо единый аккаунт с привязками, либо на каждый сайт свой аккаунт.

И, кстати, ещё вариант: не разделять и ничего не менять в авторизации. А только добавить привязку, и проверять это уже на сайте, и просто не разрешать то, что не нужно.

Многосайтовость - не для того чтобы сделать независимые сайты в одной админке, а чтобы сделать систему сайтов. Например, Битрикс - куча сайтов, и там при регистрации не нужно спрашивать к какому сайту привязать аккаунт - к главному или к сайту маркетплейса.

А делать в одной админке одновременно сайт по продаже алкоголя и сайт школы - совсем неправильно.

Если уж нужно сделать так, то допиливайте функционал индивидуально на своих сайтах, но это будет очень больно..

Тогда вам нужно избавиться от такой "фичи" Битрикса как многосайтовость

Т.к. при многосайтовости база пользователей общая для всех сайтов, нормально разделить её нет возможности.

В таких случаях часто помогает удаление куков для данного сайта.

Вопрос в другом. Вы написали "Перестала работать возможность для админа авторизоваться под любым пользователем", а по факту если вы видите "Ошибка авторизации! Доступ запрещен. Просмотр файла /bitrix/admin/user_edit.php запрещен" то вы уже авторизованы под новым пользователем.

Исследуйте вопрос и проверьте это: узнайте, что получаете после такой авторизации: либо просто она не работает, либо она сработала и вы просто неверно трактуете сообщение об ошибке.

Другими словами, если неделю назад вы успешно авторизовывались от имени контент-менеджера или администратора интернет-магазина (которым разрешили доступ к редактированию своего профиля), а сейчас пытаетесь то же самое сделать с пользователем, который не имеет прав к редактированию своего профиля, то тут нельзя говорить что перестало работать.

Всё просто: вы авторизовываетесь от имени того, кто не имеет права на просмотр страницы профиля пользователя в админке. Просто перейдите, например, в публичную часть сайта - увидите логин авторизованного. Если это, например, контент-менеджер - увидите и в админке некоторые возможности. А конкретно к странице профиля пользователя доступа нет у этого новоавторизованного пользователя.

Это и есть контроль дубликатов. Отключите эту галочку, тогда всё станет как обычно.

Посмотрите в настройках главного модуля опцию «Контролировать загрузку дубликатов файлов» - если я правильно понимаю, речь об этом.

Добрый день.
С модулем Антирутин эта задача решается за несколько минут.

Событие OnBeforeEventAdd работает только для метода CEvent::Send (из старого ядра).