Profile Pro Project

[Andreas]

For a very long time person after person has started with modding and rebuilding the Your_Account module and time after time these projects have failed, the responsible people disappear or stop working. The time has come to organize work on a level where more people can work together and post information publically, so should one user drop out, others can continue working.

The main focus of this Project would be to remake how the Your_Account module works today. Below a number of general ideas will be posted on what a new, updated version should be able to do. I will call it Profile Pro (in line with Downloads Pro and Forums Pro).

Modularity: Today certain information is fixed at the top and blocks show up in alphabetical order below this fixed information. We need to be able to decide what goes where in the layout of Profile Pro. For example, perhaps you want to show the users avatar side by side with links to his Blogs, his Forum entries and his Downloads. Below this, you want him to be able to display his personal gallery. To achieve modularity we need to do the following.

- The current information needs to be entered into YA-blocks so a user can define what blocks to use.
- An admin interface needs to be created which could look like the Blocks layout. A block can be either centre, right or left and have different weights.
- The main layout needs to be remade to accept the admin set blocks.

Not only does this allow people to layout their Profile Pro the way they themselves want it, it also allows for people to specifically create special blocks for Profile Pro, permanently adding to the features available for Dragonfly Users.

Presentation: I believe that a greater community feeling could be achieved by having a presentation block which allows the use of BBCode and even image uploading. This is a straightforward idea, but could have complicated parts to make it work.

- BBCode available. A user should have alot of text space (40kb) as a maximum and be able to use the limited design options of BBCode.
- Image uploading, this is a big maybe and would be used for uploading a personal picture of the user.

I suggest everyone with an idea for Profile Pro to think it through, write it up real good and post it here so that we can gather what people feel is most needed. Once we know whats needed we can call in the "coding team" and have them evaluate what is possible and what ain't. After that, we draft a timetable and roadmap for the project and get to work. So come on people, add your ideas to ours! Building a better community, user by user!

I will update this thread continously as people add ideas and as people sign up for the project. If YOU are a coder or programmer feeling like you could chip something in, feel welcome. The idea is to either post material here as attached files, or if we are granted CVS-space have all coders commit information to the CVS.

Interested coders/programmers:

* mc__: has expressed interest in helping out with the module and is already kneedeep in the Forums Pro debate and work.
* Spacebar: with four modules written under his belt and one of them being a Buddy List Spacebar will bring needed knowledge.

Edit: Removed the "unofficial" at the top. First of all, no "official" project has been announced with [official] in it, so no need for that. Second of all, it IS an official module but not authorized or authored by the DevTeam. It is official for everyone to join and download (in the future).

[mc__]

$prefix.'_profile_pro_presentation'

user_id, title, content

if they wish to hide certain stuff from certain people then they can use my nbbcode modification's selective display tags, which allow show to group, show to user, hide from user, only admin, only member, only guest... amongst other face-lift modifications such as spoilers and scrollboxes (overflow: auto div's wiht a theme-defined width and a bbcode-tag defined height ([scrollbox=240]blah blah blah[/scrollbox])).

$prefix.'_profile_pro_blocks'

bid, filename, x_pos, y_pos, width

bid is just to identify them, filename is where to get the content from, width is for theme template to use, xpos is where it is positioned in it's row, y_pos is what row it is in.

x_pos is either 1,2,3,4 and colspan's will be automatically calculated (so the themers should use table syntax coz it's the best for this particular purpose, seriously it is don't argue )

the colspan's will be like if it is the only one on it's y_pos then it is 4, if it is number 1, and the only other one sharing it's y_pos is a number 4, then it's colspan is a 3, etc...

$prefix.'_profile_pro_custom'

user_id, bid, state, x_pos_override, y_pos_override, width_override

allows users to deactivate / re-activate blocks in their profile (they'll see a themeable close button and a edit icon in the top-right that no one else sees excpet can_admin($module_name) type admins).

One deactivated it will appear as a block at the end of the x_pos y_pos chain, (on a new y_pos so as not to affect the last visible boxe's colspan if there is a special case one with it), only it's content will be the filename and a not saying that no-one else can see it, and the restore button will be in the top-right (along with edit icon), allowing them to re-activate it.

once / if they click on a edit icon a popup will show asking for these:

x position override (must be 1 - 4):

y_position override:

width_override (think colspans):

and when the submit it will submit it and then reload it's parent upon completion and auto-close. If it took the x_pos of something allready existing in the y_pos row given then the script should automagically bump one over as necessary and continue along and down untill its all done.


Also if the x_pos is 2 or 3 or 4, and there isn't any other blocks on the applicable y_pos row, then it is taken that it starts at this table, and colspans untill the end (colspan 3 for x_pos 2, colspan 2 for x_pos 3). This is to allow a right-aligned block exist if for some reason it is wanted.


Width and width_override are to limit the colspan values, so you could have left and right alligned blocks without the leftone becoming really fat.

---

more comments, more suggestions, c'mon people this is serious.

[Andreas]

A first step would probably be NOT to allow users to edit or modify these blocks, rather leave it to the Admin until we get everything going. I'd rather see that we start small and get it up and going - and THEN expand on the possibilities.

Is it possible to use the existing structure in Dragonfly's Your_Account or are we looking at an entirely new module which will just upgrade Your_Account (like Downloads Pro did?).

[mc__]

Not entirely new.

We can still use some of the existing code, however YA doesnt even have its own database table just yet, so it'll basically be a major rewrite.

I figured that we should talk about letting users edit it because once i start it won't be much more work to implement that, like about another hour, nothing at all.

What i don't want to have to do is do something, realise that it's wrong, and have to redo it all over again.

It probably will be a entirely new module actualley, i'll just copy+paste reusable code form YA and put it into profile_pro

So yeah. I'm currently editing the cpg_inst.php for Forums Pro on my site, toying around with subforums and such, and i won't start this untill we have a big grand idea of what we want, because what i've mentioned would be good, but it could do with more.

However most interesting functionality that i can think of shouldn't be a part of profile pro but instead separate modules with their own database tables and simply include a profile pro block...

Also another thing,


$prefix.'_profile_pro_blocks'

bid, filename, x_pos, y_pos, width

becomes


$prefix.'_profile_pro_blocks'

bid, filename, groups_csv, x_pos, y_pos, width

groups_csv is a comma separate values varchar(255) db variable that will contain a list of all gid's (or group_id's) that are allowed to view it, if it is empty then it can be assumed that all are able to view it.

Normal blocks have this (or something similar) so so should these.

[Andreas]

If it ain't that much more work I suggest that we allow users to edit certain blocks, but I believe that the Admin should be able to turn this editing on/off (either in general or for certain blocks).

I also have an idea about blocks and Profile-Modules. Is it possible to allow a module to add another "subpage" to the Profile Pro layout? For example, lets say we have the Buddylist and Personal Guestbook that I'd like for my site. Instead of adding two potentially VERY large blocks and distending the site alot, they install as "subpages". At the top of the Profile Pro page is an area with Links to subpages and each subpage only retains those links at the top while substituting everything below.

That way a guestbook, personal gallery or guestbook can be allowed to take up more space without bloating the "mainpage" of Profile Pro. Does this sound like a good idea?

Topmenu:
|Mainpage|Personal Gallery|Guestbook|Buddies|

Everything below is dependant on topmenu-choice of subpage.

[spacebar]

Sounds to me like a brand new module is needed and to me that module sounds a lot like MySpace.com

The different YA block code could be used, but starting from scratch design wise shouldn' be dismissed outright.

[Andreas]

I believe that is what mc__ suggested, that we scavange code written for the YA-module and create an entirely new module. The MOST important thing though is to remember that registration and alot of other things seem to be keyed to Your_Account and in some way we might consider keeping the folder-name and important files so that we can do an upgrade without having peoples sites go down.

Spacebar, would you be interested in helping out with this module?

[spacebar]

Yeah. I'd be interested in helping out. I've coded 4 modules mostly from scratch now and tweaked a stupid amount of mods ... so I'm getting the hang of the the DF CMS architecture.

[mc__]

Yes that is a good idea, about subpages.

The best way to implement these is for them to all be separate modules out-right, that have a profile pro block that links to their main module view...

There will be a few more ammendemants to the $prefix.'_profile_pro_blocks'

bid, filename, groups_csv, x_pos, y_pos, width

---

$prefix.'_profile_pro_blocks'

bid, filename, groups_csv, x_pos, y_pos, width, editable, nav_getlink


editable is a tinyint(1) stating whether or not it can be edited by the end user, and nav_getlink is the arguments given to getlink to create the hyper link to the module's page.

The text for it should be the filename of the profile pro block with underscores replaced by spaces.

[Andreas]

Sounds like the perfect way to go and allows people to write small mods (PP_blocks) or larger mods (PP_modules) that can be incorporated into people's sites. We just need to make sure there are "hooks" available in the main Profile Pro module for subsequent subpages.

[spacebar]

What about allowing users to have the cms site theme switch to a theme of thier choosing when a user browses to their profile.

Or better yet a module to store themes in a table could be made, default themes provided and then users could make their own and decide exactly where they want things.

If the cms owner doesn't want users designing their own themes, they could only provide a handful of default themes... or 1 that matches the rest of the site.

[mc__]

that could be accomplished in a profile pro module + block combo.

One thing to deside on is this:

should profile_pro modules be normal modules in /modules/$mdoule_name directory, or should they be special profile pro only modules that exist in /modules/profile_pro/modules/$module_name ?

The first case will always be availabe, but is there any need for the second?

If we want the module display ot be inlined in the profile view, then having a sub-module directory is the best way to do it.

Then a df module might contain files in these folders:

---

/modules/$module_name

/modules/$module_name/admin

themes/xxx/templates/$module_name

themes/xxx/images/modules/$module_name/

/blocks

/modules/profile_pro/blocks

/modules/profile_pro/modules/$module_name

---

there that about sums it up. Quite an extensive list, but is it really necessary? No its not, but is it still pluasible because of extra added functionality that one or two might like to take advantage of?

Well I think that it is. But i want to hear other's opinions on this. The idea of a profile_pro modules directory is for the organized placement of sub-pages in the profile area (modify avatar settings, modify prolie information, xxxmodule_xxxfuntion, etc etc).

We could do it many other ways, including letting other mdoules stick to their normal module directoy and add a link via inserting values into a specific syq table, but i think that this way is the cleanest and best. What do you think?

[spacebar]

I would like my uses to feel they own their profile page.

I think profile blocks should read the data of Normal modules, special profile modules will fracture DF.

[Andreas]

I concur with Spacebar, we shouldn't add another layer of abstraction and more directories for people to worry about. We should use the normal /modules/ModuleName/ directory for modules, regardless if they are general modules or PP-specific.

About theming of Profile Pro pages I think we should both leave that for a future upgrade and even then allow the Admin to decide to turn that function on or off.

[mc__]

yeah but what i meant was that all of those directories would be used togeather.

a big module would put stuff into all of them. It'd put the script that generates PP block code into the profile_pro/blocks directory, and profile subpage code into profile_pro/modules directory.

This also means that a profile_pro subpage can be made that does not need to be included in df's module thing, therefore won't occupy a mid (permanently pushing the auto_increment up), and would be a lot cleaner.

The alternatives are:

A) Keep files in normal directory. Include subpages by letting profile_pro know by inserting subpage link information into a dedicated sql table

B) Anything that anyone else comes up with.

I personally like the extra directory approach, because editing it does not require phpmyadmin.