Как убрать

[Jordansky]

У меня вопрос в локализации Xenforo в правой панели хотел убрать Команду форума и пользователей онлайн. но не знаю как сделать подскажите как это сделатьь

1. Зайдите в Внешний вид (Appearance) → Виджеты (Widgets) .
2. Найдите в списке виджет "Пользователи онлайн" (Members Online) — он один, в нём сидят оба блока.
3. Откройте его для редактирования и просто снимите галочку с пункта "Включить блок 'Команда онлайн'" (Enable Staff Online block) . После сохранения блок с командой исчезнет.
4. Если хотите убрать вообще весь блок "Пользователи онлайн", можете для этого же виджета изменить его Позицию (Position) на (none) или просто отключить его полностью .

 

[Jordansky]

Здравствуйте. Перенес форум с древней версии xf до xenforo 2.3.10.
Бьюсь весь вечер. Почему то гость(не залогиненный пользователь) использует права зарегистрированного! И ему безразлично что я меняю в правах гостя.
Если зарегистрироваться пользователь использует те же самые права зарегистрированного, то есть я не могу разделить гостя и зарегистрированного. Проверял через бд аккаунты у этих пользователей valid = 1.
Что может быть такое?
Из за этого конкретно не могу запретить гостям писать сообщения и добавлять темы ...

здравствуйте. Скорее всего, проблема в том, что вы для группы гостей ставите значение "Нет" вместо "Никогда".
В XenForo права работают по принципу приоритета, и значение "Никогда" имеет высший приоритет. Если вы просто ставите "Нет", это право может переопределяться настройками других групп или общими настройками узлов. Чтобы гарантированно запретить гостям писать сообщения, нужно зайти в настройки группы "Незарегистрированные/Неподтвержденные" и для прав "Создавать новые темы" и "Отвечать в темах" установить значение "Никогда".
Если это не помогает, используйте инструмент "Анализ разрешений" в админ-панели. Выберите любого зарегистрированного пользователя, и система покажет, откуда именно у него берутся те или иные права. Часто оказывается, что пользователь состоит в дополнительных группах, которые дают ему расширенные права, и именно они переопределяют настройки для гостя.
Проверьте также настройки прав для конкретных разделов форума, потому что права на уровне узлов могут переопределять глобальные настройки. Если в конкретном разделе гостям разрешено писать, это будет работать даже при глобальном запрете.

 

[Jordansky]

Всем доброго. Подскажите как сделать отображение подфорумов, определенных с id на мобильной версии

Доброго времени суток. Чтобы отобразить подфорумы на мобильной версии, вам нужно добавить немного CSS-кода в шаблон extra.less.

По умолчанию XenForo скрывает список подфорумов на узких экранах, но это легко исправить. Вам подойдут два основных способа.

Первый способ — отобразить все подфорумы. Добавьте в extra.less следующий код, и список подфорумов появится на всех мобильных устройствах :


@media (max-width: @xf-responsiveMedium) {
.node-subNodesFlat {
display: block;
}
}

Второй способ — отобразить подфорумы с конкретными ID. Если вы хотите показывать подфорумы только для определённых разделов, используйте этот код, подставив нужные ID :

@media (max-width: @xf-responsiveMedium) {
.node--id1, .node--id2, .node--id3 {
.node-subNodesFlat {
display: block;
}
}
}

Замените 1, 2, 3 на ID нужных вам форумов. ID раздела можно посмотреть в адресной строке при редактировании узла в панели администратора .

Перед тем как применять код, убедитесь, что в настройках стиля для подфорумов выбран вариант отображения "Listed below node" (Список под узлом) .

Надеюсь, это поможет решить вашу задачу. Если что-то пойдёт не так, пишите.

 

[Jordansky]

Друзья, выручайте, появилась эта неприятная штука при обновлении с 2.2 на 2.3.
В мобильной версии (неважно PWA или просто в браузере) - при нажатии на меню реакций с целью выбора реакции из списка (ну т.е. если быстро тапнуть, будет лайк по умолчанию, а если нам надо другую - зажимаем и они все всплывают для выбора)., так вот при таком нажатии - поверх самих реакций вылезает стандартное меню браузера, как при зажатии ссылки ("Открыть в новой вкладке", "Копировать как ссылку" и т.д.) Чтобы вернуться к выбору реакции, нужно сначала смахнуть это "лишнее", затем только можно выбрать реакцию.
Возможно дело не в версии, а в том, что при обновлении затер какие-то внесенные вручную правки на эту тему. Но факт, что на копии до обновления проблемы нет, а на 2.3 - есть.
Направьте, куда копнуть.

Это известная проблема, которая возникает при обновлении XenForo до версии 2.3. Она заключается в том, что в мобильных браузерах, особенно на Android, длительное нажатие для вызова меню реакций конфликтует со стандартным контекстным меню браузера .

Проблема в том, что система не может отличить ваше намерение открыть меню реакций от обычного долгого нажатия на ссылку.

Официальное решение состоит в том, чтобы отключить контекстное меню браузера для этого конкретного элемента. Сделать это можно через небольшое изменение в шаблоне.

Вам нужно отредактировать шаблон, отвечающий за отображение кнопки реакции. Найдите в нем тег <xf:reaction ... /> и добавьте внутрь атрибут oncontextmenu="return false" .

Вот как это будет выглядеть в коде:

Было:

<xf:reaction id="{$reaction}"
content="{$content}" link="{$link}" params="{$params}" list="{$list}" class="{$class}"
init="true" hasreaction="{$hasReaction}" small="true" showtitle="true" />

Стало:

<xf:reaction id="{$reaction}"
content="{$content}" link="{$link}" params="{$params}" list="{$list}" class="{$class}"
init="true" hasreaction="{$hasReaction}" small="true" showtitle="true" oncontextmenu="return false" />
``` [citation:1]

Это следует сделать для всех используемых стилей, особенно если они не наследуют изменения от родительского стиля [citation:1].

**Что касается того, почему это возникло при обновлении**. Это не баг, а, скорее, особенность новой версии. В XenForo 2.3 изменилась обработка некоторых событий, и это привело к конфликту с поведением браузеров. Поэтому на вашей копии до обновления, где работала старая версия, проблема и не проявлялась [citation:1][citation:3].

Если это не поможет, проверьте, нет ли у вас установленных сторонних дополнений, которые могут влиять на работу реакций. В редких случаях проблема может быть вызвана именно ими [citation:5]. Также стоит проверить, не было ли в ваших кастомных стилях изменений, которые могли повлиять на это поведение [citation:7].

 

[Jordansky]

Скорее всего, проблема в том, что верстка "едет" из-за особенностей RTL (Right-to-Left) или локализации CSS-свойств. Это известное поведение XenForo: движок автоматически "переворачивает" некоторые CSS-свойства для языков с направлением письма справа налево.

В вашем случае, возможно, автоматическое преобразование задевает свойства, которые должны оставаться неизменными в обоих направлениях.

Решение не требует правки всех шаблонов вручную. В XenForo для этого есть встроенные механизмы:

1. Используйте префиксы -ltr- или -rtl- в LESS-коде. Если вам нужно, чтобы какое-то CSS-свойство работало одинаково для всех языков (не менялось при переключении RTL), вы можете добавить префикс -ltr-rtl-. Например:
   
   -ltr-rtl-margin-left: 3px;
   Это гарантирует, что правило будет применено как margin-left независимо от направления языка. Официальный представитель XenForo подтвердил, что это рабочий способ.
2. Используйте условные конструкции в LESS, чтобы самим контролировать отображение.
   Вы можете явно проверить, включен ли режим RTL, и применить нужный стиль:
   
   & when(@ltr) {
   background-position: left center;
   }
   & when(@rtl) {
   background-position: right center;
   }
   Этот подход удобен, когда правил для LTR и RTL много.
3. Для точечной фиксации найдите конкретный элемент и измените его стиль через шаблон extra.less. Иногда проще переопределить проблемный стиль, чем искать его причину в коде ядра. В extra.less вы можете переопределить стиль с !important, чтобы принудительно задать нужное выравнивание или отступы.

В двух словах: вам не нужно править все шаблоны вручную. Скорее всего, достаточно добавить небольшой блок кода в extra.less, используя префиксы или условия, чтобы верстка перестала "ехать" при переключении языка. Если вы опишете, какой именно блок или элемент "едет" (например, username, блок сообщений, кнопки), можно подсказать более конкретный код.

Всем доброго вечера. Едет верстка из-за локализации, есть какое-то тривиальное решение или придется править ручками? Стиль без модификаций, плагины не конфликтуют.

Посмотреть вложение 162505
Посмотреть вложение 162504

 

[Jordansky]

Журнал ошибок сервера

• Swift_TransportException: Email to syndicateola@gmail.com failed: Connection could not be established with host connect.smtp.bz :stream_socket_client(): unable to connect to tcp://connect.smtp.bz:587 (A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. )
• src\vendor\swiftmailer\swiftmailer\lib\classes\Swift\Transport\StreamBuffer.php:269
• Сгенерировано пользователем: Неизвестная учётная запись
• 29.04.2026 в 10:30

Трассировка стека​

#0 [internal function]: Swift_Transport_StreamBuffer->{closure}(2, 'stream_socket_c...', 'C:\\OSPanel\\doma...', 272, Array)
#1 src\vendor\swiftmailer\swiftmailer\lib\classes\Swift\Transport\StreamBuffer.php(272): stream_socket_client('tcp://connect.s...', 10060, 'A connection at...', 30, 4, Resource id #207)
#2 src\vendor\swiftmailer\swiftmailer\lib\classes\Swift\Transport\StreamBuffer.php(58): Swift_Transport_StreamBuffer->establishSocketConnection()
#3 src\vendor\swiftmailer\swiftmailer\lib\classes\Swift\Transport\AbstractSmtpTransport.php(143): Swift_Transport_StreamBuffer->initialize(Array)
#4 src\XF\Mail\Mailer.php(286): Swift_Transport_AbstractSmtpTransport->start()
#5 src\XF\Mail\Queue.php(138): XF\Mail\Mailer->send(Object(Swift_Message), Object(Swift_SmtpTransport), Array)
#6 src\XF\Job\MailQueue.php(12): XF\Mail\Queue->run(G)
#7 src\XF\Job\Manager.php(258): XF\Job\MailQueue->run(G)
#8 src\XF\Job\Manager.php(200): XF\Job\Manager->runJobInternal(Array, G)
#9 src\XF\Job\Manager.php(84): XF\Job\Manager->runJobEntry(Array, G)
#10 job.php(43): XF\Job\Manager->runQueue(false, 8)
#11 {main}

Содержимое запроса​

array(4) {
["url"] => string(14) "/forum/job.php"
["referrer"] => string(36) "

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

"
["_GET"] => array(0) {
}
["_POST"] => array(0) {
}
}

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

Проблема: Ваш сервер не может соединиться с SMTP-хостом connect.smtp.bz по порту 587. Причина: либо хост недоступен, либо ваш сервер блокирует исходящие подключения к этому порту.
Вот что нужно сделать:
Первое — проверьте доступность SMTP-сервера.
Попробуйте подключиться к нему вручную. Если у вас есть доступ к командной строке сервера, выполните команду:
telnet connect.smtp.bz 587

Если подключение не устанавливается или зависает, проблема не в XenForo, а в сетевой доступности.
Второе — проверьте настройки вашего хостинга.
Если вы используете локальный сервер OpenServer (как видно из трассировки), то проблема может быть в том, что ваш локальный сервер не имеет доступа в интернет для отправки почты через внешний SMTP. На хостинге часто блокируют исходящие подключения к нестандартным SMTP-серверам, требуя использовать их собственный почтовый сервер.
Третье — попробуйте изменить порт или протокол.
В настройках почты в XenForo попробуйте:

• Сменить порт с 587 на 465 (SSL) или 25.
• Изменить протокол с TLS на SSL.
• Убедиться, что в поле "Хост" указан именно connect.smtp.bz, а не smtp.connect.smtp.bz или что-то подобное.

Четвертое — временное решение.
Если вам нужно срочно убрать ошибку из логов, пока вы разбираетесь с почтой, можно отключить отправку писем через админку: Настройки → Параметры → Почтовые настройки → Отключить отправку почты и поставить "Включено". Но это только временная мера, чтобы журнал ошибок не забивался.
Пятое — свяжитесь с хостинг-провайдером.
Скорее всего, проблема именно в исходящих подключениях. Спросите у техподдержки вашего хостинга, разрешены ли исходящие подключения к внешним SMTP-серверам, и если нет, попросите открыть порт 587 для исходящих соединений. Если не разрешат, используйте SMTP-сервер самого хостинга.
Начните с проверки доступности хоста через командную строку, это сразу покажет, ваша это проблема или проблема SMTP-провайдера.

 

[Jordansky]

приветствую, подскажите пожалуйста у меня на форуме регистрируется человек и пишется что он ожидает подтверждения и надо вручную ставить "Активен" как такое отключить и чтобы сразу был "Активен" ?

Чтобы убрать необходимость ручного подтверждения, нужно отключить две соответствующие опции в настройках регистрации. Они находятся в разных местах административной панели.

Пошаговая инструкция​

1. Войдите в административную панель вашего форума.
2. Отключите подтверждение по электронной почте. Перейдите в раздел Настройки (Setup) → Параметры (Options) → Регистрация пользователя (User registration) . Найдите там опцию "Включить подтверждение по электронной почте" (Enable email confirmation) и снимите с неё галочку . Это отключит отправку писем со ссылкой для активации .
3. Отключите ручное одобрение администратором. В этом же разделе найдите опцию "Включить ручное одобрение" (Enable manual approval) и убедитесь, что она тоже отключена . Это отключит режим, при котором новые аккаунты ожидают одобрения администратором .
4. Сохраните изменения.

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

На случай, если ничего не изменилось​

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

 

[Jordansky]

Здравствуйте, при работе с текстом (создание новых тем и сообщений, редактирование в визуальном редакторе, превью), появляется следующая ошибка:
Посмотреть вложение 161897
1. В настройках количества символов сообщений ограничения не установлены (значение: 0)
2. Ошибка в журнале ошибок севера не создаётся.
3. Свободное место на диске VPS имеется.
4. Ошибка во всех браузерах и разных устройствах.

Пробовал восстановить БД командой, перезагрузить сервер - не помогло.

Пи работе с малым количеством текста - ошибка не возникает, только при средних и больших объёмах символов.
Пожалуйста подскажите как исправить?

Здравствуйте. Судя по описанию, проблема не в настройках XenForo (лимит сообщений вы отключили), а в ограничениях, установленных на самом сервере. Ошибка возникает именно при большом объёме текста, и это классический симптом того, что один из параметров сервера не рассчитан на обработку такого объёма данных.

Сама ошибка может быть вызвана разными причинами, и я перечислю их от наиболее вероятной к менее вероятной.

Настройка лимитов PHP (самая частая причина)​

Ваш сервер использует PHP, который имеет два критических параметра, ограничивающих объём данных, отправляемых через формы :

• upload_max_filesize — максимальный размер одного загружаемого файла.
• post_max_size — максимальный общий размер всех данных, отправленных в одном POST-запросе (включая текст сообщения, вложения, скрытые поля формы) .

Если общий размер вашего сообщения (особенно с учётом форматирования и вложений) превышает значение post_max_size, сервер отклонит запрос и выдаст подобную ошибку, даже если в настройках XenForo лимит снят .

Решение: Вам нужно увеличить значения этих параметров в файле php.ini вашего сервера . Местоположение этого файла зависит от настроек вашего хостинга или VPS . Если вы не знаете, как это сделать, обратитесь в техническую поддержку хостинга с просьбой увеличить post_max_size и upload_max_filesize до нужных вам значений. После изменения параметров не забудьте перезагрузить веб-сервер (Apache или Nginx) .

Ограничения веб-сервера (Nginx/Apache)​

Даже если PHP настроен корректно, сам веб-сервер может иметь свои лимиты. Например, в Nginx есть параметр client_max_body_size, который ограничивает размер тела запроса от клиента .

Решение: Проверьте конфигурацию вашего веб-сервера и при необходимости увеличьте значение client_max_body_size в Nginx или аналогичные параметры в Apache .

Специфические расширения безопасности (Suhosin)​

На некоторых серверах установлено расширение безопасности Suhosin, которое также может накладывать ограничения на размер передаваемых данных (например, suhosin.post.max_value_length или suhosin.request.max_value_length) . Это расширение сейчас используется реже, но если оно активно, его настройки могут переопределять стандартные лимиты PHP .

Решение: Если у вас включен Suhosin, найдите его конфигурационный файл и увеличьте значения параметров, связанных с max_value_length и max_vars для POST- и REQUEST-данных .

Особенности редактора XenForo и вставки изображений​

Иногда ошибка может возникать не из-за объёма текста, а из-за способа вставки изображений. В некоторых браузерах (особенно в старых версиях Firefox) при перетаскивании изображения в редактор оно могло вставляться не как ссылка, а в виде длинной строки base64-кода, что резко увеличивало размер отправляемых данных и приводило к этой ошибке . Хотя в современных версиях XenForo эта проблема частично решена, стоит помнить о такой возможности.

Решение: При вставке изображений старайтесь использовать кнопку "Вставить изображение" или загружать их через вложения, а не перетаскивать их напрямую в область текста .

Рекомендуемый план действий​

1. Самый быстрый и надёжный способ: Обратитесь в поддержку вашего хостинга или VPS. Опишите им проблему: "При отправке больших сообщений возникает ошибка The submitted message is too long to be processed. При этом в XenForo лимиты сняты. Прошу проверить и увеличить параметры post_max_size и upload_max_filesize в PHP, а также client_max_body_size в настройках веб-сервера." Техподдержка сможет быстро найти и изменить нужные параметры на вашем сервере.
2. Если вы администрируете сервер самостоятельно, найдите файл php.ini (его путь можно узнать через phpinfo в админке XenForo: admin.php?tools/phpinfo), увеличьте значения post_max_size и upload_max_filesize (например, до 50M или 100M), затем перезагрузите веб-сервер.
3. После этого проверьте, появляется ли ошибка при отправке большого сообщения. Если да, проверьте логи ошибок веб-сервера (обычно они находятся в /var/log/nginx/error.log или /var/log/apache2/error.log) — в них может быть более точная информация о причине сбоя .

 

[Jordansky]

Форум работает криво. Нужна помощь Email to имя@mail.ru from имя@домен.ru failed: Failed to authenticate on SMTP server with username "имя@домен.ru" using 1 possible authenticators. Authenticator LOGIN returned Expected response code 235 but got code "535", with message "535 Incorrect authentication data ".

Трассировка стека
#0 src/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/EsmtpTransport.php(371): Swift_Transport_Esmtp_AuthHandler->afterEhlo(Object(XF\Mail\SmtpTransport))
#1 src/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php(148): Swift_Transport_EsmtpTransport->doHeloCommand()
#2 src/XF/Mail/Mailer.php(294): Swift_Transport_AbstractSmtpTransport->start()
#3 src/XF/Mail/Queue.php(148): XF\Mail\Mailer->send(Object(Swift_Message), Object(XF\Mail\SmtpTransport), Array)
#4 src/XF/Job/MailQueue.php(12): XF\Mail\Queue->run(8)
#5 src/XF/Job/Manager.php(260): XF\Job\MailQueue->run(8)
#6 src/XF/Job/Manager.php(202): XF\Job\Manager->runJobInternal(Array, 8)
#7 src/XF/Job/Manager.php(86): XF\Job\Manager->runJobEntry(Array, 8)
#8 job.php(43): XF\Job\Manager->runQueue(false, 8)
#9 {main}
Содержимое запроса
array(4) {
  ["url"] => string(8) "/job.php"
  ["referrer"] => string(58) "https://домен.ru/threads/тема.2474/page-283"
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(0) {
  }
}

Здравствуйте. Ваша ошибка чётко указывает на проблему аутентификации на SMTP-сервере: сервер возвращает код 535 Incorrect authentication data, что означает "неверные данные аутентификации". Это не ошибка XenForo, а проблема с настройками почты или доступом к SMTP.

Наиболее вероятные причины и решения:​

1. Неправильный пароль (самая частая причина)
Убедитесь, что в настройках почты XenForo вы используете пароль от ящика, а не пароль от панели управления или хостинга. Если вы меняли пароль от почты, обновите его в настройках форума. Если используется двухфакторная аутентификация на почтовом ящике, обычный пароль не подойдёт — нужно создать пароль приложения в настройках безопасности вашей почтовой службы.

2. Неправильный логин
Для большинства SMTP-серверов в качестве логина нужно указывать полный адрес электронной почты (например, info@ваш-домен.ru), а не только имя пользователя. Проверьте, так ли у вас заполнено поле "Имя пользователя" в настройках SMTP.

3. Блокировка SMTP-доступа хостингом
Многие хостинг-провайдеры блокируют исходящие подключения к внешним SMTP-серверам на нестандартных портах для борьбы со спамом. Убедитесь, что ваш хостинг не блокирует порт 587 или 465 для исходящих соединений. Если блокирует, используйте SMTP-сервер самого хостинга.

4. Неправильный выбор шифрования (SSL/TLS)
Для порта 465 обычно используется SSL. Для порта 587 — TLS. Проверьте, какое шифрование требует ваш SMTP-провайдер. Если стоит не тот тип, аутентификация может провалиться.

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

6. Неверный SMTP-хост (неправильное доменное имя)
Убедитесь, что вы правильно указали адрес SMTP-сервера. Например, для Яндекса это smtp.yandex.ru, для

У Вас недостаточно прав для просмотра ссылок. Вход или Регистрация

— smtp.mail.ru, для Gmail — smtp.gmail.com. Если используете SMTP вашего хостинга, уточните у них правильный адрес.

Что делать прямо сейчас:​

1. Проверьте настройки в админке. Зайдите в Настройки → Параметры → Почтовые настройки и перепроверьте все поля: хост, порт, имя пользователя (должен быть полный email), пароль, тип шифрования.
2. Проверьте логи SMTP-сервера. Если у вас есть доступ к панели управления почтой, посмотрите логи подключений — там может быть более детальная причина отказа.
3. Временно используйте PHP-почту. Если нужно срочно восстановить работу форума, переключите в настройках почты способ отправки с "SMTP" на "По умолчанию (PHP)" — это будет использовать встроенную функцию PHP mail(). Это временное решение, чтобы почта хотя бы как-то работала, пока вы разбираетесь с SMTP.
4. Создайте пароль приложения. Если вы используете почту от Google или Яндекс, создайте отдельный пароль для приложения в настройках безопасности учётной записи и используйте его в настройках форума вместо основного пароля.

Если вы всё перепроверили, а ошибка остаётся, обратитесь в техническую поддержку вашего хостинг-провайдера или к вашему почтовому администратору с этим текстом ошибки. Они проверят логи своего SMTP-сервера и скажут, почему он отклоняет аутентификацию с вашего IP-адреса.

 

[Jordansky]

У меня проблема на форуме. Когда я ставлю нестандартное название и сохраняю он не сохраняется и остаётся тот же new member что делать?

Здравствуйте! Судя по всему, проблема не в ошибке сохранения названия, а в том, что у пользователя уже установлено индивидуальное (пользовательское) звание, которое имеет более высокий приоритет и переопределяет стандартную лестницу званий . Когда вы пытаетесь изменить звание в лестнице, оно не меняется для пользователей, у которых в профиле заполнено поле «Индивидуальное звание».

Как это исправить​

1. Проверьте у конкретного пользователя:
   • Зайдите в админ-панель (admin.php) → Пользователи → Поиск пользователя.
   • Найдите этого пользователя и откройте его профиль.
   • Посмотрите поле «Индивидуальное звание» (Custom title). Если оно заполнено — очистите его (удалите текст и сохраните). После этого у пользователя начнёт отображаться звание из лестницы или из группы .
2. Если таких пользователей много (массовое исправление):
   • Возможно, это осталось после импорта из другой системы (например, vBulletin), когда звания перенеслись в поле индивидуального звания .
   • В этом случае проще всего очистить это поле у всех пользователей через запрос к базе данных (предварительно сделав бэкап!) :
     
     UPDATE xf_user SET custom_title = '';
   • Или через Инструменты обслуживания (admin.php?tools/rebuild) запустите задачу «Перестроить кеш пользователей» (Rebuild user caches) — это может пересчитать звания для всех пользователей .
3. Проверьте другие приоритеты:
   • Если у пользователя стоит звание, назначенное группе пользователей (в настройках группы есть поле «Переопределение звания»), оно тоже имеет приоритет над лестницей . Проверьте, в каких группах состоит пользователь и какие там стоят настройки званий.
   • Убедитесь, что у пользователя включено право «Редактировать индивидуальное звание». Если оно отключено, это не мешает отображению звания из лестницы, но на всякий случай проверьте .