Сообщаем об ошибках phpBB 3.3.x разработчикам

[rxu]

Об ошибках, выявленных в работе phpBB 3.3 Proteus, сообщаем в этой теме.
Ошибками является некорректная работа ядра phpBB, подтвержденная на последней актуальной версии phpBB, требующая устранения в коде ядра, и не связанная с работой расширений, сторонних стилей оформления, неверной работой серверного оборудования или серверного софта, а также с некорректными действиями администратора.
Запросы поддержки также не размещаются в данной теме.

[dimassamid]

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

[rxu]

Странно, т.к. при пустой таблице сессий логика кода работает по второму варианту. Ладно.

[dimassamid]

Да, логично, но таблица сессий почему-то всё равно влияет.

Я не грешил бы на движок, если бы не увидел точно такую же проблему на баг-трекере. Там у товарища один в один как у меня.

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

[rxu]

СУБД какая?
Автоматическая очистка сессий не отключена (session_gc)? Какая длительность сессии (session_length) установлена в настройках?

[im0]

Я вообще не понимаю как в принципе этот код может правильно работать…

Вот это ключевой момент

Если из таблицы phpbb_sessions удалять по одному строки с юзерами, то они тут же встают куда-нибудь в середину списка и сортируются нормально. Соответственно, если удалить все записи, то сортировка всех юзеров будет работает корректно.

Насколько я помню, последнее посещение зависит от наличия открытой сессии, и хранится в сессионной таблице пока пользователь не выйдет и тогда уже оно копируется в таблицу пользователей. А memberlist просто берёт только таблицу пользователей и получает список их идентификаторов на нужной странице, сортируя по последнему визиту из этой таблицы (без учёта сессий). https://github.com/phpbb/phpbb/blob/442 ... .php#L1605

Код: Выделить всё

SELECT u.user_id FROM users u WHERE u.user_type IN (0, 3, 1) ORDER BY u.user_lastvisit DESC 

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

[rxu]

Если крон очистки сессий включён и работает (function session_gc()), то поле user_lastvisit регулярно обновляется и находится в актуальном состоянии (равном наибольшему session_time).

Отправлено спустя 2 минуты 44 секунды:
Но вопрос даже не в этом, а в том, что даже этот один запрос некорректно выбирает из таблицы пользователей.

Отправлено спустя 3 минуты 30 секунд:
Есть подозрение, что ORDER BY в сочетании с LIMIT шалит на разных серверах по-разному. В каких-то вариантах сначала сортирует все найденные записи, затем отрезает LIMIT, а в каких-то наоборот.

[rxu]

dimassamid, попробуйте в memberlist.php в запросе

Код: Выделить всё

		// Get us some users :D
		$sql = "SELECT u.user_id
			FROM " . USERS_TABLE . " u
				$sql_from
			WHERE " . $db->sql_in_set('u.user_type', $user_types) . "
				$sql_where
			ORDER BY $order_by";

в конце добавить поле сортировки user_id, т.е.

Код: Выделить всё

		// Get us some users :D
		$sql = "SELECT u.user_id
			FROM " . USERS_TABLE . " u
				$sql_from
			WHERE " . $db->sql_in_set('u.user_type', $user_types) . "
				$sql_where
			ORDER BY $order_by, user_id";

[dimassamid]

СУБД какая?

MySQL(i) 5.7.21

Если крон очистки сессий включён и работает

Задача cron.task.core.tidy_sessions запускается раз в 10 минут.

в конце добавить поле сортировки user_id

Ничего не поменялось в сортировке

[im0]

Если крон очистки сессий включён и работает (function session_gc()), то поле user_lastvisit регулярно обновляется и находится в актуальном состоянии

Действительно, совсем забыл про cron. Тогда стоит проверить что он действительно запускается и отрабатывает, ведь тогда не должно влиять удаление сессионных записей. А на счёт регулярно…

Задача cron.task.core.tidy_sessions запускается раз в 10 минут.

Запускаться то она может и запускается, но отрабатывает не чаще чем раз в час — значение параметра
config[session_gc''] = 3600 (по крайней мере у меня так), то есть «выпадать из сортировки» могут пользователи, залогинившиеся не более часа назад.

[dimassamid]

Параметры такие:
session_length: 86400
session_gc: 3600

Отправлено спустя 14 минут 21 секунду:
Установил длительность сессии сейчас на 3600
Теперь "выпадают из сортировки" только те юзеры, которые посетили конференцию в течение последнего часа.

Отправлено спустя 5 минут 57 секунд:

Страница 1 

1.png

Страница 2 

2.png

Страница 3 

3-я страница уже нормальная

3.png

[im0]

Установил длительность сессии сейчас на 3600

Я посомневался, но оказывается session_length тоже влияет на session_gc() — похоже он не рассматривает «короткие сесии»

Код: Выделить всё

WHERE session_time < ' . ($this->time_now - (int) $config['session_length'])

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

[rxu]

Дело только в том, почему выборка и сортировка происходят постранично, а не в целом. Gараметры сессии и очистки на это не влияют, только SQL.

[rxu]

dimassamid, а SQL explain что сообщает по этой выборке? Сортировка файлов задейстована?

[im0]

почему выборка и сортировка происходят постранично, а не в целом

возможно я не понял вопрос, но выше я пытался разобрать как так получается: выбирается страница из таблицы, отсортированной по одному параметру (не совсем актуальному), а потом эта страница сортируется уже по другому параметру (более свежему значению последнего визита). PS. Там ссылки на код добавлены.

[rxu]

im0, в этом случае багаж появлялся бы у всех и постоянно. Такого нет.