There are a ton of great & ongoing discussions about different ways to try to bridge the gap between some of the existing methods of organizing and presenting user data. The ones that I'm most aware of - and please do forgive me if I've missed something big here - are the ongoing attempts to bring Bio and Nodeprofile together, the discussion about integrating MySite and Panels, not to mention Advprofile, which is in itself an attempt to unify a number of disparate modules. Michelle and I have been talking for a while about Advprofile in particular, but the other day, the ball really got rolling and we covered a lot of ground. I need to finish the release of Panels2, so this isn't something that I'm going to be working on RIGHT away, but Michelle agreed that we should post up the transcript of our conversation so that we've got as long & far a running head start as possible before we get moving.
The discussion started with Michelle's pastebinning of her 'Advanced Profile Kit - Grand Vision,' which was as follows:
- Takes over the user view tab
- Admin chooses what content can be on profile pages.
- User has panels-lite interface
- Allows choosing from admin approved layouts
- Allows adding content into panels
- Content is restricted to what the admin has marked as allowed
- For each panel, user can choose whether it is visible to all, buddies only*, or just themselves
- CCK fields/fieldgroups content has an edit button that allows user to change the underlying content
- What about other whole panels (displays?)? Does it make sense for the user to be able to add more? Do any SN sites allow more than one "page" for a user profile?
- User should be able to upload their profile picture here instead of the account tab
And we were off and running from there. The numbers in my initial responses refer to the numbers in the above list.
===============
TRANSCRIPT FOLLOWS:
May 03 21:15:33 sdboyer-laptop - 1, 2, 3.2, 3.3, 3.4, & 4 have all been implemented on some level somewhere before, and are known to be quite feasible - Ed. note: 3.4 is complete and has been committed for beta4
May 03 21:16:41 sdboyer-laptop - a panels-lite interface isn't something that's been really worked out in a consistent way yet
May 03 21:17:15 sdboyer-laptop - there are some existing tools that do pieces of it, but more work on our end really ought to be done to tie those elements together and make creating a reduced panels interface easily doable
May 03 21:17:43 sdboyer-laptop - 3.1 is actually one of the first pieces of panels code i ever wrote, and i did a crappy job of it, but i'm rewriting it for beta4
May 03 21:17:46 Michelle - Whoah, sorry, I was in another window. Catchingup
May 03 21:18:13 sdboyer-laptop - there'll be an api for it that works just like the other main api editing components - panels_edit(), panels_edit_layout(), panels_edit_layout_settings(), and the new one will be panels_edit_available_layouts() or something like that - Ed. note: completed and committed for beta4
May 03 21:18:30 sdboyer-laptop - as with calls to the panels_context_create*() and content_type functions, it'll return an array of allowed layouts as per what's been allowed somewhere else in the panels admin interface
May 03 21:20:54 Michelle - Sounds like my "grand vision" has a lot of potential to happen
May 03 21:20:59 sdboyer - oh absolutely
May 03 21:21:28 sdboyer - 3.3 is implemented right now, but the interface for it sucks and it's inflexible, improving it is on my list
May 03 21:21:39 Michelle - As for how it is now, it's basicaly a panel page that overrides user/% and a bunch of minipanels / view panes
May 03 21:22:13 Michelle - Bascially what I'm going for is the user looks at their profile page and can customize it right there on that page
May 03 21:22:27 Michelle - Rather than going to other tabs to fill in bits of it
May 03 21:22:35 Michelle - And having a static layout imposed on them
May 03 21:24:58 sdboyer - sorry, four things goin on
May 03 21:25:22 sdboyer - yeah, that is a trick that'd take some creative implementation of the UI
May 03 21:25:32 sdboyer - and would be new territory for the panels API
May 03 21:25:39 sdboyer - however
May 03 21:25:53 sdboyer - i do think that it's also the way that the panels-lite interface should be implemented
May 03 21:26:08 sdboyer - lemme see, what else did i miss on the list
May 03 21:26:21 Michelle - Same here :) (4 things...)
May 03 21:26:23 sdboyer - 3.5 is a little outside my expertise right now, i've just been awed-at-a-distance by the cck integration
May 03 21:26:41 sdboyer - i've never seen 5 done, but i absolutely can't imagine it being any problem whatsoever
May 03 21:26:57 sdboyer - now, as for 4
May 03 21:27:09 Michelle - 3.4 would be nice, but I can see that being a future phase
May 03 21:27:11 sdboyer - my personal thinking on that is this -
May 03 21:27:29 sdboyer - actually, it's probably less remote
May 03 21:27:39 sdboyer - b/c it's pretty much the model of og_panels/blueprints
May 03 21:27:47 sdboyer - other SN sites don't do it, true
May 03 21:27:50 sdboyer - or at least, not much
May 03 21:27:55 sdboyer - personally though, i think that's a mistake
May 03 21:28:10 sdboyer - b/c it really does tend to lead to this 'mash everything onto a single page' nastiness
May 03 21:28:17 Michelle - I'm trying to think how that would look... You wouldn't want a top level tab for each panel page, I think...
May 03 21:28:24 Michelle - Maybe subtabs on the main tab?
May 03 21:28:36 Michelle - Using "panel page" loosely here
May 03 21:28:42 sdboyer - sure sure
May 03 21:28:47 sdboyer - i think it'd depend on who's looking at it
May 03 21:29:11 Michelle - Hmm... true. Non admins and non user in question woudln't see so much
May 03 21:29:15 sdboyer - oh...man did i just get a crazy freakin awesome thought
May 03 21:29:25 sdboyer - hold that, finish this first :)
May 03 21:29:26 Michelle - Espeically if you dropped the track/contact tabs
May 03 21:29:27 Michelle - Yeah?
May 03 21:29:42 sdboyer - yeah, i think it's gonna be a question of how the other tabs get dealt with
May 03 21:30:08 Michelle - So you'd go to blah.com/user and you'd see several profile tabs at the top level and nothing else unless you're that user or an admin...? That's not so bad maybe
May 03 21:30:16 sdboyer - clearly it makes sense to have some separation between the pure panels/profile/blueprints/fun tabs and the other ones
May 03 21:30:30 sdboyer - but yeah, i think that's part of the question
May 03 21:30:34 Michelle - Or you have one tab named "profile" and subtabs under
May 03 21:30:41 Michelle - Not sure which is better
May 03 21:30:50 sdboyer - to me, this comes back to one of those central questions i know we've talked about before
May 03 21:31:18 sdboyer - which is the difference between what might show up at the user/1 page itself, as it's currently defined, versus what shows up at this profile-as-node thing instead
May 03 21:31:22 sdboyer - are those the same thing?
May 03 21:31:32 sdboyer - or are they different, kinda like account vs. profile?
May 03 21:31:39 Michelle - Well, in advprofile's case, the actual node redirects to /user
May 03 21:31:45 Michelle - And then the node is just part of what's shown
May 03 21:31:49 sdboyer - right
May 03 21:31:56 Michelle - For advprofile, the node is jsut a holder for the data
May 03 21:32:13 sdboyer - and i mostly just used the url as a means of pointing out that, by default, that's NOT a node
May 03 21:32:16 Michelle - Actually, the holder is irrelevent. You could use it with core profile if you wanted
May 03 21:32:23 sdboyer - yep yep
May 03 21:32:26 sdboyer - painful though that might be :P
May 03 21:32:30 Michelle - Heh, yeah
May 03 21:32:40 sdboyer - my fundamental issue here is the more kinda abstract theoretical one
May 03 21:32:46 Michelle - Basically, I want advprofile tied to the /user page and not care what exactly is in it
May 03 21:33:16 sdboyer - do we separate accounts from profiles, when do we do it - if we do by default, do we allow reintegration? if we don't by default, do we allow integration?
May 03 21:33:49 Michelle - Ok, you just lost me
May 03 21:34:19 sdboyer - hrm, ok, lemme try to paint the three distinct cases that i see
May 03 21:34:28 Michelle - Ok
May 03 21:35:39 sdboyer - case 1 - user/1 contains more or less the same sort of stuff that we see in it now. it's primarily geared towards the user him/herself for the purposes of account management
May 03 21:36:07 sdboyer - at the same time, profile/1 is one of this nifty-fangled panelized profiles we're so keen on
May 03 21:36:32 Michelle - I'm not too worried about the URL as long as theme_username points to the profile, not the for the user thing
May 03 21:36:45 Michelle - Basically, anyone wanting to look at the user should see the profile
May 03 21:36:52 sdboyer - again, just using the urls as a means of concretely differentiating between what's a node and what isn't
May 03 21:37:00 sdboyer - not that that's the best way of doing it, heh
May 03 21:38:07 Michelle - Well, in my "vision", we're going beyond profiles as nodes... The node simply becomes a container to hold some of the profile data. The rest is gathered from other sources and brought together into a profile as page
May 03 21:38:07 sdboyer - case 2 - no big-expanded profile at all, all we've got is pretty much the user/1 page that ships with drupal now
May 03 21:38:42 sdboyer - i'm with ya on that, but i'm stuck back where i am because i see a data organization & consistency problem that i think needs to be resolved before a grander vision can be effectively realized
May 03 21:38:43 sdboyer - all imo
May 03 21:39:05 sdboyer - but you're right, i should stop calling em nodes, nodes isn't the point
May 03 21:39:27 Michelle - I'm pretty open on this. I've got ideas, of course, but I'm up for collaboration, too, so any input you have is welcome
May 03 21:39:45 sdboyer - so yeah, case 2 is essentially similar to what we see on d.o right now
May 03 21:40:00 Michelle - Yeah, case 2 is pretty icky, I think
May 03 21:40:15 sdboyer - indeed, BUT...well, i'll come back to that
May 03 21:40:16 Michelle - Just dumping stuff on a page like that is no good
May 03 21:41:44 sdboyer - case 3 is more along the lines of what we're talking about - something that integrates the awesomeness of panelized profiles with all the stuff that used to appear and be used in the old case 2-style system
May 03 21:41:48 sdboyer - and the necessary result that we've got users able to control and lay out some, but not all, of what appears on their profile pages
May 03 21:42:12 sdboyer - from a programmatic angle, i don't think these really need to look all that different
May 03 21:42:39 Michelle - That's always been a difficulty... by taking over the page, you lose what modules dump on it. Personally, though, I don't think modules dumping things on the user view tab is a good idea
May 03 21:43:07 sdboyer - i'm talking much more about the end-product - my thinking is that any given drupal site is going to want something that falls into one of the three categories, and so the system that eventually wins here is going to be the one that can easily accomodate each of these three outcomes
May 03 21:43:24 sdboyer - right, and it's often done pretty badly, but
May 03 21:43:33 sdboyer - it's also not a functionality i think we can really justify eliminating
May 03 21:43:52 Michelle - Well, if we just make a user profile "thing" which is basically a panels page but maybe something custom to this if needs be, then the site admin is free to give it whatever URL they like
May 03 21:44:21 Michelle - I would set it to user/% by default but they coudl change it to profle/% or anything
May 03 21:44:28 sdboyer - yep
May 03 21:44:42 sdboyer - yeah, my hope with all this
May 03 21:44:49 sdboyer - and this more or less constitutes the second part of my comments on that list
May 03 21:45:31 sdboyer - is that we'd see advprofile grow into something that accomodates all three of these cases, which i think you can also sort of divide along 'private', 'semi-public', and 'public/almost all public'
May 03 21:46:01 sdboyer - that advprofile would be able to handle splitting some content to one URL and the other content to another (if needed)
May 03 21:46:14 sdboyer - and it would also provide a system for structuring whatever stuff other modules want to dump onto the user page
May 03 21:46:23 sdboyer - so that it's dumped in a well-organized, coherent way
May 03 21:46:45 sdboyer - or, in case 1, it's simply dumped into it's own separate space
May 03 21:46:57 Michelle - Hmm... I dont' actually know how stuff is added to the page now. If it's something that could be intercepted, that's not a bad idea to grab and redirect it
May 03 21:46:58 sdboyer - ...a space which also happens to be nice and well-organized :)
May 03 21:47:09 sdboyer - i'm glad you think so
May 03 21:47:29 Michelle - My concern is that it's just form_alter'd on... Can that be grabbed?
May 03 21:47:30 sdboyer - basically my only point here is that you can't really think about doing profiles effectively WITHOUT having a good system for handling everything else
May 03 21:47:43 Michelle - True. I've been sort of glossing over that so far
May 03 21:48:04 sdboyer - i think you actually already cited the solution to that
May 03 21:48:13 sdboyer - what we're talking about aren't nodes
May 03 21:48:26 sdboyer - they also aren't whatever-the-hell-user/# is right now
May 03 21:48:32 sdboyer - they're...panels!
May 03 21:48:40 sdboyer - they live in that ethereal space that panels is in :)
May 03 21:48:44 sdboyer - consequently
May 03 21:48:45 Michelle - Hehe
May 03 21:48:57 sdboyer - it's COMPLETELY under your control to determine what content does or does not appear, where it appears, etc.
May 03 21:48:58 Michelle - Back to the "panels profiles" idea
May 03 21:49:02 sdboyer - yep
May 03 21:49:13 sdboyer - i (big surprise) think it's the right solution
May 03 21:49:24 sdboyer - just that it needs to be built & scaled in the right way to accomodate all these possibilities transparently
May 03 21:49:27 Michelle - So we encapsulate the whole profile, including what modules want to dump on it, into our "panels profile" and that can be put at whatever path the admin likes
May 03 21:49:37 sdboyer - yep, or
May 03 21:49:53 sdboyer - it can be split into two separate paths, one for the account-y info and the other for the profile-y info
May 03 21:50:02 sdboyer - whatever floats their boat
May 03 21:50:54 Michelle - Yeah, I think there's a line there between what is "settings" and what is "profiles"
May 03 21:51:00 sdboyer - dealing with the results of the original user profile system & such then just reduces to a question of designing some gnarly panels content_types
May 03 21:51:02 Michelle - That's why I want to move the avatar upload
May 03 21:51:06 Michelle - That's a profile thing, I think
May 03 21:51:08 sdboyer - for sure
May 03 21:51:14 sdboyer - but of course, it's also subjective
May 03 21:51:23 sdboyer - or rather
May 03 21:51:34 sdboyer - maybe not subjective, but dependent on the context of your website
May 03 21:51:40 sdboyer - i can see valid arguments being made both ways
May 03 21:52:11 sdboyer - which is why i think we're best off with a solution where that decision is made by the admin in setting up their profile/account system
May 03 21:52:12 Michelle - True... So it needs to be admin decidable
May 03 21:52:19 sdboyer - zactamundo
May 03 21:52:46 Michelle - Ideally, I'd like to have a "wizard" install for this because people already think advprofile is too hard to set up
May 03 21:52:55 sdboyer - yeah, i'm 200% with you on that
May 03 21:53:05 sdboyer - i had plenty of trouble with it the first time around
May 03 21:53:18 Michelle - Given how smart you are, that's scary...
May 03 21:53:20 sdboyer - not your fault, just a whole bunch of crap getting woven together
May 03 21:53:29 Michelle - I've done my best to simplify it but, yeah, there's a lot to it
May 03 21:53:36 sdboyer - yep, there's really just no way around it
May 03 21:53:39 Michelle - I changed the name to "kit" to try and get that across
May 03 21:53:50 sdboyer - i was trying to remember if that was there before or not
May 03 21:53:53 sdboyer - good call
May 03 21:54:03 sdboyer - but...hopefully
May 03 21:54:09 sdboyer - if we can sort out this more basic infrastructure question
May 03 21:54:18 sdboyer - then a LOT of this other stuff will fall into place
May 03 21:54:58 sdboyer - i really am convinced that part of the reason these discussions go around and around in circles is b/c there's no widely understood delineation between what constitutes a profile and what constitutes an account page
May 03 21:55:21 Michelle - I just hope this doesn't get too beyond my skills... So far, advprofile is rather simple as far as coding goes. It's mostly panels exports
May 03 21:55:32 Michelle - Yeah, that is a difficulty
May 03 21:56:23 sdboyer - which is why i also think that creating that distinction programmatically, and doing it in a way that explicitly highlights it being a subjective thing, will not only be good for individual folks tryin to make all this work, but also for that whole discussion
May 03 21:56:46 sdboyer - yeah, there is a lot to all this, i'm certainly not saying you should take it all on on your own :)
May 03 21:57:01 sdboyer - in my mind, there are a couple discrete parts:
May 03 21:57:27 Michelle - You're welcome to be a co-maintainer... Though you may confuse the hell out of me if you commit something since I really suck at cvs
May 03 21:58:33 sdboyer - i'd love to :) though i should hold off for at least a little while, probably until i get panels to rc
May 03 21:58:51 sdboyer - with some of this stuff, i'm effectively doing work that'd need to be done for this anywya
May 03 21:59:02 sdboyer - anyhoo, discrete steps:
May 03 21:59:03 Michelle - Well, this is all pretty long term planning, anyway
May 03 21:59:14 sdboyer - 1. the system for handling what is strictly 'profile' content, significant parts of which can be drawn from the og_panels & og_blueprints approach
May 03 21:59:29 sdboyer - though, to be certain, not all can be drawn from there
May 03 21:59:41 sdboyer - actually...hmm
May 03 21:59:46 sdboyer - i'm liking this
May 03 22:00:05 sdboyer - here's a basic reality: there will ALWAYS be some kind of account page
May 03 22:00:12 sdboyer - somewhere that the user can, at minimum, change their password and email address
May 03 22:00:23 Michelle - Yes, definitely for basic settings
May 03 22:00:26 sdboyer - right
May 03 22:00:38 sdboyer - which means we're assured that we're absolutely always gonna have that one
May 03 22:00:39 Michelle - My original plan was to merge that but I've since realized htat makes no sense
May 03 22:01:18 sdboyer - which means that the thing we should start with is the account panels_page/display/thingamabobber
May 03 22:01:25 sdboyer - b/c we know it'll always be there
May 03 22:01:48 sdboyer - for rendering speed purposes, we can probably even just have that operate out of straight code by default, then switch to the db if customizations are needed
May 03 22:02:05 sdboyer - but basically, what we're talking about there is...CONTEXT!
May 03 22:02:48 Michelle - Heh
May 03 22:02:52 sdboyer - the essential choice that we present to admins is whether a given user-related content_type should be given an 'account' context or a 'profile' context
May 03 22:03:31 sdboyer - sorry, at this point my brain's spinning and i'm just spouting ideas left and right
May 03 22:04:31 sdboyer - those that're given the account context will be added somewhere to the account display, and that's something only admins control
May 03 22:04:34 Michelle - No problem :)
May 03 22:04:58 sdboyer - whereas things are a bunch more wide open for the content_type with profile contexts
May 03 22:05:05 Michelle - I'm glad to have you on this, even if I have to wait. I think advprofile will be much better with your help:)
May 03 22:05:25 sdboyer - i hope so :)
May 03 22:05:42 sdboyer - from there...there's a subcategorization in the context
May 03 22:06:00 sdboyer - either it's a 'strict' profile item, one that's at least somewhat editable by the user
May 03 22:06:03 Michelle - I wonder if we should attempt this in D5 or wait until D6? What do you think about that?
May 03 22:06:15 sdboyer - two things come to mind with that
May 03 22:06:43 sdboyer - one is that by the time i think the moons have really aligned on this, there's going to be a lot more work going on in d6
May 03 22:07:20 sdboyer - plus there's existing work towards a unified model for users already happening in d6
May 03 22:07:32 sdboyer - but, i think that most of what we're talking about here is fundamentally core-version independent
May 03 22:07:39 Michelle - Yeah, the whole panels/mysite thing factors into this
May 03 22:07:40 sdboyer - or at least 5 v 6 independent
May 03 22:07:43 sdboyer - for sure
May 03 22:07:46 sdboyer - ahh yeah
May 03 22:07:48 sdboyer - for suuuure
May 03 22:08:03 sdboyer - RIGHT, that's the other thing that an account is
May 03 22:08:09 Michelle - I'm thinking waiting for D6 on this would be best.
May 03 22:08:14 sdboyer - it's a dashboard for the user
May 03 22:08:16 Michelle - advprofile 2.x ;)
May 03 22:08:27 sdboyer - sounds oh-so-sweet :)
May 03 22:08:38 sdboyer - my thinking, at least when it comes to how my own time is gonna work on this
May 03 22:09:03 sdboyer - is that there are some big pieces that are core version independent, and i'm probably going to want to work on them as the other stuff i'm doing coincides with it
May 03 22:09:05 Michelle - I'll probably do a straight port of whatever I have when panels D6 is ready just to keep people happy for a while and then switch gears and do the "vision"
May 03 22:09:12 sdboyer - for sure
May 03 22:09:53 Michelle - Whatever you would like to work on helps :)
May 03 22:09:57 sdboyer - b/c honestly, i think a lot of this is going to be about getting our minds around this clearer way of thinking about the differences between these types of user areas
May 03 22:10:06 sdboyer - ahh phone, sec
May 03 22:10:41 sdboyer - ok
May 03 22:10:45 sdboyer - so yeah
May 03 22:10:51 sdboyer - ahh right, i was trying to make a discrete list
May 03 22:11:53 sdboyer - 2. creating an API, probably one largely based on an extension of panels, that enables other module developers to EASILY plug in to either the 'account' or the 'profile' end of the system
May 03 22:12:47 Michelle - That woudl be awesome
May 03 22:13:03 sdboyer - 3. being at least a little pro-active about where & how the data for users is getting stored, b/c i can see that turning into a hellish performance nightmare if there isn't some forethought
May 03 22:13:51 Michelle - Hmm... 3 might be hard. I like keeping it agnostic as far as bio/nodeprofile/content profile/core profile/whatever
May 03 22:14:05 sdboyer - yeah, you're probably right
May 03 22:14:12 sdboyer - i don't even know exactly what i'm thinking of when i say that
May 03 22:15:05 sdboyer - i've just got this picture of potentially complex combinations resulting in snarled runs of nasty, hairy queries that could've been easily made more unified by some structure at the outset
May 03 22:15:24 sdboyer - but really, that'll take time no matter how we slice it
May 03 22:15:48 Michelle - Heh
May 03 22:16:00 sdboyer - coming in with a new API and saying that everyone oughtta use it - "so rewrite all your data structures right now, guys!" would TOTALLY meet with a great response
May 03 22:16:08 Michelle - Panels lets you make really complex things easily. I found that out when my front page started going - 30 seconds
May 03 22:16:14 Michelle - LOL
May 03 22:16:21 sdboyer - yep, it sure does
May 03 22:16:39 sdboyer - which is why the need to work out a better caching system is going to get really big, really soon
May 03 22:17:15 sdboyer - all in all, though
May 03 22:17:18 sdboyer - maybe i'm delusional, but
May 03 22:17:21 Michelle - Yeah, definitely. Especially one that doesn't turn styles off for anon.
strong - === We broke for the night. Then, in the morning... ===/strong -
May 04 08:35:59 Michelle - sdboyer - One thing we didn't touch on is the notion of public profile vs "home page". That's a distinction I plan on having on my site. Users will have a "public face" which is currently done via advprofile and a customizable "home page" which gathers information useful to them as a landing page for my site. This is the realm MySite covers.
May 04 08:36:22 Michelle - So there is the question of whether these are both integrated into one package or remain seperate projects
May 04 08:36:40 Michelle - I actually can't stay and chat now but wanted to get that in your backscroll before I leave
May 04 08:36:44 Michelle - I'll be back in a few hours.
May 04 08:38:07 sdboyer - yeah, that's the realization that i started to have as it regards MySite, but that's the better way to put it, the user 'home page'
May 04 08:38:33 sdboyer - my first inclination is to say that we're probably safe collapsing the idea of the 'account' together with the 'home page'
May 04 08:39:03 sdboyer - because the real distinction that we're making here, imo, is between who this content is supposed to be facing - just the user, or the public
May 04 08:40:27 sdboyer - i imagine there'll be quibbling over terms with these things, but i think that if we're splitting the classification that way - information that's public-facing vs. information that's private-facing, and we build our two panel 'spaces' accordingly, then we'll be good
May 04 08:41:25 sdboyer - all we have to hard-code is that there are two panel-spaces per user, one private and one public, and then the admins choose which content goes into each
May 04 08:42:07 sdboyer - ahh, didn't see that you said 'landing page' at first, i think that's another good & often accurate way of thinking about the private space
May 04 08:59:39 Michelle - sdboyer - Actually back for a bit while I wait for hubby to get ready
May 04 08:59:57 Michelle - The only quibble I have with that is that MySite has an option to make your home page public
May 04 09:00:11 Michelle - So you can share your landing page with others... Do we keep that? Do people use that?
May 04 09:00:19 Michelle - That's a question that needs to be answered
May 04 09:00:34 Michelle - I, personally, would be fine with dropping it but MySite isn't my baby
May 04 09:08:56 sdboyer - right
May 04 09:09:01 sdboyer - and that is another question
May 04 09:09:18 sdboyer - i think there are two ways of answering it, both of which ought not be too difficult
May 04 09:09:51 Michelle - Two ways? Yes and No? :)
May 04 09:10:07 sdboyer - ;)
May 04 09:10:15 sdboyer - 1) we allow a 'peek'-style functionality wherein user/2 can grant, say, user/3 permission to view their landing page
May 04 09:10:50 sdboyer - and 2), we allow an 'export/copy'-style functionality wherein user/3 can, if properly permissioned, duplicate user/2's landing page onto his/her own landing page in whole or in part
May 04 09:11:06 Michelle - Oooh, that's a nifty idea
May 04 09:11:25 Michelle - For permissions, I favor the all/useronly/buddies model
May 04 09:11:26 sdboyer - i think that adequately covers it?
May 04 09:11:30 Michelle - Same as for the publich profile
May 04 09:11:44 Michelle - Granting specific UIDs sounds complicated
May 04 09:12:03 sdboyer - yeah, could well be, but at the same time
May 04 09:12:04 sdboyer - well
May 04 09:12:09 sdboyer - maybe we think of that part as an api
May 04 09:12:22 sdboyer - all buddies is really doing is selecting a group of uids
May 04 09:12:25 sdboyer - it just presents a ui for it
May 04 09:12:28 Michelle - True
May 04 09:12:34 sdboyer - but the case of the project maintainer stuff that merlin and i are pushing for right now
May 04 09:12:39 sdboyer - so we can assign issues to each other in panels
May 04 09:12:39 Michelle - UR complicates things, too
May 04 09:12:46 Michelle - So making that a generic api would help
May 04 09:12:50 sdboyer - zactly
May 04 09:13:01 sdboyer - and really, that shouldn't be hard to do at all
May 04 09:13:16 sdboyer - and i think could qualify as one of those 'having some foresight about organizing data' things :)
May 04 09:13:28 Michelle - Yeah, we definitely need to nail this down before coding
May 04 09:13:39 Michelle - This isn't a coding by the seat of your pants module
May 04 09:14:13 Michelle - I think hubby is just about ready to go so I only have a minuite or two
May 04 09:14:45 Michelle - Need to get merlinofchaos and Ken pulled in on this, too
Comments
Just a note - if things do
Just a note - if things do indeed end up going this way, then it's going to mean folks having to implement the Panels API, at least to some extent, in their own modules. Fortunately, we've finally gotten around to actually doing some really proper documentation of the API, so it's a little less like jumping straight into the deep end. The most current version of the Panels2 API documentation is available online, and is updated daily with the most recent changes in -dev. There are still big holes in the documentation, but I've done my best to cover the most essential API functions in considerable detail.
Privacy
Quick note: IMO, Panels should implement a , resp. , only. Just like node_access and/or CCK field privacy, the actual implementation of whether a pane might be accessible to a user should be left to other contrib modules.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Indeed - and it's in the works
I'm in full, or at least nearly full, agreement on this point. In Panels2 beta3, the only thing that really touches on pane visibility is the rather clunky roles interface, which is something we're intent on improving. First off, simply because it's related and the question is likely to be sparked - beta4 will add a new feature where a pane can be 'hidden' via a toggle button on the pane config (right next to the Caching, Pane Configuration, and Delete Pane buttons). Hiding panes in such a way isn't just an aesthetic trick - the pane won't be loaded from the db during the rendering process, so from a performance & security perspective, the pane simply isn't there. But that's a sledgehammer in comparison to the type of fine-tuning you're talking about; I just wanted to get it out of the way.
There are some different levels at we can implement this, but the most basic consists of an addition to the panels API that's sitting half-written in my local sandbox right now: I'm expanding the set of callbacks that can be defined by panels content_types to include a visibility callback. As with any other panels content type definition, it's entirely up to the defining module to decide what that callback points to and, therefore, the way that pane visibility works for any panes of that type. http://drupal.org/node/256471 is the issue I'm using to track this particular branch of panels expansion, and it contains an example of a similar sort of visibility callback that I wrote for og_panels.
That works well enough for most panels use cases, I think, but I also think that it's likely to prove clunky and inadequate in pretty short order with this panels_user* stuff since the whole idea is to provide a unifying framework. In particular, it seems to me that most content types for profiles ought to be able to have their visibility controlled at least (and - perhaps - first and foremost) by whether or not the current $user is on the profile owner's buddy list. If that's something that ought to apply to all profile panes, then it ought to be taken care of internally in the API. However, I can think of no shortage of use cases where buddy list membership isn't the only relevant factor to visibility - so how do we handle ANDing those conditions together? I don't think we need to end up in a situation that's as challenging as, say, the ongoing discussions about node_access, but it is a question we'll have to answer soon. My hope is that we'll be able to work something out in the API of this effort that makes these things play nice, while still being flexible.
Just to update - the Panels
Just to update - the Panels API now (or will, as of beta4) fully supports 'visibility' definitions per content type that amount to the same thing as what you're talking about here. Content types can now define arbitrary logic to govern a pane's visibility, and add form widgets to the pane config form that provide the relevant data for specific instances of that pane. See the link in my previous post for a slightly less insufferably abstract explanation.
Status?
What's the status on this? Is this module going to be available soon? I'm using Drupal 5. Will it work for it?
.
Won't be any time soon. sdboyer has been far too busy. At this point, I suspect if it happens it will happen on D6 but that's up to sdboyer.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Sobbing Uncontrollably
So, currently, there's no implemented method for having customizable profiles ala mysite, especially with D5?
I may take a look at this some over the holidays, if you can point me in the right direction some. I'm a programmer, just not great at php. The first thing I'd be looking to do is have something akin to a nodeprofile_panels. I'm thinking I'd have to follow the model of og_panels. Does that sound correct to you?
It's up to Sam
No, there currently is no module for this, which is why we are going to do it. For a direction, see http://blog.samboyer.org/content/user-panels-proposal
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
Thanks, Michelle. There are
Thanks, Michelle.
There are a number of things that're up in the air with this right now because of all the flux that Panels is currently in. I'd say that you'd probably be best served to wait this one out, unfortunately - at this point, I'm not even sure exactly how I'm going to approach implementing this. There are just too many things that need sorting out, first.