In reading this again (going through my older postings) part of the issue is _where_ the profile data is connected.

In most cases GL3/Links is the core program on a site. It's where most of the content lays and where most of the features are added/pulled through.

GForum is the main program on a forum site, but it's not designed as a database, so maintaining profile data is not as easy from within it. For example, it would be easier to make GL3 a "forum" than to make GForum into a CMS.

Commnity is shell, not a real application (at this point) and works very, very differently from the other programs.

So, when looking at the 3 major parts to a site, we are back to GL3 as the core program, with Community trying to tie the parts together.

If you use Community's program for the "real" user data, such as actual contact information, and such, you can use that data to verify the data entered into the GL3 and GF programs. Such as age, and location, and prevent problems with misrepresentation. How you manage your Community data becomes the key issue. you can even allow "private" or cloaked profiles in GL3 and GF, and have them be different.

The profile system as described here, and as implemented, is tied directly to the GL3 code.

As stated, Community is a shell, not an application (content area).

So, the purpose of the profile system is to provide as much information about the content in the GL3 database (and even in the GF area) as possible. The data tables are tied to the Users table (for settings and configurations). The stats and other features are tied to the Links, Ratings, etc tables for their data. Most of the information in the profile system is pulled from the GL3 user base and their content links within that system.

So, for this type of profile system, pulling it through Community doesn't make much sense. It's really based around, and relies on the Links data.

That said, having a Community Profile system for "real" data, or data that is shared across multiple applications would be a good thing. Providing access to the application-specific profiles -- and UPDATING them -- would also be a good thing.

But, if you want to try to secure sensitive data, making the Community system a minor part of the data exchange (eg: sessions and authentication only) with limited user data ever accessed or transferred, adds security.

It would be easier to write an accessor routine to display profile data from one of the other application pages than to integrate data from these applications under Community (as well as more secure). To edit/change this data, logging on to the application is always a better choice.

I don't see how, or why, data that is specific to one application should reside in Community. And, I've thought about this a lot, really. In many ways, the authentication features of Community should have been integrated into GLinks, or, the core-code features from GLinks should have been integrated into Community. GL3 and Community are more closely tied than any of the other programs. Allowing GL3-Community to access GForum, GMail, etc would make more sense than the current topology.

No matter how you try to view it, Forum, Mail, Lists, etc are all add-ons to the CMS/Database/Authentication system. In some ways, the whole code base could be streamlined if the logic was changed a little to reflect this.

Anyway, just a rethink of this issue.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.