Hi All,
I used Akeeba Admin tools to change the super admin away from user id 42... this is a common security measure that I take on all my sites.
I didn't realise that this would cause Virtuemart to change the Vendor user. Now I can't make any changes to the Vendor information because I always get a warning saying:
JUser: :_load: Unable to load user with ID: 42
I still have super admin access, but now I can't apply this to the vendor information because it wants user id 42.
What can do to get around this?
Thank you,
Ray.
Hi igolfniray,
Have you tried updated the field value directly in the DB? As a rule of thumb, if you plan on doing something like this again, you should firstly backup your database so you can revert back in case of problems like this.
Maybe check "#__virtuemart_userinfos". I've never used the Akeeba Admin Tools so this is only a suggestion.
I hope this helps.
Thank you!
I got into phpMyadmin and deleted the user id 42 for table "#_virtuemart_vmusers"
Then I was able to fill in the Vender form for my new admin user... Phew!
Thank you for your help!
Hi igolfniray,
I glad you got this working. Lets mark this topic [SOLVED].
This is something that has to be solved in a proper way.
I have just done a fresh install of VM2.0.12 and the problem is still there.
Hello,
But you cause the issue using admin tools. There isn't other proper way, the same will happen to any components using users id! Like K2 and the rest, you change user ID, how the other components knows about that? Only is Admin Tools update them.
So, the suggested solution is the best and the only way if you change super admin id!
Hope to understand.
Regards
I had the same issue!!
When setting up VM in the first instance I would create another superuser account and fill in the vendor details with that account.
Then when you use Akeeba ADMIN tools you can safely remove the default superuser without it having an effect on your vendor details. (With mine it replaced the email address etc)
As you're running eCommerce I would recommend getting Pro, locking your /admin area with a key and then you don't need to mess around with removing the default superuser. You'll also have a nice firewall stopping attempts to access places where people really shouldn't go.
If it happens again, instead of using phpmyadmin- go to (in Admin Tools Pro) web application firewall, Configure WAF, 'Disable editing backend users' properties' - Set to no. You can now delete the new user Admin tools has created and re-activate your old account (just rename the email etc).