Solved Cases
Feed it sugar or give it a good spanking? Grin

Thanks to you and Fern for the help and suggestions. I'm going to upgrade my live site tomorrow night. I may replace my dev site with a copy of the live site and do another test upgrade first (although, probably not. LOL).

This is a perfect example of why webmasters should keep a development site (and why PFs licensing allows you to do so) and always do updates/upgrades/additions to IT before moving on to the live site.
April 24, 2014 6:26 pm
Originally posted by: Sith

Have you tried admincp/maintain/counter/ there are many choices there, I don't know it that will fix it but just thought I would suggest, it's in admin cp tools, it updates a lot of stuff maybe the cache won't

Thanks for the idea. I just wrote a query that will serve as a temporary fix until they add it to the control panel on the back end. I added it to my first post so people can find it later.
March 30, 2014 11:54 pm
I solved it, as a note for future searches:

The phpfox_user_field is queried for the admincp and the membership list. You must update this table, the values are generated on the fly, so there is no need to worry about just leaving those blank. The reason it wasn't working for me, is due to the auto increment reset I have in my query. I went back and removed that, since this table does not auto-increment, and did a transfer for Oxwall. All 4 tables can be treated in the same manner.

As an example.

INSERT INTO phpfox_user_field(phpfox_user_field.user_id)
FROM ow_base_user
March 29, 2014 10:28 pm
-Yeah, the situation is as follows.
-We have Oxwall.
-We want to migrate to PHPFox.
-The passwords and encryption type is not compatible.
-So we are going to rely on the reset password feature.
-I used navicat to do an insert copying the password hashes to the PHPFox password field.
-I cheated the salts by copying the first three characters from the password hashes.

Note, for anyone interested. Make sure you do a:
delete from phpfox_user;
alter table phpfox_user auto_increment 0;

In the header of your SQL file.

Turns out when you use the password reset tool, it actually generates a new hash anyways.

As an extra, I set the last login IP to, so after 30 days, I can see which users have not logged in and perform a cleanup query to knock out the incompatible passwords and hashes.
March 29, 2014 8:34 pm
Originally posted by: yourwebspace

hmmm, 17 days and no answer, I have the same error, any one even looking at this??

This is a user to user forum and answers come with volunteers and sometimes with staff if we have time during our shift. The support desk is found here, should you need faster answers.

For this issue, if upgrading within a version such as v3.7.5 build 2 to v3.7.5 build 3, you don't run the upgrade routine, you just load the files and delete the install folder. (the exception to this is if upgrading from beta to rc as these are a little different and then from rc to stable).

For other issues, you need to post what problems you are having and what version you are upgrading from and to.
March 27, 2014 11:19 pm