Similar things were discussed already and I still think a separate view isn't needed, especially not because it means changing where a "single tag" should be routed to. Today it goes to com_tags and not com_content.
Other PRs for reference: #10346 & #10242

Just as a reminder: The com_content category list view already allows to filter by tags since 3.6.0. Relevant PR is #8846.
If you want the same for the blog layout, all you need is passing the filter_tag argument to the URL or in the menu item (see staging...Bakual:AddTagFilterToBlog for what it would need). This can be done with a simple alternate menu item. No code changes needed.

Indeed, similar things were already discussed and I still think a tag view is badly needed.
PRs #10346 & #10242 are interesting but don't do the job expected as a multicategories feature.
There is no other option but to use com_content to achieve this aim.

Tags aren't a "multicategory" feature. They are a "cross-extension" feature. If you're going to create a tag view, you take that cross-extension feature away. And in the end you still only filter the articles by tags which is what is already possible.

Tags aren't a "multicategory" feature.

I know but the result is quite similar and even more flexible.

And in the end you still only filter the articles by tags which is what is already possible.

May be but currently you cannot order articles by tags as you would by categories. This possibility
is available in the tag view option.

May be but currently you cannot order articles by tags as you would by categories. This possibility
is available in the tag view option.

I don't understand that. You want to sort the articles by tag? If so, that could be easily added to the eixtsing views as well. Just add the necessary code to the articles model. No need for an own view as well.
We really don't want to add a tag view to com_content (and each other extension supporting tags). It would be mostly a duplicate of the existing category view and it would be a nightmare when it comes to routing. Eg should a single tag link go to com_content tag view (removing cross-extension functionality) or com_tags (making the tag view useless)?

Edit: I see now what you mean with the ordering and I don't think I like that part. I think it's very complex code and where do we stop? Next guy wants to add ordering by author or any other item property.

Edit: I see now what you mean with the ordering and I don't think I like that part. I think it's very complex code and where do we stop? Next guy wants to add ordering by author or any other item property.

Ordering articles by tag is justified since articles are diplayed by tag in the tag view. Joomla's users would likely be able to order articles in the way they want to.
But there is no point in ordering by author or any other item property.

should a single tag link go to com_content tag view (removing cross-extension functionality) or com_tags (making the tag view useless)?

The modification I made allows you to choose which type of tag links you want to display. You can either display "standard" tag links (ruled by com_tags) or "content" tag links (ruled by com_content).
Note: You can also display the both types of tag links but it might be confusing for the website's users.

We really don't want to add a tag view to com_content

Who is we ?
I'd really like to have other Joomla's team member opinions and compare their arguments to yours.

You need an additional mapping table to provide data that is already available (yet in an excessively convoluted way). That alone from me gets a ? because we shouldn't be duplicating data in the database

You're trying to use the core API to perform a function it wasn't designed to do. While it may work in that way, core does not promise support for that function. Tags !== multicategory.

The other arguments already made are just as valid regardless of whether it's one person's opinion.

And just speaking on a code review aspect your code appears to have reverted several language and code related changes, which makes this pull request unreviewable to me.

You need an additional mapping table to provide data that is already available

Which table are you referring to ?
If it's the #__contentitem_tag_map table I can't see how to handle item ordering as there is no ordering column and even though I added one it would be too messy to manage article ordering through this table.

You're trying to use the core API to perform a function it wasn't designed to do.

May be but my proposal is just a slight modification which allows Joomla to get a powerfull feature, and I think it worth it.

Anyway, I think is really too bad because I'm sure that plenty of Joomla's users would be deeply interested in that feature.

I'm sure that plenty of Joomla's users would be deeply interested in that feature.

That may be, but then lets to it properly without hacking and misusing an existing feature.
We should either change the current category feature to allow for multiple category assignments. That's unlikely to happen in a B/C way due to the way it currently works. But maybe someone has a good idea.

The other approach is to use tags, but then it should keep the cross-extension function and com_tags is the responsible extension for that. Imagine a blog (or list or whatever) where there are two articles, one video from a video extension and two featured items from a shop. That would be a multi-extension, multi-category view which could become quite powerful. It's what I proposed with #10242 but hasn't got much interest so I closed it.

Considering the Joomla current architecture it would be a nightmare to develop a multi-category feature.
As things stand at present the only reasonable option is using tags which do the job perfectly.
But unfortunately it seems that the way that I use tags is incorrect and it's a pity.

That would be a multi-extension, multi-category view which could become quite powerful. It's what I proposed with #10242 but hasn't got much interest so I closed it.

I can tell by my clients that people wants a multi-category and not a multi-extension feature.
They are always asking how to put the same article in several categories which always force me to install a CCK component.

@duddy67 I am with you 100% - tags was always pitched as being a
multicategory feature. The fact that it works multicomponent is irrelevant
to me

On 24 October 2016 at 18:29, Duddy67 notifications@github.com wrote:

Considering the Joomla current architecture it would be a nightmare to
develop a multi-category feature.
As things stand at present the only reasonable option is using tags which
do the job perfectly.
But unfortunately it seems that the way that I use tags is incorrect and
it's a pity.

That would be a multi-extension, multi-category view which could become
quite powerful. It's what I proposed with #10242
#10242 but hasn't got much
interest so I closed it.

I can tell by my clients that people wants a multi-category and not a
multi-extension feature.
They are always asking how to put the same article in several categories
which always force me to install a CCK component.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#12529 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8eylg1bGTuyDTFDzPcSS25vMVR2uks5q3OrngaJpZM4KeLds
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

I have tested this item ? unsuccessfully on 217492c

Used Menue Item: Tag Blog, got in Frontend
Notice: Undefined index: tag in __/Joomla/libraries/cms/component/router/rules/menu.php on line 177,
Notice: Trying to get property of non-object in __/Joomla/libraries/cms/component/router/rules/menu.php on line 177
No Article displayed.

For those who are interested I've developed a dedicated Joomla extension: ABTag

Should this be closed?

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/12529

closed as stated above.