Is MODx "user" the recommended approach for all login-based sites?

Maybe try extended.weight ?

Im just guessing...

Maybe try extended.weight ?

Nope. Good guess, but that didn’t work.

I’m wondering if I’m going to have to do some sort of join operation maybe?

You can’t query it like that. Here are some examples of how you can query it.

function_that_converts_my_external_table_row_into_a_php_array();

You can’t query it like that. Here are some examples of how you can query it.

if you have your data on the external table, why not just reverse engineer it’s schema into xpdo, and then continue to use it.
pros: search-ability, performance, no-sync (in case the external table is still in use)
cons: you’ll have to create you own interface to manage it

IMHO, this "extended profile" should only be used for smaller setups or simpler stuff. storing commonly used data as json format in-side an sql column isn’t the best approach. (it’s user data, not some components configuration.. query-ability is (can be) a must)
although ’modUser’ is first common-use, extending many other xpdo objects in revolution could gain more use soon as the ’pros’ are many and the ’cons’ seems only the manager UI. a generic solution would pop up...
But I guess that most large/custom installation anyway don’t depend on /manager for administration.

If you have your data on the external table, why not just reverse engineer it’s schema into xpdo, and then continue to use it.

I actually did do that. I already had it in xpdo and was querying it... but some of the fields in the modUserProfile (name, gender, phone, dob, etc.) I didn’t initially put in the external table, because I thought it was bad form to have it in both places. So I was looking to do a join of the modUserProfile table and my external table to be able to query all the pertinent fields.

Having the external data in the ’extended’ field of modUserProfile wasn’t sufficient for my needs - I need to do some greater/less-than comparisons, and didn’t want to get in to php filtering.

I suppose I could have pursued doing a join between the modx user profile table and my external profile table - the external table has an ’account_id’ field that matches the modx user id.

Instead I ended up pulling most of the data I needed from the modx user profile into the external table (adding the fields), and redid the schema. I’m relying less on the modx user profile as a repository of searchable data; just collecting a minimal amount of information when the user registers (name, email, password, and birthdate to meet age requirement). After they register they can log on and create a profile (populating my external table).