Adding user "information"

I am working on a system where I need some "accounting fields" for users. Some will be user-supplied (billing information, for example), some will be administrator supplied (access controll to non-elgg features) and some will be statistics from a program processing a log file (data transfer, for example).

I am new to making elgg do what I want (that is, I have used it for a site but this is my first time considering modifications). Lots of design and programming experience (but not a lot in PHP).

I looked at the profile manager module but am (mostly) concerned with performance issues as information is stored in metadata/metastrings. I see three possible approachs:

  1. Use the profile_manager approach and/or module
  2. Extend the users_entity table to include my fields (the other systems will need the login info anyway)
  3. Create a new table and module to work with it

My "guess" is that #3 would be the best approach but would appreciate some input from anyone with more elgg experience. Thanks.

  • What kind of performance issues are you expecting from using metadata?  Without knowing any specifics I would say there shouldn't be any issues.

     

    In terms of what you have listed there as options I would rank them as

    #1. Use profile manager and/or a custom plugin (very much the recommended approach)

    #2. Create a new table (though be warned now that you won't be able to use any of the elgg api to do anything with it and the data there won't be subject to the elgg access model): I see this only as a benefit to someone who hasn't learned the elgg data model and is hacking, in the long term this probably will backfire.

    #3. Extend the users_entity table: no, don't even attempt it

  • The performance issue concern is for what I called "statistical data". The elgg instance is not the primary load on the site -- it is email traffic. There is the potential for a lot of updates to this information. While the fields that will be changed by the user and the admin would benefit from the elgg access model, this data would be updated externally and be read-only for elgg use or possibly not even used.

    Your comments make me think that I may be better off breaking this into two different things. Handling the "close to static" information with the profile manager and putting the stuff that could be changing rapidly into a new table.

Beginning Developers

Beginning Developers

This space is for newcomers, who wish to build a new plugin or to customize an existing one to their liking