I have members in 4.1.5 and have installed 4.2.1 and want to move the members there. how is that done?
Also my old members might have short passwords... less than 6 characters required by 4.2.1 Is that going to be a problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-08-01
If you are using the same database (and there's normally no reason why you shouldn't be for an upgrade), then there's nothing to move.
If you have created a completely new database, then you can only do that from your server's 'back-end' using something like 'phpMyAdmin'. Export the pgv_users table from the old database, and import it into the new, manually.
There is a long list of other tables you might need to move like this as well - which is why creating a new database is a bad idea. Think about blocks, favorites, place_locations, news, and any that are related to modules like googlemaps (place_locations), research assistant, etc.
The short passwords shouldn't be a problem, as this check only happens when a password is created or changed - but you should get your users to change any that are that short anyone. Its just good practice if you want to minimise the hacking risk.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm one of your lot - I do full/from scratch rebuilds. It only takes half an hour or so. I only use GoogleMap, whose data I import from an external table.
Before I do that, I copy the current user table to a safe place, usually with a different name.
After I do my rebuild (and I carefully keep as much the same as I can - GEDCOM names, table prefixes etc) I copy back my user list.
If I need to correct anything (eg, passwords) then that can be done by you as admin before the user gets to try it for him/herself. Don't forget to tell them what you've done!
I've probably broken all the rules in the book, but it works for me.
Paul
Australia
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks kiwi_pgv and paul for your quick and informative response.
I think I like the "don't change the database" idea. The reason I created a new database was because I thought there might be a difference between the 4.1.5 and the 4.2.1
So if they are the same then can I just change the database name in the config file? Then I suppose I would have to re-import the ged files???
Again, thanks quick response... it can only happen with Open Source support.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Reimport will update the DB as some new fields and tables were added.
There are, as KIWI pointed out, more than just USERS to move if you don't wish to loose favorites for every user (very frustrating for them), news, messages, and if you use RA, all those functions as well as the PUNBB if you use it. No hard, but much to do to create a new one that resembles the old one.
stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for all the advice. I just followed the instructions and upgraded and glad I did. BUT I was worried that something might go wrong. But everything is working fine now. I did have to change my password.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With 4.3.0 on the horizon, this now gets interesting.
I still plan to build a new, parallel instance and populate/test it before going live, just as before. But the user table isn't going to transfer - 1 has become 3. I can readily export my current users, but how to get them into the proposed new setup?
Paul
Australia
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-01-31
Paul
When you have created the empty DB for your new install, place a complete copy of all the old tables in it - then do an "upgrade", but on a parallel installation. That way PGV will transform all the old tables to the new ones for you.
If you're not actually creating a new DB, just copy all the old tables, giving them a new pre-fix, and amend config.php accordingly.
To put it another way, do an upgrade (as per the WIKI upgrade instructions), but on a complete replica of your existing setup, rather than over the top of your live data.
Nigel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That rather negates the point of a fresh build. I renew the GEDCOM, renew all the media, add new geolocations…I don't want to cart all the old baggage with me.
Paul
Australia
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As well as splitting the users table, the upgrade scripts do other things (move hitcounter files to a table, move the banned IP list to a table, move the known search engines to a table, move the gedcom list to a table).
We assume people will either (a) have a new/clean install or (b) upgrade an existing system.
Your "hybrid" approach is a little tricky. You could try kiwi's suggestion of creating a duplicate of your currnet system, then upgrading it. Then create a new/empty 4.3.0 system, and copy the data from tables in the upgraded one to the new one.
If you don't like your "old baggage", why not just tidy/clean/prune it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, it was easier than I thought. My 'hybrid' approach can be made to work (we don't think of it as hybrid, we apply the PAUL principle - Protect All User Lists).
The plan is: from the old db, copy xxx_users to the new db, retaining the name exactly.
Now build the new, parallel PGV, using xxx (whatever you used last time) as the table prefix.
Go ahead and install. Your user table will keep user names and passwords, and the time/date of last login. Anything else gets added to the tables as folk use the system.
When finished, you can delete xxx_users (only the plural one! - xxx_user is the new one you must keep).
Paul
Australia
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have members in 4.1.5 and have installed 4.2.1 and want to move the members there. how is that done?
Also my old members might have short passwords... less than 6 characters required by 4.2.1 Is that going to be a problem?
If you are using the same database (and there's normally no reason why you shouldn't be for an upgrade), then there's nothing to move.
If you have created a completely new database, then you can only do that from your server's 'back-end' using something like 'phpMyAdmin'. Export the pgv_users table from the old database, and import it into the new, manually.
There is a long list of other tables you might need to move like this as well - which is why creating a new database is a bad idea. Think about blocks, favorites, place_locations, news, and any that are related to modules like googlemaps (place_locations), research assistant, etc.
The short passwords shouldn't be a problem, as this check only happens when a password is created or changed - but you should get your users to change any that are that short anyone. Its just good practice if you want to minimise the hacking risk.
<<The short passwords shouldn't be a problem, as this check only happens when
a password is created or changed>>
The minimum-length check is applied when the password is entered in a form (i.e. both login or register).
I'm one of your lot - I do full/from scratch rebuilds. It only takes half an hour or so. I only use GoogleMap, whose data I import from an external table.
Before I do that, I copy the current user table to a safe place, usually with a different name.
After I do my rebuild (and I carefully keep as much the same as I can - GEDCOM names, table prefixes etc) I copy back my user list.
If I need to correct anything (eg, passwords) then that can be done by you as admin before the user gets to try it for him/herself. Don't forget to tell them what you've done!
I've probably broken all the rules in the book, but it works for me.
Paul
Australia
Thanks kiwi_pgv and paul for your quick and informative response.
I think I like the "don't change the database" idea. The reason I created a new database was because I thought there might be a difference between the 4.1.5 and the 4.2.1
So if they are the same then can I just change the database name in the config file? Then I suppose I would have to re-import the ged files???
Again, thanks quick response... it can only happen with Open Source support.
Beware. As I recall, there are changes to the database from V4.1.6 to V4.2.1.
Reimport will update the DB as some new fields and tables were added.
There are, as KIWI pointed out, more than just USERS to move if you don't wish to loose favorites for every user (very frustrating for them), news, messages, and if you use RA, all those functions as well as the PUNBB if you use it. No hard, but much to do to create a new one that resembles the old one.
stephen
Thanks for all the advice. I just followed the instructions and upgraded and glad I did. BUT I was worried that something might go wrong. But everything is working fine now. I did have to change my password.
With 4.3.0 on the horizon, this now gets interesting.
I still plan to build a new, parallel instance and populate/test it before going live, just as before. But the user table isn't going to transfer - 1 has become 3. I can readily export my current users, but how to get them into the proposed new setup?
Paul
Australia
Paul
When you have created the empty DB for your new install, place a complete copy of all the old tables in it - then do an "upgrade", but on a parallel installation. That way PGV will transform all the old tables to the new ones for you.
If you're not actually creating a new DB, just copy all the old tables, giving them a new pre-fix, and amend config.php accordingly.
To put it another way, do an upgrade (as per the WIKI upgrade instructions), but on a complete replica of your existing setup, rather than over the top of your live data.
Nigel
That rather negates the point of a fresh build. I renew the GEDCOM, renew all the media, add new geolocations…I don't want to cart all the old baggage with me.
Paul
Australia
As well as splitting the users table, the upgrade scripts do other things (move hitcounter files to a table, move the banned IP list to a table, move the known search engines to a table, move the gedcom list to a table).
We assume people will either (a) have a new/clean install or (b) upgrade an existing system.
Your "hybrid" approach is a little tricky. You could try kiwi's suggestion of creating a duplicate of your currnet system, then upgrading it. Then create a new/empty 4.3.0 system, and copy the data from tables in the upgraded one to the new one.
If you don't like your "old baggage", why not just tidy/clean/prune it.
Looks like typing time…. :-(
Paul
Australia
Ah, it was easier than I thought. My 'hybrid' approach can be made to work (we don't think of it as hybrid, we apply the PAUL principle - Protect All User Lists).
The plan is: from the old db, copy xxx_users to the new db, retaining the name exactly.
Now build the new, parallel PGV, using xxx (whatever you used last time) as the table prefix.
Go ahead and install. Your user table will keep user names and passwords, and the time/date of last login. Anything else gets added to the tables as folk use the system.
When finished, you can delete xxx_users (only the plural one! - xxx_user is the new one you must keep).
Paul
Australia