integrating members from another database into IPB--IMPORTING them - not a duplicate question, a different one

[raincat]

(I posted this topic just a while ago, but it since seems to have been deleted?  I didn't get any messages about why, and I can't imagine it's any sort of violation of any Terms of Service.  Maybe because the beginning of my question/preamble looked much like another one I posted at the same time, someone thought it was a duplicate?  If there's a problem, if someone could let me know directly, that'd be great, thanks?)

...

I currently have a site that has evolved into quite the mess.  It has about 85,000 members, but most of their details exist in two databases* other than IPB (but not other forum software listed on the migration page) . . . but the site ALSO features an IPB with some duplication/overlap.  

And was wondering how I could/should move forward with all that in the future less confusingly, probably continue in some fashion with the newest version of IPB, but also hopefully get everyone under one member database "umbrella," and then wondering . . . could I actually just get IPB to do everything I need to do here?

It would really be awesome if I could.

And I'm imagining it's probably possible that I could IN THEORY, but I have no idea what would be required to get from here to there.  And I'm imagining it might be difficult.  And I'm hoping for some large hints.

I'd have to do 2 main things, the first being get the non-duplicated members that aren't already in my IPB, IN there.  (I really couldn't manually enter them all into the ACP.  I would lose the will to live before I finished. And I'd really like a way to do it myself, not just hire someone.)  

I also understand there's some sort of invitation thing you can send, but in this situation it would be better if the information could just be imported in such a manner that they'd have a login with their profile with fields already filled in and they could just be emailed it was there.

So just, some sort of more automated way to import them?  Is that possible? 

Or just really, any suggestion anyone has about this.  Importing members from another database, flexible format.  I'm really hoping there's some sort of way. 

(I split the second thing into another thread per my understanding of forum rules.)

*Left out most details here, imagining not relevant.  If some actually were I'm happy to provide.

 

 

[TSP]

It's certainly possible, but you need to have the knowledge on how to write a script that gets you there. And you need to set up things like profile fields that corresponds to information you wish to import to the user profiles from your other databases. Unless you're already a competent developer, you would have to get someone with the knowledge on how to do it.

Some of the tasks needed in such a process could be: 

• Query for members in an external database and gradually set it up in such a way that it goes through all members in that member table
• For each member: Check if a member exists in IPS that share the same email address. If it exists you retrieve that \IPS\Member object for further actions. If it doesn't exist you create a new member with the information from the external database, before you continue to use the recently created Member-object for later actions. You would have to catch possible exceptions like the display name already being in use by another member. 
• For each member: Process any information you retrieve from the original tables you wish to transfer and save that to the corresponding profile field you've set up in IPS 4 for that member. If that profile field doesn't already contain information the member have added on the IPS 4 installation.
• For each member: During the step where you may have created a new member object, you could set a variable $created = true; for example. At the end of the process for each member, if everything completed successfully, you could then check if that variable is set to true and have PHP code that sends an email with necessary information. 

You would have to look at classes like \IPS\Member (system/Member/Member.php) and \IPS\Db (system/Db/Db.php) in order to find methods that would help you or another developer to achieve the goal. 

It's not something it's easy to give a step by step guide on. It will wary greatly based on what information you actually want to transfer, how you expect it to work and how the information is currently stored. 

[raincat]

Thank you for your reply!  I really appreciate it!

And . . . everything you've said makes sense to me.  I just need to figure out precisely how to do it.  And I understand that no one is going to give me a step by step guide, but  . . . I've been doing a lot of searches on this site and not finding a lot.  But I can't even tell at this point if that's because the information simply is not here at all, or I'm just too inexperienced and lack the knowledge to even choose the correct search terms.  

Such as, you said: "You would have to look at classes like \IPS\Member (system/Member/Member.php) and \IPS\Db (system/Db/Db.php) in order to find methods that would help you or another developer to achieve the goal."  How do I even go about doing that?  Is there an area on this site with instructions I should be reading?  On THAT, I mean.

Or a book I should read?  Another website?

A secret decoder ring?  (I know it's not that simple, I'm being facetious, but it does seem a bit like that at the moment.)

Or another related question, one of my (non-forum, non-IPB) databases containing my members' info is Filemaker Pro.  IN THEORY at least, I could do a live connection from that database to the online database set up for IPB, and transfer the info in there that way.  But in order to avoid making a profound mess of that, I'd obviously need to know exactly which fields needed to be filled in and with what.  Would I best determine that just by adding a member some "regular" way, observing the changes in the database, then recreating those by creating new records in that database and adding those fields?  

Or is there an official list of sorts someplace (for the default/required fields, anyway)?  Or would I get that from looking at the classes \IPS\Member and/or \IPS\Db?

Or even speaking even more generally, if not to answer just that one question, is there a book or another website or a hidden area on this website I should read just in general, before attempting anything outside-the-box with IPB?  I know I could try to google or amazon that, but I'd rather a bona fide recommendation from someone who knows their stuff.

Would appreciate any additional replies, thanks!

[Marcher Technologies]

YMMV, but I've always found actually reading the code(yes, all of it) with an understanding of PHP and/or the PHP manual ready to provide a strong basis for modding it. I find this to be true of any framework. As I said, your mileage may vary though - some just don't have the time for such.

[raincat]

OK.  Thanks!

Anything else you'd recommend?  A helpful area on this site I never managed to locate?  (that seems entirely possible)

A great book for folks looking to do extra stuff in IPB?  Or are books even too old-fashioned / too almost-instantly-out-of-date for this?

Thanks!

[Marcher Technologies]

There are these: https://community.invisionpower.com/4docs/advanced-usage/development/

[raincat]

Thanks!  Curiously . . . still don't see anything in there about adding members (from another database), but there is a lot in there for me to read, perhaps the topic descriptions don't fully reflect the scope.

Maybe I can actually add the members the Filemaker Pro way.  Feeling more than a little trepidation about trying that without instructions or guidance of any sort, but I guess no one can really tell me it will or will not work, only that I have to try it and see?

 . . . Unless someone wants to tell me it absolutely will NOT work?  That seems like that might be possible.  Because someone else already tried that and something horribly heinous happened next?  I guess that's a possibility . . . so if anyone wants to warn me about something of that nature, I'm definitely interested.  

[craigf136]

You appear to be looking for a conversion system which isn't available, if you need one the best information is to hire someone or do it yourself.

A starting point would to look at how members are created in V4 and then look at the conversion tool for 3.4 and if you have an understanding of how things work, create a script for the conversion. Obviously doing this on a non production environment.

[raincat]

Thanks for your reply!

I will do that.  If I could ask one more question, after I upgrade to the latest version, will this process involve adding records to just one table, one new record per new member?  And then if I manage to do that correctly, that would have a reasonable shot at actually working?

Or are there actually other things involved in adding a member that an inexperienced person such as myself might not notice right away, even if she was examining the database before and after the addition?  I'm going to look at the stuff I've been told to look at first, but I'm just wondering if there are any obvious pitfalls here, if someone wanted to give me a heads up.  

[craigf136]

You need to look at the members table from what you are importing from, you need to then ascertain what would be the relevant table within IPS. Then the questions of whether or not private messages are to be imported, post count, topics, etc.

If's it purely member data and nothing else associated to it, you will probably find everything you need will be under the core_members table.

Only thing I can suggest, is give it a try on a non production environment once you have a script put together and on a non production environment test it.

[raincat]

Thanks again for your reply.  I think I kinda sorta have a game plan now, at least some stuff to try, hope it works.  

So thanks to the 3 of you that helped me out with that!

But if anyone else is reading and wants to offer additional tips, I did subscribe to the thread, so I'll definitely keep reading if anyone else has a comment.