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.
The failed error could be causing for something in the server deleting the session.
You will need to contact your hosting company and tell to them about this issue, if the issue persist I strong recommend you to move your site to a recommeded hosting companies: * http://www.phpfox.com/hosting
I did so:
Is replaced all the files with a new version of the archive, but the file: include/setting/server.sett.php
Then launched installs and finished updating.
Everything is working fine. But whether I'm doing?
I'm sorry that I ask again ... Just not all words can be translated into Russian tongue.
You can put it in both Russian and English so that if someone that speaks Russian is on the forum they can answer in both Russian and English if that would help. We do just have to have an English translation of any other language.
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.
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) SELECT ow_base_user.id FROM ow_base_user
-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 0.0.0.0, 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.
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, http://www.phpfox.com/helpdesk/ 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.
I'm happy to say that we can mark this as "Solved". When I downloaded the files to my laptop, something looked different, so I upgraded again and it worked when I went to the install page. Cannot answer why, but I am up and running on 3.7.5 build 3! Thanks again for your help and support.
