panels-profiles

What is it? Building user profiles with panels? Or installation profiles? Or making profiles for panels?

Michelle

Awesome! This sounds a lot like the mysite module. On my CRO site, my plan is to have profiles, which are all about the user and mysite pages which are user aggragated content. It sounds like yours is a combination of those.

I actually use the panels css for http://shellmultimedia.com/tutorials/user-profiles and would love to be able to use panels itself. I can't help much with the code but can do testing and UI feedback.

Michelle

subscribe

Great. I'm willing to help with testing and UI stuff.

If I manage to find the time, I'm willing to help. (I wrote Mini Panels.)

also subscribing, been holding off a shift from core profile module until something like this shows up.

Some points:

Panels profiles should define the URLs available administratively and not let the user define that.

Panels profiles will need a 'user' context. Note that the user context doesn't exist, but it'll be a context that contains the user object.

Since the user context doesn't exist, there aren't any content types that use it; the only thing I can think of offhand that should use it are the author information block (which we have to rig up because the block uses the URL and we want something like that block, but uses our passed-in context) and the actual profile pages.

Can we get an overview of your plans? I'm planning on updating my tutorial to use panels Real Soon Now and am interested in this project but there isn't a lot of information. Will it be using the core profile module, nodeprofile, bio, something new? Is this going to be a new sub module of panels? I don't want to waste my time doing my own thing if I can jump on your bandwagon but first I need to figure out what music you're playing. :)

Thanks,

Michelle

The hack-saw solution would be to use the Bio module, and then say that a Panel Node is your Biography type. Then when users register, they're given the option to create a Panel Node to associate with their profile.

That's a bad hack =)

A panels context is a wrapper around an object. The object can be anything Drupal knows -- a user, a node, or whatever.

A context can be created from an argument.
A context can be passed into the system externally.
A context can be created from an existing context (relationship).
A context can just be in the system (future functionality).

Content can require a context to function.

For example, if I put the 'node content' pane into a panel, it won't do much good without knowing what node it's talking about.

Likewise, I can't have a user profile without knowing what user.

Context is how Panels is able to tie this stuff together.

I was planning on doing the same bad/clever hack with nodeprofile. Good thing we have Sam to figure this stuff out. :)

Michelle

This would be an amazing addition to the Drupal community. Any updates on how this is progressing?

Subscribing. Willing to test with the latest panels version.
Greetings,
Martijn

subscribing

subscribe

posted elsewhere

SORRY! Im new here, didnt realize that the main title would be changed
based on my comments title!!! (im not used to forums doing that...)

feel free to get rid of that extra bit on the title

This isn't part of the forum. This is part of project where people can change the title and other meta data with each comment. Fixed it.

Michelle

Glowingtree -- please open a new issue. You have some interesting questions which I think can be answered here, but not at the cost of unfocusing a good, if somewhat stalled issue.

subscribing

would love to test this when it's ready! =)

This sounds great! I am hopeless at coding, but will be happy to take it for a test drive when it's ready :)

Thos of you tracking this should probably take a look at Michelle's Advanced Profile module - which is already doing a lot: http://drupal.org/project/advanced_profile

What Sam is doing is a bit different. We've talked about it, trying to work them together, but I'm not sure how at this point. Whereas advprofile uses one panel page and takes an argument for the UID, Sam's (if I'm understanding correctly) allows users to actually create panel pages that show up as tabs on the user page.

What I need for advprofile is a way for the admin to define the master panel page that's used for profiles but allow per user custom layouts/content. I had hoped this would help with that, but it doesn't look like it will. At this point, I think these two projects are going down too different of paths, unfortunately.

Michelle

Ahh, I see!

These two projects *should*, at the end of the day, be mergable. The difference is that advprofile relies on a panel page, whereas the panels_profiles module will not rely on a panel page. However, it should hopefully end up supporting all of the gadgets of a panel page, (except with fixed 'arguments' and built-in context) as well as be exportable. So hopefully once all of that stuff is in place, advprofile will be able to take advantage of this.

I think Sam needs some help, though =)

It would be nice if they could come together. Maybe I'm just missing something.

What I would like to have at some point is this:

* The user clicks the edit profile link
* They are presented with the "content" tab of a panel.
* The panel starts out with a standard set of content.
* The user can add/remove content but is limited to what the site admin has allowed access to
* The user can change themes for the profile from a limited selection
* The user can change layouts from a limited selection.
* The changed panel is saved as a user setting, not added to the panels pages list because that would be a huge mess.

So will Sam's module help with any of that? Maybe I just misunderstood it...

Thanks,

Michelle

Thanks. Advanced_profile is also very interesting. Will definitely try this out. =)

This is what advanced profiles was suppose to be about... I understand Michelle, and the projects shouldnt be merged... THEY ARE THE SAME PROJECT!

I feel the best solutions are to use the pre-existing building blocks, and then build something that hooks them all together into one solution. I support Michelles approach rather then a program that is separate from everything else, thus eliminating the ability of us to do things that were not planed for in the original scope. change views, cck's, etc...

Anyways, check out what I did with advanced profiles http://www.allourquilts.com/user/1

The application needs allot of work, I had to essentially build everything myself, and still am... What you need to do is build style panes, pane that can be controlled by the user...

Please don't change the title of the issue! :)

Sam is working with panels as well so I'm not sure where you're getting that it's separate from everything else. It's unfortunate that we haven't been able to combine our efforts, yet, and I hope we can at some point. But I just really needed to get going on this and Sam's wasn't ready when I started and we ended up going down separate paths. Merlin seems to think they can be merged and he knows far more about panels than I do, so we'll see. :)

Michelle

I am working on various panels. Most Panels use uid, where in the user account page we needs to use arg(1). I am more then willing to share the code that I am working on. Some of it was from UserProfiles2 (good job Michelle), others I am working on as additional custom blocks. I am working on one right now for user points. It will probably be a modification of the block for User Points, however it will have to be a separate block. There are other things like user views of the default advanced profile information that is included. I don't know what you guys want to do with this. Use BIO or usernode. I prefer usernode and was going to change over to user node as to avoid another separate user info tab. I am very busy with my own site, working around 8-12 hours a day on it, but I see allot of the work I am doing as being very compatible with this.

Just some quick feedback. I don't know how this module is coming along, and I'll still definitely be interested to see the result, but Michelle's Advanced Profile module just does it for me. It's perfect. As Michelle pointed out, it's just "glue" but it saved me hours, if not days of head scratching! Highly recommended.

One note - it puts the Latest Comments (I think?) mini panel (again, I think? apologies of terminology is wrong!) in the user profile panel page automatically. This is cool, unless you do not have Comments installed. Panels 2 currently assumes you do and you get a nasty PHP warning. Just delete it, no more warnings. Michelle already added this as an issue against Panels 2, so no need to re-post it. =)

This is a long discussion by now. Perhaps it would be convenient if Sam would start a wiki page for this, similar to what Michelle did at http://groups.drupal.org/node/7982.

Sam-

Are you coming to Boston? We really should discuss the role of MySite in the Panels world for Drupal 6.

http://groups.drupal.org/node/8780

http://drupal.org/project/mysite

Here is my basic design.

2 tables:

create table panels_profile {
  ppid int -- unique database identifier
  name varchar -- unique identifier for exports
  path -- example: "profile"
  -- plus any options necessary
}

create table panels_profile_user {
  ppid int -- profile this belongs to
  uid int -- uid this belongs to. Use 0 for the 'default' user which is what users who haven't modified their settings will get
  identifier -- So we can have multiple profiles per path: i.e, profile/%user/%identifier
  did -- id of the display
  -- plus any user settable options necessary.
}

Administrative UI:

• Allow administrators to create one or more profile paths.
• Allow administrators to create one or more identifiers for that path; there should always be at least one 'default' identifier.
• Allow administrators to edit the default display for each identifier. This UI will only include layout, layout settings and content -- users will not be able to add contexts.
• Allow administrators to restrict what content is available for this application.

User UI:

• Allow users with privilege to edit their version of any given profile identifier.
• Allow users with privilege to add new identifiers just for themselves
• This UI will allow adding contexts via arguments and relationships. All user displays will inherit these.

Menu 'path' handler (eg 'profile'):

• Will assume/require a 'user' argument. This could just be in the UI, but obviously a user argument will be required so we can match up displays.
• Will see if this identifier for this user exists; if not, load identifier for default user. If not exist, 404.
• Load all contexts into the display; set options. Show display.

There are likely more subtleties to be thought about:

1. Permissions.
2. Menu links to profile pages.
3. Some existing content is not suitable in its current form for users to use, so simplified variants (similar to panel views) may be necessary to make a good end user UI. This will be especially true for profile pieces.

Does this help people understand what at least I am looking for here?

Wow, that sounds perfect! Now all we need is someone with the skills and time to code it. LOL! Unfortunately, that's way beyond my level so I couldn't take a lead in the development but I'm up for testing and bug fixing.

Michelle

I like the idea of a glue module for this. Michelle advanced profiles makes perfect logistical sense. What should be done is to encourage developers and to set out a standard to include their modules in this glue. You are right, the Panels application would be nice. Change the params on the panel from $user->uid to ARG(1) or what ever you want. Honestly, that and more support for panels seems to be the two major stumbling blocks that I have encountered.

Also, Bio is rough... Im afraid my users wont see the extra tab, and wont fill out the information. Would be nice to include the data within the usernode itself. If only the User Node itself was put into panels:-p

Ohh I second the notion of having an Advanced Profiles type OG.

i.e.
User A, display 1
User A, display 2
User B, display 1
User B, display 2

As opposed to:

User A, did 1029
User A, did 3498
User B, did 2307
User B, did 3098

The former doesn't work; display IDs must be unique and are assigned to you, you can't assign them. So you have to go with the second variant regardless.

Just do a panel_save_display() and the did will be returned to you. The API for panels_edit on the content tab will also return a DID to you as well.

* Allow administrators to restrict what content is available for this application.
Isn't this available through the panels-api? I copied panels pages for this.

It is, but it's very simplistic; it's either on or off. For this application we might need to do role based. I dunno, though; the UI for doing that could be terrifyingly complex.

3. Some existing content is not suitable in its current form for users to use, so simplified variants (similar to panel views) may be necessary to make a good end user UI. This will be especially true for profile pieces.

This isn't entirely about permissions and about complexity in the UI. I wouldn't worry about this part, though; this can come Later. It's a polish thing.

CREATE TABLE {panels_profile} (
uid int(10) NOT NULL DEFAULT 0 PRIMARY KEY,
css_id varchar(255),
did int(10)
);

This setup allows only 1 display per UID, because UID is unique. You need some other identifier in order to have multiple displays per uid, and then uid most no longer be unique in the table.

If you don't store the path somewhere then I guess you're hardcoding it to user/%uid/something which seems limiting to me. 'mysite', for example, exists on a totally separate path.

Subscribing and offering developer hands. I want to write up a case study about doing per-user customized profiles in the social networking chapter of the Lullabook, which is for D6, and http://groups.drupal.org/node/8780 implies that MySite won't be updated to D6.

Sam, where are you at, and how can I jump in?

Webchick - My understanding is that MySite will have a migration path, whether MySite is upgraded to 6.x as is or it merges with Panels 2.

Michelle

@webchick

Right, I'm torn about how to proceed. At the moment, I'm tempted to port MySite to 6 -- that may be faster than Panels integration.

But then I'd drop MySite development in favor of Panels integration.

Comments http://groups.drupal.org/node/8780 are appreciated.

subscribing

Just an FYI for interested parties: we'll be picking up the original direction of this work and (I hope) taking it a step beyond as well. I've posted a transcript of Michelle's and my big-think on this issue at http://groups.drupal.org/node/11388. I'd love comments.

subscribing

Subscribing

Hi Panel People,

I'm debating Michelle about her Advanced Profile Kit, you might be interested. She is in favor of the Content Profile module, I am against it. Please discuss.

I don't know what there is to discuss. I already said I'm not going to write the module you're asking for. I will be cleaning up and porting APK without any radical changes so people have something to use until sdboyer and I are able to do the panels user module. If you would like to write a different module, feel free.

Michelle

Ha ha, I tried

hobgobber: That was an inappropriate hijacking of the thread, IMO.

sorry

This is a dead end.