Manually applying user upgrade fails if upgrade would extend current upgrade

shawn

Well-known member
If a user doesn't currently have that upgrade... no problem. Enter their username and it applies as it should. If manually upgrading them would extend their current upgrade, I get this error:

unserialize() [function.unserialize]: Error at offset 0 of 5 bytes
  1. XenForo_Application::handlePhpError()
  2. unserialize() in XenForo/Model/UserUpgrade.php at line 407
  3. XenForo_Model_UserUpgrade->upgradeUser() in XenForo/ControllerAdmin/UserUpgrade.php at line 253
  4. XenForo_ControllerAdmin_UserUpgrade->actionManual() in XenForo/FrontController.php at line 310
  5. XenForo_FrontController->dispatch() in XenForo/FrontController.php at line 132
  6. XenForo_FrontController->run() in /websites/nc4x4/forum/admin.php at line 13
Additionally, as more of a feature request than an actual bug, there's no place in the ACP to manually edit a user's upgrade settings. You can use the "active upgrades" pane to see when an upgrade is supposed to expire, but because it's not searchable, it's basically useless if you have more than a few dozen active subscriptions.
 
I am unable to reproduce this error.

This looks like it might be due to corrupt data in xf_user_upgrade_active.extra. Can you post the results of this query?

Code:
SELECT CONVERT(uua.extra USING utf8)
FROM xf_user_upgrade_active AS uua;

Or give me access to phpmyadmin and I can have a look for myself.
 
I am unable to reproduce this error.

This looks like it might be due to corrupt data in xf_user_upgrade_active.extra. Can you post the results of this query?

Code:
SELECT CONVERT(uua.extra USING utf8)
FROM xf_user_upgrade_active AS uua;

Or give me access to phpmyadmin and I can have a look for myself.


The vast majority just say "Array"... which I'm assuming are the ones we imported from vB. The bottom several rows are more like "a:4:{s:11:"cost_amount";s:4:", etc.
 
The vast majority just say "Array"... which I'm assuming are the ones we imported from vB.

"Array" is not valid. That explains the error.

The vB importer doesn't do paid subs. Did you use this addon?

http://xenforo.com/community/threads/vbulletin-4-subscription-importer.19169/

I just reviewed the code for that addon and found the problem:

Rich (BB code):
			$this->_db->insert(
				'xf_user_upgrade_active',
				array(
					'user_id' => $userIdMap[$log['userid']],
					'user_upgrade_id' => $newId,
					'start_date' => $log['regdate'],
					'extra' => 'Array',
					'end_date' => $log['expirydate'],
				)
			);

Try running this query to fix your data:

Code:
UPDATE xf_user_upgrade_active
SET extra = 'a:0:{}'
WHERE extra = 'Array';

Let me know if that fixes the error.
 
Jake, I owe you a beer. The db fields are now fixed, upgrades from the ACP work properly, and we should probably link your script to the importers with the bad queries.

*However*, my bug should now be revised somewhat:

Let's say we've got a user that has an active upgrade, set to expire next March (03/15/2013 for the sake of discussion). Now, I don't know *when* their upgrade expires, because it doesn't show in the admincp. It theoretically shows under the "List Active Upgrades" link in the ACP, but because that list isn't searchable, and I have several hundred entries in it, for all intents and purposes, the list is useless... and the upgrade info isn't exposed in the edit user page.

SO... our user mentioned above won a prize and gets a free year subscription. I select "Manually Upgrade User" from the Upgrades pane, type in the username, and down at the bottom, it says that the upgrade ends on 2013-05-28, which is a year from today. Problem is, if I hit okay, rather than adding a year to the current upgrade, it explicitly sets the upgrade to expire on 5-28-13, or only about two and a half months after it was scheduled to end in the first place.

Either way, I'm still better off changing the expiration date directly within the database, as I can quickly search by user_id and directly modify the expiration date.

As far as bugs go, it probably doesn't fall under 'unintended behavior', but that doesn't mean it works well the way it's currently designed.

Thanks again for the help.
 
Top Bottom