In the next few months I will be looking to completely rewrite profile. Although this module has been a great module for a few years now I am building a new social networking site that will require more flexibility than the current module provides. Instead of developing 3 or 4 more modules and making things more complicated or adding code to profile to make it do things it wasn't originally designed to do I have decided to redesign profile from the ground up. Since this is such an important module I expect this to take a while to do. I am opening this thread now because I would like to discuss what is lacking and new ideas for things to add to profile. I want to write profile to be more of an engine to tie things together instead of a module trying to do everything.

Since I am also working on some other modules I should make aware that I don't expect to spend any real coding time on this project until I have major completion done on the other modules.

I want to kick around some things so I have a pretty good idea what we want to do with profile.

This project will end up making two separate modules. I am using the idea of the xroster module to build a new module which I may end up just calling Roster. The intent here is sort of a profile lite but I plan to develop and test a few of the features I plan to use with profile to the point the add ons should work for both modules. This module will essentially allow you to have "profiles" of people that are not on your site for special projects. Such as a church directory, team roster or whatever. This will also tie in with profile to allow those people who are in the roster that are also tied into the site to be able to make changes to their entries to update things such as their phone number or address. Will also support locking of the roster as some sports require a roster that doesn't change once the season starts. After that point only things such as phone number or address will be allowable to be changed. Once "roster" is at an alpha stage I will open up other things to add to it.

At this point my initial plans are to change/add the following areas. I expect to totally rewrite the profile module but plan to reuse code when possible. The new profile will be designed around php 5.2 and xoops 2.4.5. Should work with 2.5 plus anything else that comes along. I am also going to encapsulate ALL xoops related functions within module objects. This will allow for easy transition to another framework when available without major recoding of the main module. So if there is a fork of xoops that uses a different setup than xoops does with the xoopsobject and xoopsobjecthandler it will be rather simple to "port" the module over. Yes this comes from my recent introduction to a certain fork of xoops but it makes sense because by doing this it will allow easily transferring not only to that cms but should make updating the module easy for any upgrades in x3 or other future enhancements to the xoops family.


Data fields:
Currently there is a somewhat flexible setup that allows new data types to be added by hard coding them into the code. I want to make this more flexible and allow through plugins to allow for ANY type of data to be included in the profile. While this doesn't sound like much on the surface, the intention is that you will be able to attach ANY type of data to your profile. So plugins for video, audio, or any module would be an easy thing. This would be taking coding for these out of the module and place it into the plug ins. I haven't decided yet the best way to add support for plug ins and will be looking at other modules and such to see how they have done it. Likely it will be done by setting up an object.

Verification/authentication:
Will likely look at adding plugins here as well. I want to make the verification system somewhat transparent and allow much flexibility. I have some ideas for making a dynamic system that will make bot registrations virtually a thing of the past. It will be very difficult for a bot without using AI to get around the system I have in mind. By using hidden fields, generalized field names, CAPTCHA style through out the form, jquery fields, XML tracking, graphic field titles, and some other things a normal user should not be able to tell the difference but a bot will not be able to easily guess this system. There will be plug ins to also allow other types of validation as well. I am thinking here that there will be two kinds of verifications available to the system. Static and dynamic. The static verifications would be like having captcha being a requirement each time. The dynamic ones would be like having captcha one time and recaptcha the next time or some other random verification or combinations.

Groups:
I want to expand the flexibility of groups and I think profile is the place to do it as it deals with users. I want to add group based themes. These would allow you to have different themes available to different groups. These would include both the user and admin themes. A simple example would be a theme dependent on if the user is male or female(different groups still). I also want to add support for memberships as well. Will likely add support to use a payment system such as the one wishcraft is developing to allow memberships to be totally automatic through a payment system.

Registration:
I want to provide a little different system here. There will likely be a common first step registration that will be used for the initial activation. Beyond that, after activation further steps will be available. The registration steps will be setup with the availability to set them according to group. Selection for the group they should belong to will be available for the initial step. Again think here, women would belong to one group men to another and they would have slightly different registrations. Or for a team you would have different registrations dependent on if the person was a player or a fan or a coach etc.

profile permissions:
I want to add more of a permissions system to the fields than just "visibility" or "editing". More of a "roster" thing but will use this example to explain the intention. On a team site you have fans, players, coaches and team management. You want each of them to be able to view different portions of a profile and to be able to edit or change things. Plus you may want the coaches and management to be able to view phone numbers and all team people able to view addresses. These types of things will be addressed with profile permissions by field.

user interface:
With the first few versions I will want to get the base core of the module to work without issue. Once that has been accomplished I want to make the display of profiles totally dynamic. At first the admin will be able to design a few base designs that the people will be able to choose from. Eventually I am thinking along the lines of what myspace did with the "profile 2.0" for those familiar with it. For those NOT familiar with it think of how the block management is done with xoops 2.5 and then you are on the right track. Basically the display would be made up of blocks that you order by dragging around on the screen. The blocks will be able to be defined for what you want to display. Not unlike how categories are now. And I would hopefully be able to also define some CSS items in this as well so you can change the background and colors for the profile when it is displayed. This may also extend into the editing portion of the profile but the user interface will only be able to be modified by the admin.


Wishcraft has been making some changes to profile to accommodate some modules he has come out with. I will be looking at those changes to make sure those still work with this module. I will be looking at developing the plug in system to support plugins for datatypes, validation, and whatever else I can do. Discussion on this will probably become more active when I actually am building the code for the plugins.

On our site the profile module forms the basis for our membership roster, that is for a national aquarium association. This is a criticial part and function of our web site.

I am interested in your project and would be happy to help test it when the time comes. I'm not a programmer but I do pretty well at finding problems. I have a mirror site that I use for such testing.

I assume that your module would be able to import data from an existing list of users in the current profile module?

barryC

Good point Barry, I haven't even considered upgrades.. I will likely try to preserve the current profile listing to an XML file from which you will be able to import the information to the new profile.

However realize this new profile will be very different in structure so I am unsure how much will be able to carry over but when I get to the point of it being stable I will do my best to try to save over all information.

Chances are however that all data will be able to be converted over to the new profile once finished since the new profile is intended to do everything the current one does plus much more.


Also, if you have all your members of your roster on your site then profile will work fine. However if you have a roster of people for a group and only half of them are on the site then you would have a problem if you are required to list all of them. In my case a large portion of the team doesn't have access to a computer so they can't get on the site and enter their information. But the league requires ALL available player to be listed on the site with the official roster information and picture. So SOME of them will be on the site and some not. Those that are on the site will be able to update portions of their entries. With my roster module I will use profile entries where possible when the member is on the site and allow them to edit portions of their record. With off site members a roster admin will have to enter in all the information from an information sheet the member filled out.

Rodney

Yeah sounds like an interesting project rod, I would be willing to give a hand. I have only been adding the stuff people have been asking for like validation apart from captcha seeming captchas are pretty useless when it comes to human sweat shops for spam like the ones in india where someone is paid $1 a day to spam websites for the purpose of indian SEO Companies.

I would stray away from modifying Xoopsobjects, I tried this in the core and phppp is a hardliner doesn't like a thing changed at all. for example was some useful encoding functions for storying Unicode on latin1 database. Which does happen from time to time when people don't have a choice.

For your roster module, i have had a couple of enquiries that people are looking for a rostering module for softball. I oftered them a multifielded version of rostering which i think would be the best solution. It would take a couple of days to implement just means people will be able to make a roster of any type of any field combination.

When I am closer to this I will definitely contact you Simon. I already had plans to do that to get your input on some stuff but at this time I am at the early stages and want to get some feedback for things desired in the module.

Would like to bounce some concepts off you to see what you think. I know what I want to do with some of this stuff but not sure the best way to implement them.

My biggest challenge with this at this time is developing a plugin system that will work to allow these additions. My thought for the datatypes is to design a class template that will do all that is necissary. The plugins then would basically just be a bunch of classes added to profile then called from profile as needed.

I believe this can be done for the other plugins as well for things such as validation and such. Unfortunately for validation I don't believe there is a good way to block sweat shops without making things hard on normal users other than an IP or other network type block. But I believe I can block most any bot with the design I have in mind if it plays out in code.

I have no intentions of changing the core, however I would like to write this and any other modules I write so that if there ever is a change it will be easy to implement without major effort. Plus this would allow the modules to be modified easily to work with xoops forks that don't support the full xoopsobject or xoopsobjecthandler classes. Or if say a generic framework comes out that will do some of the functions better.

Rodney

Lots of interesting ideas!

I think it would be nice to include xincode in profile...

That would be nice to manage "default affecting group" for a new user, depending on a code he would specify during the registration.

like :
code "man => the user will be assigned to the group "x"
code "woman" => the user will be assign to the group "y"

So we wouldn't have to manage affecting group by ourselves! If they have a specific code (given in the association magazine, or closed community), they will be affect in the good group!

What do you think about it ?

Regards

PS : i'm also ready to test this new module on my test site !

Quote:

I actually think this would be better served in pm...
Which is another module I will be redoing.. But haven't even considered features for that yet.

but it should be something that would be available with a plugin.

Quote:

That is EXACTLY the type of thing I am intending. Can be man, woman... Fan, player, coach... Or whatever the site is based on...



Quote:

Patience.. I will hopefully be finishing the project tonight I need to finish up but then I will be starting on my team schedule module. I figure I am 4-6 months out from writing this module but maybe I will have less problems than I expect with the two modules I am working on now.

You might wanna check the user app and ACL in Xoops Engine or X3.
We are uploading X3 to sourceforge. Docs are not complete at this moment but hopefully there will be dev guide very soon.

Thanks phppp, DEFINITELY want to look through the X3 documentation. A big reason for planning to separate out stuff is not knowing what will be coming up in X3.