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

Сообщение **Sheer** » 17.05.2019 23:03

Черт его знает

Pazh · Сообщение **Pazh** » 17.05.2019 23:10

rxu,

INSERT INTO phpbb_config (config_name, config_value) VALUES ('board_dst', '0');

это из схемы phpbb 3.0 значение тянется, а в 3.1 и далее оно уже нигде не используется

Сообщение **rxu** » 17.05.2019 23:12

Pazh, это понятно. Я про конвертацию говорю. Получается, что при миграции оно не удаляется нигде, а новое не создается.

Сообщение **Sheer** » 17.05.2019 23:16

Создаётся.

Сообщение **rxu** » 17.05.2019 23:17

Ну тогда всё хорошо.

Pazh · Сообщение **Pazh** » 17.05.2019 23:17

rxu, после конвертации 3.0 на 3.1 оно используется в одном UPDATE запросе в миграции phpbb\db\migration\data\v310\timezone.php и все, больше в движке это значение нигде в коде не используется ни в 3.1 ни в 3.2, т.е. оно должно было быть удалено еще в v310

Сообщение **rxu** » 18.05.2019 6:38

Видимо, board_timezone не создается, оно всегда было

Так тогда значит и user_dst в таблице юзеров тоже остается после конвертации и больше не используется?

Pazh · Сообщение **Pazh** » 18.05.2019 11:25

rxu писал(а): ↑18.05.2019 6:38 Так тогда значит и user_dst в таблице юзеров тоже остается после конвертации и больше не используется?

оно используется в миграции \phpbb\db\migration\data\v310\timezone.php и потом удаляется в миграции phpbb/db/migration/data/v310/timezone_p2.php (больше в этой миграции ничего не делается)

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

'drop_columns'	=> array(
				$this->table_prefix . 'users'			=> array(
					'user_dst',
				),
			),

Вот сюда будет правильнее добавить и дроп board_dst

Сообщение **Sheer** » 18.05.2019 11:50

rxu писал(а): ↑18.05.2019 6:38 Видимо, board_timezone не создается, оно всегда было

Время-то бежит, уже и забывать все стали. Точно было, это часовой пояс, а board_dst - это признак летнего/зимнего времени.

rxu писал(а): ↑18.05.2019 6:38 user_dst в таблице юзеров тоже остается

Нет, не остается.
phpbb\db\migration\data\v310\timezone_p2.php

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

	public function update_schema()
	{
		return array(
			'drop_columns'	=> array(
				$this->table_prefix . 'users'			=> array(
					'user_dst',
				),
			),
		);
	}

Сообщение **rxu** » 18.05.2019 13:30

https://github.com/phpbb/phpbb/pull/5595/files

Pazh · Сообщение **Pazh** » 08.06.2019 15:38

rxu, прошло 1,5 года с момента Re: Сообщаем об ошибках phpBB 3.2.x разработчикам - планируется что-то меняться? 3.2.7 - косяк повторяется

Сообщение **rxu** » 08.06.2019 15:50

Pazh писал(а): ↑08.06.2019 15:38 планируется что-то меняться?

Не могу сказать про разработчиков. Лично мне не кажется, что это "косяк".

Pazh · Сообщение **Pazh** » 08.06.2019 15:55

rxu, а они в курсе данной "проблемы"? Т.е. ну если с внутренними уведомлениями еще можно через одно место справиться - подложив язык при просмотре, что в принципе правильно, но вот email уведомления отправляются сразу в момент формирования уведомлени и ТОЛЬКО на англицком языке - а в идеале должны отправляться на языке получателя уведомления...

Сообщение **rxu** » 08.06.2019 15:59

Какие уведомления?

Pazh · Сообщение **Pazh** » 08.06.2019 16:07

rxu, форумная система уведомлений. Проблема с формированием уведомлений из cron заданий из-за того что в кроне подгружается только английский язык.
Костыльное решение:
использовать в функциях обработчика задания в расширениях конструкции типа такой:

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

$this->language->set_default_language($this->config['default_lang'], true);
$this->language->add_lang('topic_actions','rxu/TopicActions');

первая строка выставляет языком по-умолчанию язык конференции (это 99-100% юзеров конференции), с перезагрузкой файлов локализации данного языка, а вторая строка догружает файл локализации расширения (т.к. они ТОЖЕ по умолчанию не грузятся в cron, т.к. для cron заданий не вызывается нигде user_setup, куда по гайду через listner и событие core.user_setup все вставляют локализацию расширения)