Tracker: Add menu item that takes you to 'my recent posts'

Yay!! :D
Thanks webchick! Will give it a try asap.

instead of adding tracker/user, why not just make that the path for the "My recent posts" tab, but still support arbitrary uids in there? would this work? i don't know how to get both subtabs to appear directly in the navigation menu in D6, and menu.module doesn't really exist yet for D6, either.

FYI: with killes's blessings, i just applied the D5 backport on d.o and finally fixed http://drupal.org/node/107934).

#6 is indeed RTBC for D6.

note: our patch breaks no links. everyone's old bookmark to tracker/[uid] will still work, since $target can be an arbitrary uid. it just won't call that the "My recent posts" tab, it'll think it's "All recent posts" for some other user. big deal.

This is a bit of a universal problem. The "my account" menu suffers from similar problems -- it's hard to move it around.

So, this looks like a universal problem to me that needs a universal solution.

It's almost as if the mapping from %user_current to the $user's uid happens at the wrong time. It shouldn't happen when the menu is generated and send to the client, it should happen when the page is requested, and the callback is resolved and called.

Of course, it's easy tos ay and write this -- but it might actually be hard to implement. Either way, I'm just thinking up loud, hoping to spark ideas for a more generic solution. It would be super-useful, I think.

interesting point. the trick we play in this patch to handle $target appropriately could be built into the menu system. it's true that both tracker and My account could benefit.

however, here's a counter-example: the current "My projects" link. the existing menu item is:

http://drupal.org/project/user

however, it also supports:

http://drupal.org/project/user/46549
http://drupal.org/project/user/dww

if we made the default "my projects" item really be this:

http://drupal.org/project/user/user

we'd conflict with a user named 'user'. :(

granted, the existing project menu item isn't necessarily the most sane approach, but it seems like we can't just apply the same technique to all menu items that want to know the uid of the current user. i think we'd need 2 different menu path tokens, one for the uid of the current user as a literal in the URL, and another for this cool 'user' keyword in the URL that maps to the current user's uid before being passed in as a menu callback argument...

however, i feel like there are so many important menu-related patches still in the queue and that menu API is still in flux, i wouldn't want to complicate or delay those with this particular feature request. that said, i'll try to get chx and/or pwolain's input on this in the near future, and see what they think.

personally, i'd rather see this patch go in now, and if we change menu API to add the cool new token, we can always port this functionality to use that when/if it exists, but that's just me feeling the heat of the freeze fast approaching. ;)

I do not understand what #6 solves when that's a MENU_LOCAL_TASK still. And, as my account shows, it's quite trivial to create dynamic menu items. Actually. If you just remove MENU_LOCAL_TASK from the menu definiton in six, you'll get a normal menu item.

@chx: maybe we're just confused since menu.module doesn't exist in D6. but, in D5, you can't define your own menu items that point to dynamic paths. so, you can't say: 'My recent posts' = /tracker/%user_current. you can only say stuff like 'My recent posts' = /tracker/user. what #6 solves is that the regular tab stuff still works fine on /tracker, but you can also define your own navigation menu item that points to /tracker/user, and under the covers, that works like %user_current. see this in action on d.o right now in the navigation menu.

the non-existance of menu.module is what needs work, IMHO, not this patch.

that said, i like Dries's idea of some way to say:

put "user" in the URL for the menu item, but treat that like %user_current before it actually gets to the menu callback...

that's what i was hoping to get your input on... ;)

non existence of menu.module? Stay tuned!

i eagerly await! ;) however, it doesn't really change anything about the need for this patch, or the discussion about this magic path URL token that gets automatically remapped on the fly.

Any chance of a 5.2 release with this in it?

@Jax: please note the category of this issue: "feature". therefore, it's not going to be officially released for D5, which is a stable version that's only accepting bug fixes. in a matter of days, this might not even make it into D6, unless we can get some more thoughtful reviews and support for this, so it will be committed.

the "My recent posts" item was in the menu for quite some time, but it seems to have disappeared again??

This'd be great on drupal.org

Also unrelated I think tracker/1 has disappeared as a tab in D6??

But it doesn't apply.

here's an updated patch.

Still a good idea. No longer applies (again).

agree

Well, what appears to work for me in D6.4 is to create a new menu entry with path "tracker/%" and title "My content" in the Navigation menu. The % is substituted with the user id in the menu system prior to invoking the tracker panel, and gives a one-click result.

It took me a while to figure this out, so I hope this is useful to someone. Feel free to advise an alternative if this approach isn't legitimate.

Fundamental usability issue. Something to look at in Szeged.

There's one minor snag with my solution in #24. It turns out that tracker code & SQL will only locate and display published content (node->status == 1). However, my preferred interpretation of a "My content" link would include unpublished content as the whole point is to make things easier for the user developing their posts at varying stages of completion. Whereas of course for "All recent content" then only published content should be included.

This issue is well explored from another angle in another thread: http://drupal.org/node/10611?mode=2&sort=2

What happened to this? I still think this would be a great idea to implement on drupal.org.

Still a nice and sensible feature. IF tracker stays around of course :)

This extension is deprecated and scheduled for removal in Drupal 11.

This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

It will be moved to the contributed extension once the Drupal 11 branch is open.