Proposed Standard for Handling Front-End Users/Subscribers/Registrants/Visitors

I just released a webinar management extra called Webinex (http://modx.com/extras/package/webinex) and I have been looking at ways to integrate it with other extras to provide email sending, login management and other functionality. I've run into a problem, and I think we need to deal with it in general as a community before it gets worse:

There is no unified standard for handling email subscribers, event registrants, front-end users etc. -- basically, for handling people who come to your website.


In particular, we have some extras that store people such as newsletter subscribers in a custom db table. And then we have other extras that store people in the modx_users table.

The problem with this is that it means these extras can't work together to provide integrated functionality for the same database of people. Or at least, it will make integration very difficult. For example, if I want to use the Subscribe extra to register people as users of my site, but I also want to send them a newsletter using DitsNews, I would have to store two records for each person - one as a user, the other as a DitsNews subscriber. The more such extras I use, the more records I will have to maintain for each person, which will quickly become unmanageable.

So I propose the following standard be adopted universally as a coding standard for Revo:

Users, visitors, registrants and subscribers to the site should always be handled as users, either by using the modUser class or your own custom extension of the modUser class.


This would allow all such extras to interact and be used in combination easily, since they would all be storing people in the modx_users table. That will make it much easier to build a unified system for interacting with your site visitors. [ed. note: esnyder last edited this post 14 years, 3 months ago.]

Sounds good to me.

BTW, a new version of Subscribe is due out soon. It may be a pain to install because of some changes to prevent conflicts with other extras, but it will still put the users in modx_users.

It will work with EmailResource (to send NewsLetters to subscribers) and an upcoming extra called Notify that will email subscribers a link to new pages.as well as sending an update to Twitter and Facebook. As far as I can tell, it will also work with Articles.


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

I'm working on a pretty hefty booking system right now and am wondering if there would be any performance issues if that modx_users table grew to the point where it has 10,000+ users (and eventually a lot more).

Only about 30-40 users would ever have access to the manager, but the others may need to have a username/password to access their booking history and account details. I'm still on the fence as to whether it should go into a separate table or not.

Has anyone used the modx_users table in this way before? Any issues that might pop up? Or is this exactly how this table is intended to be utilised?

The modx_users table is fairly lightweight and well indexed (username is an index) so I think it would be reasonably fast. For the booking history and account details, you'd have to either subclass the User object or put the information in the User Profile.

I think that subclassing the User object would give you much faster performance, but OpenGeek could give you a more definitive answer. Using the User Profile is somewhat slower and more cumbersome to code for, so putting all the info into the table of your custom User object, would probably speed things up a lot and make life easier once you got it set up. As freejung suggests, it would also let you use other extras such as Subscribe, EmailResource, and Notify with your users, which might be worth a small performance hit versus creating a custom User table.




------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

As freejung suggests, it would also let you use other extras such as Subscribe, EmailResource, and Notify with your users

Exactly -- and more importantly for the rest of us, if you release your booking system as an extra we could use it in conjunction with whatever other extras we're using or developing to interact with users.