What modules are being used for general user directory, possibly on an opt-in basis. I noticed there is a guestbook which visitors can sign into, but there appears to be no general directory module to give other users the ability to browse who exists on the site so I'm just wondering what others are doing.

The xRoster module kind of comes close but you need to do some rewriting to the code to make it work like that.

I modified it heavily for a football team I was providing the web site for. In the version I created you can have members online and off line in it. Since not all members of the team are on the website it worked well. I added a registration feature that allowed any user on the website to add to the team after they were approved.

Not sure if that is what you meant.

It is a module that is high on my list to rewrite once I get through some other stuff so hopefully this summer I will be tackling that one. Once rewritten it will likely do what you are looking for.

Rodney

#xoobaru

There's a module called xoopsmembers that should do what you want.

I haven't tried this module in a while but it looks like it's been updated sufficiently to run on current versions of XOOPS.

Hey Redheadedrod,
That sounds close, ideally. On and offline status too. Is your version current?.

Thanks zyspec, I will try that xoopsmembers module, however the last message in the thread you linked to raises concerns. I have had my share of drive-by white screen modules.

This is also an appeal to solicit opinion from anyone, as I am spending more brainpower than is good for me trying to determine where the magic red line should exist between user expectations of privacy (and what in the world those even are), and their expectations of what should be reasonably publicly available.

Mamba, you are a marketing guy, so you might understand something about the market psychology as it relates to social site users.

In a public context for a social network, many users want a way to become aware of other users, their interests, their online status, and have the ability to contact users that potentially interest them. If there is no means to research other users, their interests due to the absence of a directory, they feel cut off, lose interest and go elsewhere.

But on the same site there are BYO users that only want to be with those in their own group/distant family and want privacy from public access, but transparent to their own group. They do not care to be listed or contacted, friend requested, or have their online status viewed by unknowns. This is probably a third or less of all users.

Knowing you can't please all of the people all of the time, what is that magic level of public user/status availability that is reasonable across the entire social media site, given existing or prospective XOOPS capabilities?

If we push Smallworld further into Social Networking, then the best way is to let users decide what and how much they want to share with whom.
Ideally, they should be able to create their own groups, and invite their friends there, and decide how much they want to share there.

You could be invited, and you might decide that you will join, but you won't share anything. And the group owner can decide if this is acceptable, i.e. if in order to join the group - do you have to share the minimum what everybody else is sharing, or if it is up to you.

And you could define several "personas" for your profile, that you could share, depending on your needs, so you wouldn't have to do it over and over again.

That would be very much user-driven Social Networking.

I uploaded my hacked version of xRoster to the SVN. It does not have the 2.5 admin that Mamba added to the original since I did the modifications like 2 years ago.

In order to use it you would have to rewrite some of the code to allow your users to enter in their information.

If I recall there was not much verification when it was originally done. I believe it only allowed an admin to make up the records.

I added support for users that were actually on the system to be able to edit and submit their own information and this was used as a sort of "registration" system and required an admin to approve of the entry. Any time the profile was edited it had to be approved before being shown.

The database stuff was very archaic and used one method to write to the database and a totally different method to read from it.

But with it as I said, you could enter a persons information. The only difference was if they were a user on the system you could give them access to change their own information or an admin could do it.

The original use of the module was to show profiles with pictures of members of a video game clan. It looked like it was built piece meal. You had to be an admin to enter the information. To change the supported information you currently have to edit the entry forms, the shown screens and the database routines.
I added the remote user stuff and some of the other features.

What is nice about it is that it does display the full list of users and you can choose the one you want to look further at.

This module would also work nicely if you wanted to show profiles of a board at a company or something of that nature since you can control who is displayed and who isn't. And they don't have to be members on the system to be displayed.

Redheadedrod, which SVN did you upload to, the tortoise one? I will try it on a dev server to see what it does but am reluctant to try on the production one. Sounds interessimundo.

Link to SVN Hacked xRoster

Please note that I wrote this about 3 years ago and never released it to the public because it was a rushed hack job and I never cleaned it up. Mamba added the 2.5 admin to the original but he did not have access to this version so my version does not have the 2.5 admin. I had little knowledge of how to interact with xoops so no xoops related functions were modified so there is likely lots of crap code in this module.

The old version has much of the stuff hard coded in and very little flexibility. It has no link to users on the system and is pretty much a stand alone module.

The old version has a simple user list and a single user listing with a picture. The admin I believe could edit entries but was very basic.

I added a way to link a user on the system to their entry so they could edit their own entry. An admin has to approve any changes before they are displayed. A user could also "register" as a new player if they don't already have an entry and it would be approved by an admin.

Pictures are added to a preferred directory manually (ftp or otherwise) and then their file names can be entered into the form by an admin.

Registered users could look at the player list and look at a specific player and it would display their picture and whatever stats were entered. No contact information is given. A registered user could also register as a player if they desired or could edit their player entry if they had one linked to their online account.

Coaches could do the same as registered users but I think they also might have been able to approve registrations. They could also see the contact information and could print out a contact form that listed all of the players and their contact information. May have been able to edit entries too but I don't remember.

Admins could do everything coaches could do as well as edit entries for sure and edit some of the basic system settings.


I wrote this module so the coaches and admins could make minor changes without involving me. If they wanted more then I would have to make those changes. To change the fields allowed it is rather tedious because you have to change it all in the code. The entry form, the display form, the database read and the database write routines.

As I have already mentioned I plan to rewrite this module along side a rewrite of profile. My new profile module will be intended as a full replacement of profile. The new roster program is intended to be used as a "roster" for a business or a team or otherwise where not all members are on the system and may provide different information than their profile would. I plan to develop them together so they can share the plugin system for the data types.