Fixed Post-Migration User Issues

[Curt LeCaptain]

I've migrated over from vB 3.8 to XF 2.0.1. After having done so, everytime I attempt to login as my admin account (the one that got migrated over), I get the following:

ErrorException: [E_WARNING] Creating default object from empty value in src/XF/Admin/Controller/Login.php at line 118

1. XF::handlePhpError() in src/XF/Admin/Controller/Login.php at line 118
2. XF\Admin\Controller\Login->completeLogin() in src/XF/Admin/Controller/Login.php at line 98
3. XF\Admin\Controller\Login->actionTwoStep() in src/XF/Mvc/Dispatcher.php at line 249
4. XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 89
5. XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 41
6. XF\Mvc\Dispatcher->run() in src/XF/App.php at line 1880
7. XF\App->run() in src/XF.php at line 328
8. XF::runApp() in admin.php at line 13

 

[Mike]

It looks like your user is an admin via a flag, but you don't actually have an admin record that gives permissions, etc. I'll move this to bugs for analysis.

Did you retain IDs? Do you still have access to the original admin user that did the import? (Can they access the control panel specifically?)

 

[Curt LeCaptain]

I did not retain IDs on this migration. I'm planning on doing another test migration (it took roughly 20 hours last time, big forums) and can do it then. I do have access to the original admin user that did the import (was a new admin user I created specifically for the new XenForo setup.) . They can access the control panel still. I'm probably a few days out from a new migration as I work out the kinks of what happened (there are more fun things that will get reported shortly.)

Admittedly, my fear in doing the ID retain was that it'd overwrite the new "admin" user I created when I did my install. If that's an unfounded fear, excellent.

 

[Mike]

If you can still login with the original admin, I think you can workaround this by removing the "bad" admin and then re-adding them. That should allow you to avoid the issue until this is properly fixed.

Admittedly, my fear in doing the ID retain was that it'd overwrite the new "admin" user I created when I did my install. If that's an unfounded fear, excellent.

If you have a user with ID 1 in the source, the "new" user will be partially overwritten -- we do keep the new email and password to prevent potential issues. (If you go down this route, you will generally want to use a unique email that isn't in the source database to prevent unexpected email changes.)

 

[Curt LeCaptain]

If you can still login with the original admin, I think you can workaround this by removing the "bad" admin and then re-adding them. That should allow you to avoid the issue until this is properly fixed.


If you have a user with ID 1 in the source, the "new" user will be partially overwritten -- we do keep the new email and password to prevent potential issues. (If you go down this route, you will generally want to use a unique email that isn't in the source database to prevent unexpected email changes.)

If I remove and re-add the "bad admin" - will that user's post history get nuked then as well? What happens there?

 

[Bryan]

If I remove and re-add the "bad admin" - will that user's post history get nuked then as well? What happens there?

Add the new admin then merge the old one into the new one.

 

[Curt LeCaptain]

Thanks - I'll attempt that, appreciate it!

 

[Mike]

Actually, the user won't have an admin record, so they might not even show up in the admin list. You can likely just add them there and that should sort the issue.

 

[Mike]

This is fixed for 2.0.2. It was generally an import bug, though the fix should prevent this error regardless.

 

[Joel Fernandez]

I have the same insue and i cant resolve
@Mike

 

[Ozzy47]

I have the same insue and i cant resolve
@Mike

So you migrated from vB 3.8 to XF 2.0.1?

 

[Sean Engle]

We just migrated from vB4.2.5 to xF2.1.6 - and appear to have the same issue. How was this resolved?