... it is probably a mistake to use "adminForm" as the name and HTML id of the form used for filtering

@smz

Being able to apply front-end filtering to "Category Blog" (and possibly other views) doesn't seems to be a bad idea, after all.

Not a bad option for site visitors but not for site admin. There is no way a site admin can create a menu item that displays Articles (of the same Tag) in a Blog format.

This allows to filter based on "tags" too, which is what was requested/proposed by the OP in the Google Group discusssion

That was not what was discussed. What was discuss was to present a Blog page that displayed Articles of the same Tag(s) ... not to display a Category blog page that the visitor filters. It is a good addition but not a solution for the discussion on https://groups.google.com/forum/#!msg/joomla-dev-cms/YVwuuNYHFUQ/hHs7_kaFAgAJ

I definitely agree with Kevin. This is NOT what was discussed in the first place.
It's an interesting option but to much limited compare to the Tag view feature.
There is no control on the item ordering, no way to create a tag layout menu item and you don't have the flexibility you would with a component of your own.

@Webdongle & @Duddy67
Guys, I'm totally with you! This is just a "proof of concept" PR I put up in five minutes after struggling for days trying to do "the right stuff" implementing a native "Tagged Items Blog" view, a task I'm simply not up to...

As I said in #7020, the main objective is:
"contributing to raise the awareness about how much needed this is"

@Duddy67
Actually there is items ordering with this PR (set in the back-end), but again, I admit this is not what we all were asking for.

A separate component is not needed at all, and actually I think it would be a bad idea: what we need is a separate view within com_content...

Add a tag selector parameter to the blog.xml in the request section (same place as the category filter parameter) with the same name as the filter(filter_tag) and you have your view.
At least in theory it should work.

If that works and similar can be done with 'Featured' then that would do it. It would negate the need have an extra view in either com_tags or com_users. And conforms to the KISS principle

@Bakual

We will still be missing routing, something like: &view=tag&id[0]=2&id[1]=3 as we have in com_tags.

See staging...Bakual:AddTagFilterToBlog for what I mean. I just tested it and it works without any other modifications.
Basically it's something which is now possible to do with a simple alternate menu type (layout override) on template level. It doesn't necessary has to be included in core.

... It doesn't necessary has to be included in core.

beside the fact this is one of most useful and most asked for missing feature!

... sorry, I have to go: will review later tonight. Thanks to all!

We will still be missing routing, something like: &view=tag&id[0]=2&id[1]=3 as we have in com_tags.

Don't mess with routing please. A single tag should always go to com_tags. If you're starting to route tag links from that blog view to com_content, then you will end up in devils kitchen very fast.

... you will end up in devils kitchen very fast.

That's exactly where I've been in the last few days!!

@Bakual Yes, that works!

And we also have routing: http://j36.dev/index.php?option=com_content&view=category&layout=tagged&id=8&filter_tag=2&Itemid=106&lang=en

Still missing:

• "category agnostic" view
• multiple tags

... but I think we are on a good road now!

I'm thinking about basing the new "tagged items" layout on the categories view instead of category...

Still missing:

• "category agnostic" view
• multiple tags

You don't need a category agnostic view. Just set up your categories so they all have the same root category, and then set that root category as the filter in your menu item. Also set the parameter "Include Subcategories" to "All" and you have a list of items from all categories. No special code needed.

Multiple tags would be possible, but would make the code more complex. You would have to deal with an array of tag ids and sanitise this array to integer before using. It gets even worse if you want to also support a coma separated list of tag ids. Just have a look at the single tag view from com_tags which supports those kind of stuff.

I'm thinking about basing the new "tagged items" layout on the categories view instead of category...

The categories view only shows a list of categories. No items at all.

@smz

"I'm thinking about basing the new "tagged items" layout on the categories view instead of category.."

Category Blog and Featured menu item edit screens being able to select Tags will be (imho) more preferable than in an All Categories list

I can understand the category view, but why the featured view? You already have kind of a tag (the feature label) there to filter what articles to show.

Yeah ... on second thoughts Featured filtered by Tags would not provide what was being discussed.

Featured Blog view ... displays Articles in Blog format based on featured Articles in all selected categories
Category Blog view ... displays Articles in Blog format based on a category
Categories List view ... displays a list of Articles in all selected categories

What we need is
Tags Blog view ... displays Articles in Blog format based on selected tags in all selected categories

Creating a new view in com_content rather than altering an existing view is surely the most logical way to achieve the desired outcome.

@Webdongle

Kevin, to further clarify, my idea is not to have a list of articles selected by tag (for that we already have the right view in com_tags), but a full featured blog view, and my idea (nothing more than that, just an idea...) is that we probably could hybridize the categories model and view with the category blog layout, (and of course add the tags filtering) and achieve what was requested in the first place.

I haven't looked yet if this is feasible at all.

@Bakual

You don't need a category agnostic view. Just set up your categories so they all have the same root category, and then set that root category as the filter in your menu item. Also set the parameter "Include Subcategories" to "All" and you have a list of items from all categories. No special code needed.

Yes, that's feasible and I already gave you my to the idea in the mailing list, but:

• this cannot be applied to an already existing site for which the categories tree has not been designed with that in mind "ab initio".
• it is a little bit hackish
• have side effects on SEF URLs

@smz

"but a full featured blog view, and my idea (nothing more than that, just an idea...) is that we probably could hybridize the categories model and view with the category blog template, (and of course add the tags filtering) and achieve what was requested in the first place."

I understand what you are saying .. but imho altering an existing view to make it act in a different way is not a good approach to achieve an affect that is different in nature. Category Blog differs because it is by definition only one category. Being able to have an extra option to display only related tags of the category is good ... but altering it to act on all categories is illogical captain.

It will be a different "view", the same way "Category Blog" and "Category List" are two views sharing the same model/view...

@Bakual

"You don't need a category agnostic view. Just set up your categories so they all have the same root category, and then set that root category as the filter in your menu item. Also set the parameter "Include Subcategories" to "All" and you have a list of items from all categories".

If that is done with Categories view then you just have a List view not a Blog view ... unless you alter the nature of Category list and change it to Blog.

If that is done on Category Blog view then it limits the ability to match root categories with root menu items. Many users like to have the menu structure match the category structure.

Again the most effective way to have a Blog view that displays Articles for all Categories selected by Tags is to create a new view in com_content

this cannot be applied to an already existing site for which the categories tree has not been designed with that in mind "ab initio".

Of course it can be applied to any existing site. Just create the category and assign the existing categories tree to the new created parent. No issues and all will continue to work as expected.

it is a little bit hackish

Nothing is lacking at all. In fact it follows the "Joomla way" properly.

have side effects on SEF URLs

Not really. Usually you have a menu item pointing to a category already, then nothing changes in the URL since you don't change anything "below" but only "above" it (which is "hidden" in the menu item alias).

It will be a different "view", the same way "Category Blog" and "Category List" are two views sharing the same model/view...

It's only one view, but two layouts. Please don't use the term "view" to describe a "layout".

It's only one view, but two layouts. Please don't use the term "view" to describe a "layout".

yeap, I stand corrected! But probably even better would be using "Menu Item Type", which conveys the idea of different options too and not just a different way to represent things.

@Bakual

Of course it can be applied to any existing site. Just create the category and assign the existing categories tree to the new created parent. No issues and all will continue to work as expected

Cart before the horse. Creating any content (including a Category tree) to match a menu/menu item is backward. Menus/menu items should be created to match the content (including a Category tree).

A new view in com_content would give the desired result without altering the 'nature' of existing views.

A new view in com_content would give the desired result without altering the 'nature' of existing views.

From an architectural point of view it is not a new "view" what we need but a new "Menu Item Type":

• the "Categories" view/model returns items from a category (root category included) and its children
• the "Category" view/model returns items from a category (root category excluded) and its children

On the basis of this two model/views it is conceivable to build very different Menu Items for very different purposes. We are already doing that.

I think it would be even possible to merge the two models/view without loosing functionality.

All other views (archive, article, featured) could probably be merged too. It would be a matter of applying the right filtering.

But I'm drifting, now... sorry about that.

sigh All you need is that filter as I've shown already.

I would be very opposed to creating a new view for that (architectural disaster) or a new layout/menu item type (duplicating the blog layout).

Cart before the horse. Creating any content (including a Category tree) to match a menu/menu item is backward. Menus/menu items should be created to match the content (including a Category tree).

Nah. Categories are there to organise the articles. If you have a new requirement for your organisation (eg want to show items from all categories) then you need to adjust your organisation. Nothing wrong with that and it has nothing to do with menu items by itself.

All other views (archive, article, featured) could probably be merged too. It would be a matter of applying the right filtering.

You can't merge the article view because it's a completely different dataset (one single object vs a list of objects). You could indeed merge the archive view since it's technically just a different state for the list view, but that's something for J4. The featured is a bit special, but could very likely be merged as well into the list view, however it could maybe make that view to complex.

You can't merge the article view because it's a completely different dataset

I beg to differ: same dataset filtered on id...

Edit: a set can have 0, 1, or "n" members...

In our case, a list view of one article and a single article view is something completely different both in how it displays and how it is routed. Don't try to merge those

Don't try to merge those

I sincerely hope J4 will!

Edit: "how it displays" is irrelevant: layout stuff. Routing... hmmm... I don't know... doesn't category is always part of our routing?

I sincerely hope J4 will!

I'm quite sure it doesn't. It would be a horrible decision.

Try this ... the zip file has the folders/files placed so they should unzip in the correct place. I used a lot of code from fjrelated so the language constants will need altering and the files tidied up. But is shows POC for a view in com_content

tagviewpoc.zip

@Webdongle OK... give me some minutes...

@Webdongle Doesn't seems to work, Kevin...
Beside the fact that many back-end strings are missing, I'm getting this:

Notice: Trying to get property of non-object in D:\UniServerZ\vhosts\j36\components\com_content\views\tagsview\view.html.php on line 93

Warning: Invalid argument supplied for foreach() in D:\UniServerZ\vhosts\j36\components\com_content\views\tagsview\view.html.php on line 136

Error on line 136 is particularly alarming as it means we have no "items" there....

I really don't think you can have a "view" without a "model" and I don't see any model for your view in your code...

What is it "fjrelated"?

Code updated with "the best we can get at the moment..."

Some strings missing.

Reverted the front-end filters: nice, but not what we want here.

@smz

Sorry forgot to add a file. Try this

tagviewpoc_v2.zip

Notice: Undefined property: stdClass::$category_title in D:\UniServerZ\vhosts\j36\layouts\joomla\content\info_block\category.php on line 14

... but much better!

What is it "fjrelated", Kevin?

It is a view from the http://extensions.joomla.org/extensions/extension/structure-a-navigation/multi-categorization/fj-related-articles-blog-and-list-component component. I just changed the names in the files to match the name of the view/folder

It needs adjusting but it shows POC. With sample data installed ... select a few Articles and 'Batch' add tag 'Red' ... select te Tag 'Red' in the menu item and view from front end.

It can act as a good Template methinks ? Just a few adjustments but basically everything is there for selecting from all categories based on tags.

Thanks for the info, Kevin! Wow, a Mark Dexter's extension!

BTW:

• my "hybridization" trial hasn't been possible because #8846 hasn't ported the tag filter to the categories view (only to "category")
• I've tried to add show_root="true" to the category field in the category view, but faced other issues (the category view isn't really able to deal with the root category ATM)
• I'm really inclined to throw the towel, stop fighting uphill and find myself something more enjoyable and productive to do...

@smz

"Wow, a Mark Dexter's extension!"

Yes I helped helped test for bugs in his original. If memory serves me correct the original (pre tags version) was more or less a copy of the com_content with the Featured/Category Blog and Category List views selecting the Articles(to be displayed) by their tags. With the added option to define the tags by using the tags of a selected Article.

It shouldn't be too difficult to either remove that extra feature from the options ... or add the variables that make it work. Once it is working the change the language constants and add them to the Joomla language files.

I have the time to work on it but I don't have the concentration span to spend large chunks of time learning to understand what changes should be made. If I was in a classroom environment then I would only have to concentrate on doing it ... however working out what has to be done at this level is very taxing.

I'm really inclined to throw the towel, stop fighting uphill and find myself something more enjoyable and productive to do...

Yep you are at a 'dead end' with that approach. Methinks an adaptation of the fjrelated views is our best shot.

Yep you are at a 'dead end' with that approach.

Well, that's not exactly what I was thinking of, but probably that too, yes.

Methinks an adaptation of the fjrelated views is our best shot.

Can't tell at this time: I just tested it and haven't looked at the code yet.

Most important thing would be to see more interest in this and some constructive help by a skilled core developer convinced this is important, preferably from within the PLT. I wouldn't hold my breath, thus.

Your derogatory comment probably explains everything

?? Sorry ?? Derogatory against whom?

ah.. maybe I understand what you mean!

when I talked about a missing "skilled core developer convinced this is important" I didn't at all imply that @Bakual isn't a skilled core developer: what I meant to say is that he is not convinced about the need of this, which is something he himself stated!!

I'm not going to do the PR myself because it's not something I want to pursue, but I wrote the needed code to get it work. All you would need to do is clone my branch, create the PR and write the test instructions. The code I wrote works.

Facts beside that:

• There is no need for an own layout and even less for an own view
• The categories view is the wrong approach as it isn't supposed to show any articles, only the categories tree
• Using nested categories is absolutely fine

@Bakual

"The categories view is the wrong approach as it isn't supposed to show any articles, only the categories tree"

Absolutely agree and by the same ... Category view is the wrong approach because its designed for one category(tree).

"Using nested categories is absolutely fine"

If that were true then Featured would be restricted to one Category(tree)

"I'm not going to do the PR myself because it's not something I want to pursue,"

That has been obvious from the beginning because your approach appears to be totally different. You seem to be using coding as a starting point whereas myself (an others) are starting from the desired end result. But that is fine if the feature is never created there are 3rd party extensions.

The closest current view to the desired end result is Featured ... what is required is like Featured but with Articles being selected by Tag not by featured.

Specification
1. Blog layout
2. Articles selected by Tag regardless of Category

Adding Tags option to Category view meets spec 1 but not spec 2
Adding Tags option to Categories view meets spec 2 but not spec 1
Adding Tags option to Featured view meets both specs but needs a select by featured or by tags option. That would change the nature of Featured.

Only a new view will produce the desired end result. If someone with the required skills is not prepared to do that or if someone is and does but it doesn't get merged ... then so mote it be. In either case I have gone as far as I can with this and will use an extension when I require the feature in a site.

You seem to be using coding as a starting point whereas myself (an others) are starting from the desired end result.

Obviously, because we need to fulfill your request with code. Sometimes the user will have to adapt to the possibilities that are available.

Only a new view will produce the desired end result. If someone with the required skills is not prepared to do that or if someone is and does but it doesn't get merged ... then so mote it be. In either case I have gone as far as I can with this and will use an extension when I require the feature in a site.

An additional view has implications with routing and is basically duplicate code from either the featured or category view. Nobody will merge that, I'm sure. And those with the "required skills" will know that.

Just trust those with the "required skills" when they tell you what is possible and how your request could be implemented. All it needs is that tag selector I already showed the code for and a category tree that fits your needs.

@Bakual

"...Nobody will merge that, I'm sure. And those with the "required skills" will know that."

Are you speaking for yourself or on behalf of the PLT ?

"Just trust those with the "required skills" when they tell you what is possible and how your request could be implemented."

So far you are the only one that has said it's not possible.

"All it needs is that tag selector I already showed the code for and a category tree that fits your needs."

What you have shown is close but requires Categories to be in the same tree.

http://extensions.joomla.org/extension/fj-related-articles-blog-and-list-component will do what is expected. We will just have to make do with installing that if the required view isn't included in the Joomla core

Are you speaking for yourself or on behalf of the PLT ?

I'm no longer in PLT since some months now.

but requires Categories to be in the same tree.

Which is no issue at all.

http://extensions.joomla.org/extension/fj-related-articles-blog-and-list-component will do what is expected.

So we don't have to do anything in core because it can be done with 3rd party extensions. That's fine with me.

but requires Categories to be in the same tree.

Which is no issue at all.

By the same logic it wouldn't be be a problem not having the root category in "Category List": you could always resort putting all of your categories under a fake, user defined, root category.

http://extensions.joomla.org/extension/fj-related-articles-blog-and-list-component will do what is expected.

So we don't have to do anything in core because it can be done with 3rd party extensions. That's fine with me.

By the same logic it wouldn't be worth adding "custom fields" to the core in the upcoming 3.7 release: the world has plenty extensions offering the same functionality

... and BTW the sub-categories thing doesn't works at all.

Test it:

Category (with 1 tagged article and 1 non tagged article)
   |
   |
   +- SubCategory (with 1 tagged article and 1 non tagged article)

Results:

• 1 article from Category is displayed
• Link to SubCategory is displayed
• Click on SubCategory
• Both articles (tagged and non-tagged) in SubCategory are displayed

The result would be expected as the link is to a category without any tags filter applied.

I said to set the parameter "include subcategories" to "all", which will display the items from subcategories in the same list as if they were on the same category.

The result would be expected as the link is to a category without any tags filter applied.

I said to set the parameter "include subcategories" to "all", which will display the items from subcategories in the same list as if they were on the same category.

Correct! I did set the "Subcategory Levels" option to "All" instead of the "Include Subcategories" one. Correct settings are:

• Subcategory Levels to None (for not having links to unfiltered views. It could probably be forced for this layout...)
• Include Subcategories to All (or whatever is needed...)

This, anyway, doesn't affect my previous two objections...

A couple of minor mods seems to be enough for allowing the selection of the "Root" category: unhappily one of those is a modification to a legacy library and I'm totally unsure if this can have detrimental side effects...

@Webdongle, @Duddy67

Can you guys test this as it is now? With latest commit the "Root" category issue seems to be solved.
Just be sure of not making my same mistake and set the subcategories options as described above.

Things I still would like to solve:

• Support for multiple tags. The main issue here is doing it in a way that is B/C with #8846
• The "DRY" myself hates the fact that this duplicates all of the "Category Blog" layouts/sub-layouts. I'm thinking about "incorporating" this in the "Category Blog" menu item type... what's your opinion?

The main issue here is doing it in a way that is B/C with #8846

Just saying: It doesn't have to be B/C as long as this is merged into 3.6.0 as well.

@Bakual Thanks for the hint, Thomas, but I think the odds of this being merged with 3.6 are very-very slim, to be optimistic (not tested yet...)

I think #8846 made a mistake not taking into account multiple labels: labels have always been "marketed" as a solution for not having "multiple categories" and having a filter based on a single label goes against this...

The ability to have com_tags views filtered by multiple tags gave us headaches multiple times already due to security issues. I think the existing com_tag single tag view (tag) should have never done like this and should only have allowed a single tag.
But that's my personal opinion. If you're going to change this to allow multiple tag selection, you have a lot more codework to do and it's indeed very likely it doesn't get merged for 3.6.0.
My proposed solution however would likely have been merged a week ago

My proposed solution however would likely have been merged a week ago

You mean #10242?

staging...Bakual:AddTagFilterToBlog

@smz this is over a year now since the last comment - is this still active or should it be closed

@brianteeman if by "active" you mean that the requested functionality (it's an RFC with a proof of concept, not a PR) is not there yet and an official decision about its need should be taken, then I'd say it is. If on the contrary you mean that this is "good code", I'm afraid it isn't.

on the basis that it has been a year since the last comment and its not usable code then shouldnt it be closed - it can always be re-opened if you ever create the good code

its obviously not something that is a high priority for people or perhaps even something that is wanted if it has gone a year without update

Closed