blog/[uid] doesn't narrow to user posts

Menu definiton badly botched. Also, user_current_load contained some old code, I fixed that as well. There is no real need for the special access for this menu entry as the blog_page_user contains the necessary checks.

Tested and works as advertised. This is a re-roll that fixes a notice when viewing another user's blog, by re-working the output in blog_page_user() to run it through theme('item_list') rather than hard-coding the ul and lis.

Tested with anonym, user1 and standard user. It also corrects the bug that anonym was not allowed to view user blogs, even though access content is set for anonymous.

- Hm, the change in user_current_load() might be a bit far reaching. Where is that used?
- It is also interesting that "edit own blog" is the permission to create new blog entires?! Really? Aren't there specific permissions added with the blog node type to let blog post creation?

It would be great to clear these two questions up.

http://drupal.org/node/176759 (User-specific blogs pages and feeds not accessible) is more or less a duplicate of this issue. Don't know wich one to mark as duplicate; both have patches attached. So I just mention it; to be on the safe side. Have no time to compair the patches now, but hopefully I can do later.

the user_current is used in the my account link and this is necessary as the current code is waaaaay outdated, it's simply a remnant of early menu system code, it's before to_arg calls was introduced. blog permission redux is not in the scope of this issue.

Feeds for users are broken too. Attached the same patch as from webchick (that was working well), but now also with a working user-feed.

Leaves a menu-issue left: when someone has no 'edit own blog' permission; the 'my blog' link will still appear. Also; before if you visited your own blog-page the title was 'my blog' and now is always 'username's blog'.

But the menu items should be a separated issue; it's not about user posts.

- It is also interesting that "edit own blog" is the permission to create new blog entires?! Really? Aren't there specific permissions added with the blog node type to let blog post creation?

Nope. Those are permissions explicitly added by node.module for admin-created content types. modules that define their own content types can set their own permissions at will...

Modules that define their own content types HAVE TO set their own permissions... I tried to delete all permissions set/checked in blog.module in hope that node.module will take care of it but that's not the case (would be very nice).

Now, the 'edit own blog' permission is all or nothing at all. 'create', 'update' and 'delete' all depend on it; so 'manage own blog' would be a better name or even better; node.module should take care of that (the 'standard' permissions').

But again, this is not part of the original issue (as Chx and I told). Let's first fix the 'user-pages' and then look at menu/access issues.

the user_current is used in the my account link and this is necessary as the current code is waaaaay outdated, it's simply a remnant of early menu system code, it's before to_arg calls was introduced. blog permission redux is not in the scope of this issue.

Ok, now I see we deal with %user_current which translates to the load function. BUT now I don't see what is the difference between user_current_load() and user_load() after the patch? I looked into both and user_load() seem to return FALSE equally if the argument is not numeric or not an array, which is basically what happens here. So why do we need both?

Agreed, that permissions should be dealt with in another issue.

Leaves a menu-issue left: when someone has no 'edit own blog' permission; the 'my blog' link will still appear.

Why is this a problem? Then the page is a view page, right?

Also; before if you visited your own blog-page the title was 'my blog' and now is always 'username's blog'.

Well, because there is an explicit set title in the patch, this can be overcome by comparing $account to $user and acting on that.

Also, I noted that in the feed fix, we should write url('blog/' . $account->uid instead of url("blog/$account->uid" (see how the code does this above in the patch).

Leaves a menu-issue left: when someone has no 'edit own blog' permission; the 'my blog' link will still appear.

Why is this a problem? Then the page is a view page, right?

Yes, but it's always empty. Users who don't have 'edit own blog' permission don't have a blog, and they shouldn't have a 'my blog' menu item either.

Also; before if you visited your own blog-page the title was 'my blog' and now is always 'username's blog'.

Well, because there is an explicit set title in the patch, this can be overcome by comparing $account to $user and acting on that.

I like seeing my content in the same context that other users are seeing it. For example, I might want to print out a blog entry and give it to someone else.

Note: this is different from 'My account', which is a) not content and b) destined primarily to myself rather than to the outside.

I corrected the code-style for the feed-update; my mistake.

I agree that I prefer the 'nam's blog' title; also for my own page.

I will work on the permission/menu problems and will create a differend issue for that; leaving this just to the 'user-page' problem.

applied patch (fine with a couple lines offset), enabled blogs, posted an entry.

/blog is fine
/blog/1 narrows down and I agree "username's blog" should be used whoever's looking at it.
/blog/1/feed also works as expected.

RTBC.

sorry, just to add it works for admin created additional user as well.

Thanks for the patch and for the tests, committed.

Is their a patched blog for 5.X? Where can we get it?

Thanks
GreenJelly