Add path user/{uid}/content to get a listing of one user's nodes

Where is it linked from? How does it look like? How does this interact with the tracker?

Seen this: http://flickr.com/photos/factoryjoe/12517114/?

How does this differ from blog ?

In that any type of content is shown? Isn't the idea to turn blog into an extension of any node (kind of like the new events) ?

There are at least 4 formats:

1. The teaser format (titles + author + teasers)
2. The tracker format (titles + author)
3. The block format (titles only)
4. The RSS format

There are at least 3 filter mechanisms:

1. Filter by node type
2. Filter by category
3. Filter by user

So how about this format:

http://example.com/$format/$filter/

Examples:

teaser -- shows all posts in teaser-format
teaser/type/blog -- shows all blogs in teaser-format
teaser/user/<uid> -- shows all posts from user <uid>
teaser/category/<tid> -- show all posts in category <tid> in teaser-format
...
track -- show all posts in tracker-format
track/type/blog -- show all blogs in tracker-format
track/category/<tid> -- show all posts in category <tid> in tracker-format
...
rss/category/<tid> -- show all posts in category <tids> in rss format
...

or even

rss/type/blog,forum/category/1+2/user/1,10,100 

What we need:

1. A function that takes a filter URI as input, and that returns a valid SQL query
2. A function that takes a valid SQL query and a format as input, and that returns a chunk of HTML

Example usage:

1. format_nodes(query_nodes('/type/blog,forum/category/1+2/user/1,10,100'), 'rss')
2. Want to create a block with a user's last forum topics? Create a PHP block with the following snippet:
   print format_nodes(query_nodes('type/forum/user/$user->uid'), 'titles');

NOTE: we might have to refine the URL schema and the API but this would come a long way.

nice suggestion, dries ... i suggest that the best name for the 'tracker' format is 'table'.

I really like this idea. The current taxonomy URLs are already a bit like this.

Taxonomy URLs have 2 parameters though, one of which is optional. By using default values, we can take care of this at the moment, but I'm sure how this would work with the current scheme proposed by Dries.

It also fits perfectly with what I was thinking of implementing for the admin/node screen: right now the user's refining filters are stored in the session. It would be nicer if they were stored in the URL (e.g. admin/node/type/blog), that way they can be bookmarked and aliased.

whats wrong with userposts.module. i does what you want, except for the tab/localtask thing. I am willing to commit that patch though.

As Dries said "a function that takes a filter URI as input, and that returns a valid SQL query":

http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/chx/urlfilter...

It's actually two functions but I hope that's OK...

We seem to have a bit of a naming conflict here... filters for filtering text, or filters as WHERE clauses in queries.

Can someone suggest a better word for the second to avoid confusing?

"conditions"

Well the patch in #3 still applies cleanly, amazingly given its age. :-) Is that patch still being considered, though? If so, it applies cleanly but didn't seem to have any effect. If not, this should probably be refiled as active.

Userposts.module would be a very good candidate for this.

I don't think that this is needed anymore, now that we have views. Views can do what this patch does, as well as pretty much every other filtering combination suggested in this thread.

Closing.