Posted by a_c_m on November 2, 2007 at 11:46am
| Project: | MySite |
| Version: | 5.x-2.15 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
Is it possible to have owner specific default content?
e.g. Force every mysite to have its owner users most recent blog post displayed ?
It currently doesn't work as default content has to be an explicit user or relating to the current logged in user (ie viewer), not the owner of the mysite.
I've been looking for a few hours and so far not seen a nice way to do this. I noticed for the blog and user types, the Type_ID is the UID of the user its referring to, so thats an easy enough hack to do, but for droplets it seems a lot more complicated.
Any pointers / advice / snipits?
Comments
#1
Take a look at how profile.inc is constructed. I think that is the approach that you want.
#2
When implementing something like this, remember that the arrays defined by mysite_type_hook_options() and mysite_type_hook_data() don't care where the data comes from, only the format its returned in.
Also note that you can likely use mysite_render() to populate the hook_data() piece, and you can store string keys (non-integer keys) in the {mysite_content} db using mysite_get_myid().
What I'm saying is that you could define a my.inc content include that creates its own rules for pulling back content.
With blog.inc, say, the options and data are generally taken from standard keys:
type id---- --
blog 1
blog 2
In this case, id == UID.
Now in your case, you can use mysite_content and mysite_get_myid() to create:
type id---- --
my blog
my posts
my comments
my friends
mysite_get_myid() will turn those string ids into numeric keys for insertion into the {mysite_data} table automatically. In your _hook_options() function, you would cycle through those options: 'blog', 'posts', 'comments', 'friends.'
Then in the _hook_data(), you might have functions designed to return the correct data for each type. In the case of blogs, posts, and comments, you can simply use mysite_render() to return the data currently provided by the core module.
Does any of this make sense?
#3
I think it makes sense :)
But (as usual) i didnt do it that way, i was in a bit of a rush and instead of creating my own content type, i just hacked the existing droplet.inc .
I have attached a patch for what i did, again, its probably not the best way to do it (as it requires another SQL call which i expect can be avoided) but in a nutshell, i modified the views_build_view() call to pass the UID of the owner user as the first argument, so the view can be used to select on that UID.
Which allows you to use regular view/block for owner based content.
What do you think ?
#4
I suspect that might be a smart patch. I still haven't played with view too much.
You should, of course, simply be able to use:
<?php$uid = arg(1);
$args[] = $uid;
?>
This works since mysite's menu path is 'mysite/UID'. No queries needed. Though 'admin' is a valid arg here, so it may need to be:
<?php$uid = arg(1);
if ($uid == 'admin') {
$uid = 0;
}
$args[] = $uid;
?>
But UID 0 is likely not what you want here, so probably $uid = 1, like you have it now.
#5
Cool!
Will that arg(1) still work when you have things like auto-path working? as then its /mysite/username
#6
Yes, since arg() is an internal function that reads the "real" $_GET['q'] string, not the aliased path.
It may be that the arg code belongs in the View, not the MySite code.
#7
#8
Subscribing, greetings, Martijn
#9