Would it be possible to tie a SQL db to the members table to mark the profile?

[rcane]

I know you can make custom profile fields that only the admin can see.

When users register I place them in one of two member groups based on whether or not they have a particular piece of data in their profile. 

The problem is, they were supposed to give that little bit of data to another person as well who logs it in a spreadsheet.

So, I have to physically check a second location to see if they gave that bit of data to both places.


Could I start using an SQL for that other list and set things up on BOTH db's such that

1. if a person registers on SMF it checks the other db against their email address;
2. if it finds it over there it fills in a private custom profile field to let me know they did it (saving me a step).

And, on the other side.

1. if my guy enters them in his new SQL db it checks the SMF member table, and
2. if it finds their email it goes to the custom profile table and puts a YES somewhere (something like that)?

This way if they register first in SMF, the act of entering them in the other place will go back and mark their profile for me.

This way if they register 2nd in SMF, the act of registering in SMF will go check the other list, and mark their profile for me.


You could go further and if they register SMF (and their stuff wasn't entered in the other place) SMF could send them a reminder email (on top of the activation one) that they need to go take care of the other thing.

[Arantor]

You could but it'll have to be custom coded for you specifically, no one can give you an easy convenient snippet to do it for you

[rcane]

You could but it'll have to be custom coded for you specifically, no one can give you an easy convenient snippet to do it for you

That's what I suspected--though it might be a fun project to attempt.


I wonder if it could be a straightforward of putting the instructions in the registration button on SMF to make the call to the other db and select the "yes" radio button on the custom profile field's custom_col_ID. 

I'm just dipping my toe into SQL front ends so there has to be some way to run a few lines of code with each person submitted on the 'spreadsheet' side. 

[rcane]

In fact, I'm willing to make it a one-way thing only. 

Just use SMF to grab 3 things from their SMF profile (name, email, piece of info) and toss them in a different DB each time their profile is changed.

Could tie it to the registration button and the change profile button. 

[Kindred]

or use the hooks that already exist to trigger code like this...

[rcane]

or use the hooks that already exist to trigger code like this...

Where can I see a list of all the hooks?

[Kindred]

https://wiki.simplemachines.org/smf/Integration_hooks

but the number of hooks has been drastically increased in 2.1

[rcane]

https://wiki.simplemachines.org/smf/Integration_hooks

but the number of hooks has been drastically increased in 2.1

And these hooks will call THESE functions?

https://wiki.simplemachines.org/smf/$modSettings

[Arantor]

No, a hook is a point in the code where it says 'hey, I'm here, does any plugin want to do anything while I'm here'.

So there's a hook during registration just before the member is actually created to pull in any last-minute extra details, it's called integrate_register and you use a thing called add_integration_function to say 'hey, when you get to the part marked 'integrate_register', here's what I want you to do'.

So you could do that, and that would be able to run a query to check the spreadsheet and populate the custom field if desired. But it's not completely obvious even if you're familiar with SMF's code.

[rcane]

Well, "not completely obvious" is my middle name.

I've been learning all this ground-up, so I'm up for a challenge. 

[rcane]

No, a hook is a point in the code where it says 'hey, I'm here, does any plugin want to do anything while I'm here'.

So there's a hook during registration just before the member is actually created to pull in any last-minute extra details, it's called integrate_register and you use a thing called add_integration_function to say 'hey, when you get to the part marked 'integrate_register', here's what I want you to do'.

So you could do that, and that would be able to run a query to check the spreadsheet and populate the custom field if desired. But it's not completely obvious even if you're familiar with SMF's code.

the problem i have, always have here, is finding WHICH file to examine.  there are numerous index's or templates of the same name.  learning the heirarchy has been the hardest part.