У меня была такая же проблема. Выскакивала ошибка на крон-задачу статистики. Далее, я рассуждал так:
я проверил ещё раз php-код и таблицы в базе на предмет запятых вместо точек в десятичных представлениях чисел сидбонусов. Оказалось, что у меня всё в порядке.
Все знают, что php очень вольно относится к преобразованиям типов переменных, и по собственному усмотрению может преобразовать один тип в другой.
Сидбонусы, которые у нас прописаны в админке, сериализуются (преобразуются в пригодное для хранения представление) в массив значений типа value, после чего отправляются в базу (переменная seed_bonus_points таблицы bb_config).
Как должно происходить обратное преобразование (десериализация)? Судя по мануалу ( раздел "Возвращаемое значение"), обратное преобразование может быть к одному из пяти (!) типов. По здравой логике, php сам должен был бы преобразовать по умолчанию к типу float...
Далее, я исходил из того, что php мог вольно десериализовать к любому типу по своему усмотрению. К тому же, нельзя забывать, что у всех разные трекеры и разные числа сидбонусов... поэтому я решил воспользоваться явным преобразование к типу float.
В 177-ой строке крон-задачи статистики (файл library/includes/cron/jobs/tr_cleanup_and_dlstat.php) есть строка с десериализацией:
я её заменил на строку с явным преобразованием к типу float:
После чего, ошибка крон-задачи Tracker cleanup and dlstat из логов полностью исчезла и сидбонусы заработали нормально.
P. S. Вся эта ситуация заставила меня вспомнить одну из простых истин:
"Хороший стиль программирования предполагает явное преобразование типов данных".
Предлагаю в следующий билд включить указанную выше поправку.
я проверил ещё раз php-код и таблицы в базе на предмет запятых вместо точек в десятичных представлениях чисел сидбонусов. Оказалось, что у меня всё в порядке.
Все знают, что php очень вольно относится к преобразованиям типов переменных, и по собственному усмотрению может преобразовать один тип в другой.
Сидбонусы, которые у нас прописаны в админке, сериализуются (преобразуются в пригодное для хранения представление) в массив значений типа value, после чего отправляются в базу (переменная seed_bonus_points таблицы bb_config).
Как должно происходить обратное преобразование (десериализация)? Судя по мануалу ( раздел "Возвращаемое значение"), обратное преобразование может быть к одному из пяти (!) типов. По здравой логике, php сам должен был бы преобразовать по умолчанию к типу float...
Далее, я исходил из того, что php мог вольно десериализовать к любому типу по своему усмотрению. К тому же, нельзя забывать, что у всех разные трекеры и разные числа сидбонусов... поэтому я решил воспользоваться явным преобразование к типу float.
В 177-ой строке крон-задачи статистики (файл library/includes/cron/jobs/tr_cleanup_and_dlstat.php) есть строка с десериализацией:
PHP:
$seed_bonus = unserialize($bb_cfg['seed_bonus_points']);
PHP:
$seed_bonus = (float) unserialize($bb_cfg['seed_bonus_points']);P. S. Вся эта ситуация заставила меня вспомнить одну из простых истин:
"Хороший стиль программирования предполагает явное преобразование типов данных".
Предлагаю в следующий билд включить указанную выше поправку.
