Would you like a tag view feature ?

[theduddy67]

Hello everyone,

I'm a web developer and I've worked with Joomla for over 5 years.
Recently I set up a kind of generic component (an Hello World component like) which I use as a starting point whenever I have a new component to develop for a client.
This component has the Joomla standard functionalities (create/edit items etc...) but I've added to it a new feature.

Indeed, it's been a while that I've been stuck with the "multicategories problem" without finding out a real solution.
Most of the time I end up with a CCK (flexicontent, seblod) which is a far more complex and heavy solution compare to my initial needs.
So I decided to add a tag view to my component which displays (in frontend) all the component items labeled with the same tag in a blog or list layout.
Now the "multicategories problem" can be considered as solved since tags allow an even better flexibility regarding the item sorting (taxonomy).

So I was wondering if the Joomla core team would be interested in adding this feature to the framework.
In doing so the Joomla's users would be definitely freed from this "multicategories problem" and could organize and display their articles the way they want to.

Don't hesitate to ask for further informations.
I can send you a demo for you to see what this tag view feature looks like.


Regards
Lucas Sanner

[Webdongle Elgnodbew]

Are you saying

It adds a tag option to Category Blog, Category list menu item types to filter those views by Tag ?
or
It adds a tag option to Category Blog, Category list menu item types to display blog/list by tag regardless of category ... thus overriding the selected Category ?
or
It Creates new Category Blog, Category list menu item types to display blog/list by tag regardless of category ?

[theduddy67]

I'm saying

- It adds a tag option to Category Blog, Category list menu item types to display blog/list by tag regardless of category 

In the menu item form you are asked to select a tag not a category so there is no override.

[Bakual]

Isn't that what com_tags already does? You can select one (or multiple) tags and can optionally additionally filter it by content types. So you get a list of items with the selected tags.

[theduddy67]

Nope, com_tags displays all of the items that share the same tag, besides you cannot manage your items displaying as you whish since they are treated in the com_tags component. 

The tag view feature displays only your component items that share the same tag in a tag blog/list layout. And you can manage your items as you would with a category blog/list

[Sergio Manzi]

Lucas,

If you're willing to share your extension, why don't you put it in GitHub?

I'll surely be interested in it...

Thanks and regards,

Sergio

On 2016-05-01 14:14, theduddy67 wrote:

Nope, com_tags displays all of the items that share the same tag, besides you cannot manage your items displaying as you whish since they are treated in the com_tags component. 

The tag view feature displays only your component items that share the same tag in a tag blog/list layout. And you can manage your items as you would with a category blog/list

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

[theduddy67]

Sergio,

Thanks for your suggestion.

Actualy it's not an extension, it's a feature which could be part of any Joomla standard component in a future version of Joomla.

I think I'm gonna set up a demo website so that people can go and see what this tag view feature is really about.

[Sergio Manzi]

Yes, I understand what your objective is, and I share your vision (a "Tag Blog" view can be very useful, I agree!), but I suppose you implemented it as separate views that complement current com_content views, without patching them (you know, the "a kitten will die" thing...).

If this is the case you could publish them separate from the core and everybody could "insert" them as com_content "add-on. Yes, it will not be an "extension" in the classical terms, but a "common playground" to experiment and appreciate the value of your proposal.

As an alternative you can propose your mods as a PR for an upcoming new Joomla release. This will be a little bit tougher, I guess.

Keep also in mind that next minor release (3.6) is targeted to include the new "custom fields" feature, so I think your mod should also take this aspect into account.

Regrads,

Sergio

[theduddy67]

Thanks again for your suggestion but I'm not sure that the tag view feature can come as an "add-on".

It is not just an extra view in the component, it also implies a deep interaction between standard features.

For instance in backend when the tag filter is selected the standard Joomla ordering item is replaced by a dedicated tag ordering (a mapping table). In doing so the user is able to display the tagged items in a specific order in the tag view.

[Sergio Manzi]

... then I think a PR is the only way.

I'm looking forward to test it!

Cheers,

Sergio

[theduddy67]

What does PR mean ?

[Webdongle Elgnodbew]

"I'm saying- It adds a tag option to Category Blog, Category list menu item types to display blog/list by tag regardless of category"

That would be a bit confusing because the Category Blog, Category list menu item types have an option to select a category.  So to have an option that overrides the selected category would be contradictory. 

Better (imho) would be:
Either a separate component (as part of the core files) that has its own menu item types .. based on tag selection ... that display like Category Blog, Category list views
or
Additional Tag menu item type views that display like the Category Blog, Category list views

If you make a Pull Request then I would test it

[Sergio Manzi]

Ah, sorry, I thought you were familiar with the term!

A PR is a "Pull Request", that is your request for your code to be "merged" into Joomla core.

This is done through the usage of the "Git" source code management system hosted on GitHub (https://github.com/joomla/joomla-cms).

There are several pages scattered around in Joomla documentation describing how this is accomplished, like, e.g.:

• https://docs.joomla.org/My_first_pull_request_to_Joomla!_on_Github
• https://docs.joomla.org/Using_the_Github_UI_to_Make_Pull_Requests
• http://extensions.joomla.org/blog/item/how-to-contribute-to-joomla-through-github
• https://docs.joomla.org/Git_for_Coders

There are probably others too and I'm unsure, at this point, which one should be considered more "authoritative".

On 2016-05-01 20:20, theduddy67 wrote:

What does PR mean ?

[Webdongle Elgnodbew]

You may wish to look at the free extension http://extensions.joomla.org/extensions/extension/structure-a-navigation/multi-categorization/fj-related-articles-blog-and-list-component

On Sunday, 1 May 2016 09:08:06 UTC+1, theduddy67 wrote:

[sup...@jlhwebdesigns.com]

I am a novice, but I think a demo site would be very helpful. I also believe that a "Tag Blog" would be a very useful addition.

 

However, I don't believe it should override or contradict the core concept of a "category blog". Thus, I see it as a new "tag blog" -- separate and independent of the "category blog" -- where any number of tags could be selected. For example, I want to show all articles that have a Tag of either "Pub", "Tavern", "Bar" or "Club" on one Page. Then, I might want to add a Location Tag such as "Riverfront". Then, I would have a select list of businesses on Riverfront where one could get a cold beer. Nice!

 

I was confused about the PR. I thought it ought to be "Push Request" instead of "Pull Request -- sort of like the put() and get() functions. But, I now think of a PR as a Request to Pull the New Stuff into the Core -- and it makes more sense. So, I will Push it (upload it to GitHub) and request that the "Powers to be" Pull it into the core with a PR..

 

----- Original Message -----

[Webdongle Elgnodbew]

I was confused about the PR. I thought it ought to be "Push Request" instead of "Pull Request -- sort of like the put() and get() functions. But, I now think of a PR as a Request to Pull the New Stuff into the Core -- and it makes more sense. So, I will Push it (upload it to GitHub) and request that the "Powers to be" Pull it into the core with a PR.."

When you create the PR please give full testing instructions i.e. what the new menu item type is called etc.

[Bakual]

As I said, com_tags is able to filter by content type, which basically means by component (even a bit more granular if the component has multiple content types).

Thus you can for example have a view showing all contacts tagged "red", without showing the articles with the same tag.

For how to display them, that's what overrides are for. But yes, there com_tags is a bit lacking. Ideally it would optionally call a JLayout for each content type to render it in.

[Webdongle Elgnodbew]

Hi Bakual

"For how to display them, that's what overrides are for. But yes, there com_tags is a bit lacking. Ideally it would optionally call a JLayout for each content type to render it in"

Would that be different views for the com_tags component of something a little more complecated? 

[Sergio Manzi]

No you can't.

You can have the equivalent of "Category List" by using "Tagged Items", but there is no equivalent of "Category Blog".

It is quite obvious if you think it over a second: all "Tag" views are, by definition, com_tags views (and they can apply to whatever object of whatever nature from whatever component that supports tags), so they have no knowledge of the nature of the items they are listing.

Can you see all the com_content item related options (e.g. "Show Author", "Show Voting", "Show Intro Text", etc.)  we have in "Category Blog" in "Tagged Items"? I can't.

Of course in your override you could re-implement all the com_content logic (and options) to have those, but it will be a monster override.

If the view shows content it belongs to com_content, not com_tags, the same way "Category Blog" belongs to com_content and not com_categories.

--

[Bakual]

Yes, it's true the current tag view is only producing a list. But that doesn't mean it couldn't do more.

The params and text is saved in the #__ucm_content table. So the data would be there to use.

You're right that a single override would be a monster if it had to deal with each extension and possible parameters. And it of course would be lacking support for any 3rd party extension. So that isn't a good approach when we're talking about a template offering that override.

However it would work if you do that as the admin of a specific website. You only would do it for the component(s) you need and you could ignore all parameters anyway and just write it the way you want.

But besides that. If we want to implement such a layout, it should make heavy use of JLayouts as I suggested. The main layout could check the presence of a content type specific JLayout which would render the item. That JLayout would have to be provided by the extension responsible for that content type (eg com_content has a JLayout to display an article). If the JLayout is present, the main tags layout would give the data to that JLayout which does the rendering and returns the fully rendered item. If there is no specific JLayout, it could fall back to a generic JLayout. The main layout then just puts it together to a "blog". This way you could actually make a "cross-extension page" which content from various extensions.

No need to have duplicated views across each extension.

This is what tags should have been always, but at the time it was written I think we didn't have JLayouts yet :)

[Sergio Manzi]

I have nothing against JLayouts, to the contrary! :-)

But you haven't addressed the issue of where the options for those JLayout will be set.

Tags are a kind of taxonomy, exactly same as categories.

Taxonomies should be used by components for filtering content (of whatever nature).

Content views belongs to their respective components.

[theduddy67]

Sergio is correct. com_tags is not as flexible as a category blog, this is why I've developed this tag view feature.

As always one example is far more clear than a thousand of explanations so here is a link to a demo website:

http://demotagview.radisnoir.site/

It's very basic but you can at least have a quick overview of what the tag view feature is about.

Enjoy :)

[Webdongle Elgnodbew]

@theduddy67

As always one example is far more clear than a thousand of explanations so here is a link to a demo website:

http://demotagview.radisnoir.site/

We know what the views should look like.  What is in question is the best way to implement it.  Your example only shows us what we already know ... what we need is your code in a PR so we can pull it into our individual branches of staging so that we can test it.

Maybe the simplest method would be to create more 'views' in the com_tag component that would give new menu item types in com_tags.  Perhaps use the files in /\components/com_content\views/category/tmpl as templates ... edit them for use in /components/com_tags/views/tags/mpl ?

[Chris Davenport]

You might like to explore using Smart Search.  I'm not sure that the tags finder plugin has been fully implemented, but you could fix that and use it to create whatever crazy filter criteria you might happen to want, then you can show results across all content types in whatever way you want them.

Chris.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send email to joomla-...@googlegroups.com.
Visit this group at https://groups.google.com/group/joomla-dev-cms.
For more options, visit https://groups.google.com/d/optout.

--

Chris Davenport
Joomla Production Leadership Team

[theduddy67]

Regarding the pull request I need time to set it up and I'm quite busy these days.

Meanwhile, if you're interested, I can post the SongBook component and its plugin for you to download.

[Sergio Manzi]

That would be great. The component or the whole Joomla installation, without DB, so we can check if anything else was modified and what your base Joomla version is.

You could do that by cloning it into a GitHub repo or, if you're not familiar with that, putting it into a publicly shared Dropbox/GoogleDrive/OneDrive folder.

If you wish I could then put it into a GitHub repo.

Regrads,

Sergio

On 2016-05-02 20:48, theduddy67 wrote:

Regarding the pull request I need time to set it up and I'm quite busy these days.

Meanwhile, if you're interested, I can post the SongBook component and its plugin for you to download.

[Bakual]

The options for the JLayout would have to be taken from the global component settings for obvious reasons. Maybe some generic ones can be done in com_tags and it's menu item, overriding the component ones.

Tags were meant to create a system of cross-extension filtering. They are not really designed to filter extension content. Look at the database structure and you see what I mean. You will have to join over several tables to filter your items by a specific tag :)

[Sergio Manzi]

Thomas,

I'm really sorry you're insisting that it can be done "your way": yes, it can. Everything can be done, but will it be good architecture? Not at all!

Just to make myself clear, when I was talking about "monster override" I wasn't referring  to the "size" of the override but to its "nature" as it will be a freak one totally breaking the MVC paradigm.

On 2016-05-02 23:28, Bakual wrote:

The options for the JLayout would have to be taken from the global component settings for obvious reasons. Maybe some generic ones can be done in com_tags and it's menu item, overriding the component ones.

Yes, the obvious reason is that that's not the place for them. Putting "some generic ones" in there for a particular component would be an architectural mistake. One we have already done, btw, when we inserted things such as "Item Image" in the "Item options" of the "Tagged Items" view.

Tags were meant to create a system of cross-extension filtering. They are not really designed to filter extension content.

Ahem... aren't the two above sentences mutually exclusive?

 Look at the database structure and you see what I mean. You will have to join over several tables to filter your items by a specific tag :)

No I haven't looked, but I suppose this is what all current "Tags" views are doing, right?

Just to make myself clear, I don't think we should re-code all of the tag selection logic in every view of every component for which we want a "List of item" or a "Continuous display of items" (a.k.a. "Blog") in which items are selected on the basis of a particular or several tag being applied.  To the contrary, what I think is that we should "pipeline" the list (array) of items selected by a generic com_tags "view" (or helper class) into specific views for specific purposes of specific content generators/handler/consumers (a.k.a. "components").

The only legitimate native front end tags views are the ones that generate generic lists of possibly heterogeneous (coming from different components) items. And this is because tags are a taxonomy concept and not a content concept.

Same should had been for categories, but unhappily they are now so much encrusted into everything (heck, they even build up the route to items...) that's it not feasible to decouple them from what they have been forcibly married.

Have a look around at what other CMS/frameworks are doing and tell me if this is not the case.

Cheers!

Sergio

[Bakual]

Am Dienstag, 3. Mai 2016 00:41:22 UTC+2 schrieb Sergio Manzi:

No I haven't looked, but I suppose this is what all current "Tags" views are doing, right?

Current Tags doesn't do it that way. Current tags runs from copies of the data in its ucm tables.

If you want to filter your extension data by tags, you can do it by joining the #__contentitem_tag:map table, filtering by "type_alias" (currently unindexed varchar) or "type_id" (if you queried that before) and tag_id (which could be a nested set) and you join by the content_item_id. Looks like the data needed is copied all there from the other UCM tables. So it's less than I thought.

Imho, my idea isn't that bad like you make it sound. Maybe we misunderstood eachother.
I think it would be much worse if each extension that supports tags has to add filters for their list views to allow filtering by tags (because that is essentially what that new "view" would be, the existing view with added filter). Currently, extensions don't have to know anything about how tags are stored, it all works over an API. That would change.

Imho, com_tags has to deal with tags and it already has the needed data. The only missing part is that it doesn't know how to render an item. Using content type specific JLayout provided by the extension we would be able to solve this in a nice way.

[Webdongle Elgnodbew]

Hi Bakual

"Imho, com_tags has to deal with tags and it already has the needed data. The only missing part is that it doesn't know how to render an item"

Yes ... from a users point of view yes.  It would be good if (in the com_tags) there were menu item types that used a view to render a look like Cateegory/Fetured Blog and Category list.

"Using content type specific JLayout provided by the extension we would be able to solve this in a nice way"

If that is the same way com_content Featured an Category Blog/List do it then yes to that to.

I know how to create an override and (at a push) could probably create a new view in com_tags but am a little stuck on how to add a menu item type for it.  If you could post a few links that I would point me in the right direction ... then I could have a stab at creating new views for com_tags.

[Bakual]

The menu item type is created automatically if you create an XML file with the same name as the layout. Eg copy the existing default.xml file and adjust it.

However I'm not sure you need a new view. I think it should work with a layout for the existing tag view. The data is there and you can actually already show the item content (description).

What is missing is special data for a specific item. That is a limitation of the current com_tags. Unfortunately someone decided to put a field in for specific attributes, mostly com_content stuff. But other extensions may have different database fields (like the adress in com_contact) which are not reflected in com_tags. Those data can't be show in a tags view.

[Webdongle Elgnodbew]

Hi Bakual

"The menu item type is created automatically if you create an XML file with the same name as the layout. Eg copy the existing default.xml file and adjust it"

Yes if a Template override is created and renamed it becomes a Layout override and creating an xml file adds a new menu item type.  So the same for a component view ...
ie. default.xml in the /views/viewname ?

"However I'm not sure you need a new view. I think it should work with a layout for the existing tag view"

But it needs to display on a screen in the same format as Featured/Category Blog.  Surely creating a new view is better than editing an existing com_tags view to display differently ?
e.g.
As well as
/components/com_tags/views/tag/tmpl/default.php
and
/components/com_tags/views/tags/tmpl/default.php
have
/components/com_tags/views/tagblog/tmpl/default.php

That would allow Articles to be displayed in blog format according to matching Tags.  imho that would be the best approach to take from a users point of view as it would effectively be a multi category Blog.  Technically from a programmers point of view ... how does that pan out ?

[Bakual]

It's always (in core that is) the XML file from the layout that defines the menu item type. One could also define them on view level (using a metadata.xml) or component level (don't remember the filename there) but that isn't used in core to my knowledge.

[Bakual]

But it needs to display on a screen in the same format as Featured/Category Blog.  Surely creating a new view is better than editing an existing com_tags view to display differently ?
e.g.
As well as
/components/com_tags/views/tag/tmpl/default.php
and
/components/com_tags/views/tags/tmpl/default.php
have
/components/com_tags/views/tagblog/tmpl/default.php

A new view is only needed if you want to deal with different data. But you're going to use the same data as in the tag view but in a different design. Then it's just another layout for the tag view.

[Webdongle Elgnodbew]

"A new view is only needed if you want to deal with different data. But you're going to use the same data as in the tag view but in a different design. Then it's just another layout for the tag view."

I understand what you are saying but I think you missed the point from a users angle ?

Because if another view is added then it would compare too Category List and Category Blog ... but if it was just a different design (of the same view) then it would be like editing the Category Blog view to also be able to be configured like a Blog.  Besides which to display a Blog view based on Tags would require more data than the /views/tag/ and /views/tags/ currently use ... wouldn't it ?

[Bakual]

The Category List and Category Blog are both layouts of the same view. For the user, it doesn't matter at all if it is an own view or just a different layout of the same view. He will just see two menu item types that he can choose. :)

The blog view may need more data than is present in the tag view. But it may even be missing in the UCM tables. Which means we would first have to add it there and after that we could add it easily to the tag view.

[Webdongle Elgnodbew]

"The Category List and Category Blog are both layouts of the same view. For the user, it doesn't matter at all if it is an own view or just a different layout of the same view. He will just see two menu item types that he can choose. :)"

Yep ... just had another look and now see what you mean

"The blog view may need more data than is present in the tag view. But it may even be missing in the UCM tables. Which means we would first have to add it there and after that we could add it easily to the tag view."

1. How difficult would that be to achieve ?
2. Would the result be worth the effort of doing it ?
3. Or is it better to leave it to 3rd party extensions to achieve the same result ?
   

[Chad Windnagle]

I've written custom views for tags to achieve this functionality and I think its certainly worth having in core. It shouldn't be much more than some helper model functions and dedicated menu item types. 

Regards,
Chad Windnagle

On Tue, May 3, 2016 at 6:14 PM, Webdongle Elgnodbew <in...@weblinksonline.co.uk> wrote:

"The Category List and Category Blog are both layouts of the same view. For the user, it doesn't matter at all if it is an own view or just a different layout of the same view. He will just see two menu item types that he can choose. :)"

Yep ... just had another look and now see what you mean

"The blog view may need more data than is present in the tag view. But it may even be missing in the UCM tables. Which means we would first have to add it there and after that we could add it easily to the tag view."

1. How difficult would that be to achieve ?
2. Would the result be worth the effort of doing it ?
3. Or is it better to leave it to 3rd party extensions to achieve the same result ?
   

On Tuesday, 3 May 2016 22:01:41 UTC+1, Bakual wrote:

The Category List and Category Blog are both layouts of the same view. For the user, it doesn't matter at all if it is an own view or just a different layout of the same view. He will just see two menu item types that he can choose. :)

The blog view may need more data than is present in the tag view. But it may even be missing in the UCM tables. Which means we would first have to add it there and after that we could add it easily to the tag view.

Am Dienstag, 3. Mai 2016 22:43:44 UTC+2 schrieb Webdongle Elgnodbew:

"A new view is only needed if you want to deal with different data. But you're going to use the same data as in the tag view but in a different design. Then it's just another layout for the tag view."

I understand what you are saying but I think you missed the point from a users angle ?

Because if another view is added then it would compare too Category List and Category Blog ... but if it was just a different design (of the same view) then it would be like editing the Category Blog view to also be able to be configured like a Blog.  Besides which to display a Blog view based on Tags would require more data than the /views/tag/ and /views/tags/ currently use ... wouldn't it ?


On Tuesday, 3 May 2016 21:17:30 UTC+1, Bakual wrote:

But it needs to display on a screen in the same format as Featured/Category Blog.  Surely creating a new view is better than editing an existing com_tags view to display differently ?
e.g.
As well as
/components/com_tags/views/tag/tmpl/default.php
and
/components/com_tags/views/tags/tmpl/default.php
have
/components/com_tags/views/tagblog/tmpl/default.php

A new view is only needed if you want to deal with different data. But you're going to use the same data as in the tag view but in a different design. Then it's just another layout for the tag view.

--

[Sergio Manzi]

Kevin,

If you want to implement it "the wrong way" you might be interested in this:

http://joomla.stackexchange.com/questions/13583/how-to-show-tagged-items-in-category-blog-layout

Then, you could also answer to this (irony intentional...):

http://joomla.stackexchange.com/questions/14465/how-do-i-get-webchuns-taggedblog-solution-to-display-the-articles-formatted-ti?lq=1

Please, also not that this "Tag Blog" idea seems to be an idea proposed some time ago, but apparently royally ignored...

http://ideas.joomla.org/forums/84261-joomla-idea-pool/category/12057-content?query=category%20blog%20tagged%20items

On 2016-05-04 00:14, Webdongle Elgnodbew wrote:

"The Category List and Category Blog are both layouts of the same view. For the user, it doesn't matter at all if it is an own view or just a different layout of the same view. He will just see two menu item types that he can choose. :)"

Yep ... just had another look and now see what you mean

"The blog view may need more data than is present in the tag view. But it may even be missing in the UCM tables. Which means we would first have to add it there and after that we could add it easily to the tag view."

1. How difficult would that be to achieve ?
2. Would the result be worth the effort of doing it ?
3. Or is it better to leave it to 3rd party extensions to achieve the same result ?
   

On Tuesday, 3 May 2016 22:01:41 UTC+1, Bakual wrote:

The Category List and Category Blog are both layouts of the same view. For the user, it doesn't matter at all if it is an own view or just a different layout of the same view. He will just see two menu item types that he can choose. :)

The blog view may need more data than is present in the tag view. But it may even be missing in the UCM tables. Which means we would first have to add it there and after that we could add it easily to the tag view.

Am Dienstag, 3. Mai 2016 22:43:44 UTC+2 schrieb Webdongle Elgnodbew:

"A new view is only needed if you want to deal with different data. But you're going to use the same data as in the tag view but in a different design. Then it's just another layout for the tag view."

I understand what you are saying but I think you missed the point from a users angle ?

Because if another view is added then it would compare too Category List and Category Blog ... but if it was just a different design (of the same view) then it would be like editing the Category Blog view to also be able to be configured like a Blog.  Besides which to display a Blog view based on Tags would require more data than the /views/tag/ and /views/tags/ currently use ... wouldn't it ?


On Tuesday, 3 May 2016 21:17:30 UTC+1, Bakual wrote:

But it needs to display on a screen in the same format as Featured/Category Blog.  Surely creating a new view is better than editing an existing com_tags view to display differently ?
e.g.
As well as
/components/com_tags/views/tag/tmpl/default.php
and
/components/com_tags/views/tags/tmpl/default.php
have
/components/com_tags/views/tagblog/tmpl/default.php

A new view is only needed if you want to deal with different data. But you're going to use the same data as in the tag view but in a different design. Then it's just another layout for the tag view.

--

[Michael Babker]

ideas.joomla.org has been royally ignored for years, just being blunt about it.  There's a reason it finally fell off the .org navigation menus.

[Webdongle Elgnodbew]

Hi Chad
Could you create a PR ?


Hi Sergio
Thanks for the link but how does hacking core files relate to what Bakual  suggests ?

[Sergio Manzi]

Too bad, because amongst some strange and unfeasible ideas there are also some "gems", like this one, IMHO.

If you read the comments to the "Tag Blog" idea there is one which I think is very spot on:

This is exactly what i'm looking for.

When i heard, joomla 3.x comes with an integrated tag-component, i thought this would be the main function.

Since today i'm looking for another way to get this feature to my website.
I hope you notice this featuere and update this function.

It would be the easiest way to show every content (and the other components) of one basic tag without category limitation

[Sergio Manzi]

hacking core files with the PLT blessing is not hacking any more!

and if I'm not mistaken the one I pointed to is exactly Bakual's idea...

[Chad Windnagle]

Hi Sergio

Sorry the code I wrote for that was done a long time ago and is definitely not "fit" for a PR. Just sharing for confirmation on the proof of concept. 

Regards,
Chad Windnagle

[Sergio Manzi]

Chad,

Actually it was Kevin, not me, who asked for you to push a PR, but I'll be anyway curious to give a look at it...

[Chad Windnagle]

Oops sorry! Fast reading. 

Regards,
Chad Windnagle

[Sergio Manzi]

... but... wait a minute, Chad: is it you "webchun" on StackExchange?

Is it that your code you were referring?

Sorry if I'm mixing up things...

Regards,

Sergio

[Chad Windnagle]

Not me. My stack exchange would be drmmr763. The code I'm referring too would be: https://github.com/drmmr763/tag-cat-groups (really old and not really recommended for anything other than reference / ideas / inspiration) 

Regards,
Chad Windnagle

[Sergio Manzi]

Thanks!  :-)

[Webdongle Elgnodbew]

Hi Sergio

How would you

1. Create a menu item type
2. Have that menu item display a page that displays Articles (based on Tags) in the style of a Featured/Category Blog
   

If not by adding to an existing com_tags view or creating another com_tags view ... how would you do it ?

[Sergio Manzi]

Simple: like we do for every other com_content view.

• have a model in com_content
• have a view in com_content

The model could use JHelperTags::getTagItemsQuery() to select the relevant items.

[Webdongle Elgnodbew]

Hi Sergio

So you are saying a Tag Blog menu item type that displays Articles (in a single or multi-column layout) based on selected Tags belongs in


not





From a users point of view I could see that being 'intuitive.  From a technical view point how does that 'scan' ?  Are you saying that from a coding perspective that is (for want of a better phrase) more correct ?

[Sergio Manzi]

Absolutely. That's what I'm repeating since the beginning.

Also keep in mind that:

• The "Tagged items" (as you called it) layout (or template... the thing that goes into tmpl...) would practically be a clone of the one we currently have for "Category Blog"
  
  
• The view wouldn't be much different, I guess...
  
  
• The model would be quite easy thanks to JHelperTags::getTagItemsQuery()

Even more (just ideas buzzing in my mind...):

• The sub-template used to display each item (article) could be transformed into a JLayout and shared between all views that display one or more article (Single Article, Category Blog, this new thing, etc..). I know this is an heterodox usage of JLayouts, but it works and I'm using this in my "Pantarei" template (https://github.com/smz/tpl_pantarei)
  
  
• In the "New thing" we could also add the option for filtering based on category/categories (but I'm unsure about that...).
  
  
• ... and to filter based on the "featured" status.
  

We could call the "New Thing"... "Blog", maybe.

Cheers!

Sergio

[Webdongle Elgnodbew]

Hi Sergio

Absolutely. "That's what I'm repeating since the beginning"

Forgive my ignorance for not understanding the way you explained it before ... not being a dev I needed to ask questions in order to get it explained more clearly.

1. How long would it take you to do it ?
2. Do you have the time to do it ?
   

[Sergio Manzi]

No problem, Kevin: English not being my native language I probably didn't express myself clearly.

Answering to your questions:

1. Not much, I guess, if done by an experienced Joomla core developer.

2. I'm not an experienced Joomla core developer. I may have vision, but I will be overwhelmed by the task of maintaining consistence with all the legacy code, so I don't see myself fit to the job, unhappily. I could try, if helped with the right experienced guidance, but the process will take a lot longer, I'm pretty sure.

[theduddy67]

Hi guys,

Glad to see that many Joomla developers are passionately interested in that feature.

I've finaly managed to post the songbook component and its plugin on Github 

https://github.com/Duddy67/song-book 

So that you can try it, examine it closely, break it down and see if it fits your purpose.

Thanks for your feedback.

[Webdongle Elgnodbew]

Hi Sergio

Given

"I'm not an experienced Joomla core developer. I may have vision, but I will be overwhelmed by the task of maintaining consistence with all the legacy code, so I don't see myself fit to the job,"

Then what makes your approach the 'most correct' method technically ?
and
As you can't do it then how can you be confident it can be done that way ?

Not a personal attack because I admit that I'm not qualified to say which method is technically correct.  But as an end user ... having the new menu item type for the view in com_tags or com_content makes sense to me either way.

[Webdongle Elgnodbew]

Hi duddy

Sorry but your method does not add an extra view ... it changes an existing view.

Could you produce the required end result by
either
Adding a new view to com_content
or
Adding a new view to com_tags
???

[theduddy67]

"Sorry but your method does not add an extra view"

Yes it does. If you look at the code carefully you'll notice a tag view folder and a tag model as well.

I don't know what you expected exactely but the component meets its objective which is to display items labeled with the same tag in a tag blog (or a tag list) layout. 

Regarding your question about adding a new view to com_content I think it shouldn't be a problem. 

I have not yet think about it but there are several ways to achieve this.

[Petros]

https://groups.google.com/forum/#!topic/joomla-dev-general/4sgkgRgxvZc

Just to express my interest in more tags funcionality :)

Τη Κυριακή, 1 Μαΐου 2016 - 11:08:06 π.μ. UTC+3, ο χρήστης theduddy67 έγραψε:

Hello everyone,

I'm a web developer and I've worked with Joomla for over 5 years.
Recently I set up a kind of generic component (an Hello World component like) which I use as a starting point whenever I have a new component to develop for a client.
This component has the Joomla standard functionalities (create/edit items etc...) but I've added to it a new feature.

Indeed, it's been a while that I've been stuck with the "multicategories problem" without finding out a real solution.
Most of the time I end up with a CCK (flexicontent, seblod) which is a far more complex and heavy solution compare to my initial needs.  
So I decided to add a tag view to my component which displays (in frontend) all the component items labeled with the same tag in a blog or list layout.
Now the "multicategories problem" can be considered as solved since tags allow an even better flexibility regarding the item sorting (taxonomy).

So I was wondering if the Joomla core team would be interested in adding this feature to the framework.
In doing so the Joomla's users would be definitely freed from this "multicategories problem" and could organize and display their articles the way they want to.

Don't hesitate to ask for further informations.
I can send you a demo for you to see what this tag view feature looks like.


Regards
Lucas Sanner

[Sergio Manzi]

Hi Kevin!

On 2016-05-04 10:39, Webdongle Elgnodbew wrote:

Hi Sergio

Given

"I'm not an experienced Joomla core developer. I may have vision, but I will be overwhelmed by the task of maintaining consistence with all the legacy code, so I don't see myself fit to the job,"

Then what makes your approach the 'most correct' method technically ?
and
As you can't do it then how can you be confident it can be done that way ?

Not a personal attack because I admit that I'm not qualified to say which method is technically correct.  But as an end user ... having the new menu item type for the view in com_tags or com_content makes sense to me either way.

No, I'm not offended at all by your question, but I find it to be... well... a really curious one! :-)

I'll try to give you some answers, hoping they will convince you:

• ... because you don't necessarily need to be a tailor to tell a well cut dress from a bad one
  
  
• ... or because you can tell a well written book from a bad one without being a writer
  
  
• ... because leading high profile IT and telecommunications projects is what I've done for a living in my last 40 years (well, not from the beginnings, actually!) and advising people on architectural patterns (and very often taking the final decision about it), leaving the implementation details to the people I trusted and had the right competence, was part of my daily responsibilities. (CV privately sent  on request)
  
  
• ... because I know how the MVC architectural pattern works
  
  
• ... because I firmly believe on the "Principle of least astonishment" (https://en.wikipedia.org/wiki/Principle_of_least_astonishment) and when I see something odd (like a component view menu item popping out in an unexpected place), I raise my antennas and try to understand if there is something wrong with it (and 99% of the times there actually is something wrong...)
  
  
• ... because I've done my homework and seen what we do in all other similar cases
  
  
• ... because nobody has so far stated that my approach is wrong

I hope you find the above points valuable.

Regards,

Sergio

[Webdongle Elgnodbew]

Hi duddy

Yep I see it now but ...
The blog menu item type for your component has selection for category not Tag.  And according to the others it would seem that a new component is not necessary ... just another view of either com_tags or com_content.  Also the language files are in the /component/com_songbook/language folder instead of the Joomla /language folder.

[Sergio Manzi]

oops... read: "like a content view menu item popping out in an unexpected place"

[Webdongle Elgnodbew]

Hi Sergio

That answers my question.  Like I said

" having the new menu item type for the view in com_tags or com_content makes sense to me either way."

My gut feeling now is that com_content is the way to go because it is content being displayed not the Tags themselves.  i.e. The Tag(s) is/are the selection criteria not not the display criteria.  You understand the code better than me so are in a better position to know which approach is the best code to use.  I suspect that the devs who can write the code might disagree which approach to use.  I just hope that one of the devs can produce a PR for this enhancement.

[Bakual]

Am Mittwoch, 4. Mai 2016 00:14:08 UTC+2 schrieb Webdongle Elgnodbew:

"The blog view may need more data than is present in the tag view. But it may even be missing in the UCM tables. Which means we would first have to add it there and after that we could add it easily to the tag view."

1. How difficult would that be to achieve ?
2. Would the result be worth the effort of doing it ?
3. Or is it better to leave it to 3rd party extensions to achieve the same result ?

1. It sure is possible, the difficulty is probably to decide on a way to implement it, not the actual coding :)

2. Probably yes

3. No

Imho, there are two approachs you can go. One is to call the model and query the extension tables for the full details of an item. That could be done in a content type specific JLayout easily, but has its flaws from an architectural point of view since we do more database queries and the layout shouldn't deal with retrieving data from the tables.

The other approach would be to store the full details in the UCM tables. com_tags could json_encode the whole item object and store it in a database field. The downside here is that it may fail if there is a big object or if an extension has item attributes which don't store well in JSON. Also it will make the tables quite a bit bigger. It also doesn't work on existing items as long as they aren't resaved.

Both ways have their downsides as you see.

[Sergio Manzi]

You're welcome Kevin.

On a personal note I would like to tell you that I like the way you don't "give things as granted" and you listen to your guts!

--

[Sergio Manzi]

Thomas,

what's wrong with using JHelperTags::getTagItemsQuery()?

[Bakual]

It gives you the data that is present in the UCM tables. My answer was about possible ways to get data which isn't stored in the UCM tables (eg the address from a contact).

So for com_tags, this doesn't give us more data than what is already available in the tag view. May be related to the fact that this view uses that method to fetch the query :-)

For extensions, it would be a complex query to run on each list. It uses several joins and groups which just would not be needed if the extension would do it's own querying of the #__content_tag_map. Thus from a performance view, it would be horrible.

So I'm not sure what you want to use it for?

[Sergio Manzi]

Once you have the content items IDs, which you get from JHelperTags::getTagItemsQuery(), wouldn't it be enough to run a second query on the content table (c) with

where('c.id IN (' . implode(',', $ids_from_tags) . ')');

?

[Webdongle Elgnodbew]

Hi Bakual

My answer was about possible ways to get data which isn't stored in the UCM tables (eg the address from a contact).So for com_tags, this doesn't give us more data than what is already available in the tag view.

From what I am understanding is that adding a view to com_content doesn't suffer that problem because the required data already exists there. The data displayed is Content not Tags  therefore

1. It makes sense to display via com_content and filter by Tag
2. Not to display via com_tags and filter by Category

With #1 ... All the data is already fetched and displayed in Category Blog ... the only difference is that the selected will have an extra IF criterion to match a Tag value(s)
but
With #2 ... A significant amount of rewriting com_tags would be needed.

@Sergio
Is that similar to what you are saying ?

[theduddy67]

The blog menu item type for your component has selection for category not Tag.

Not at all. Again please check the code carefully. 

When you create a new menu item just choose: SongBook->Tag Blog or SongBook->Tag List in the popup

than you'll see that it asked you to select a tag not a category.

And according to the others it would seem that a new component is not necessary

I've never intended to impose a new component. The purpose of the Songbook component is just to show how 

the tag view feature work.

The idea would be to embed this feature in the Joomla's standard components architecture.

[Bakual]

Yes sure, but why run a complex query if you're only need the ids? If you can do the same with one join over the tags_maps table in your extension? I'd rather deal with the table myself than running an unneeded complex query.
But then, I still think extensions shouldn't deal with tags in this way :)

[Bakual]

That's true, com_content wouldn't need the additional data from com_content for obvious reasons. By the way, it wouldn't need a new view there as well. What you want is adding a filter to the existing category view (blog and list layouts). The downside here is that this will only show items from com_content, while com_tags can show all tagged items regardless of extension.

Imagine that you could do a "featured" homepage, but with content from all extension. To make an example using my extension (SermonSpeaker) a church could have a homepage which shows a "Welcome" article, the next events (with start time, ical link and a map with location) from JEvents and the sermon (with audio player) from SermonSpeaker. All in the component area and not using any modules or plugins. Just by tagging the right article, events and sermons. :)

[Sergio Manzi]

... because "we want" (and sorry if I'm mis-interpreting) a view for com_content where we can set the very same display options we can set for "Category Blog"

[Sergio Manzi]

Hi Kevin!

On 2016-05-04 16:13, Webdongle Elgnodbew wrote:

Hi Bakual

My answer was about possible ways to get data which isn't stored in the UCM tables (eg the address from a contact).So for com_tags, this doesn't give us more data than what is already available in the tag view.

From what I am understanding is that adding a view to com_content doesn't suffer that problem because the required data already exists there. The data displayed is Content not Tags  therefore

1. It makes sense to display via com_content and filter by Tag
2. Not to display via com_tags and filter by Category

With #1 ... All the data is already fetched and displayed in Category Blog ... the only difference is that the selected will have an extra IF criterion to match a Tag value(s)
but
With #2 ... A significant amount of rewriting com_tags would be needed.

@Sergio
Is that similar to what you are saying ?

Somehow... the model for "Tags Blog" (let's call it that way for the time being...) should not filter on category but only on tags (again, for the time being, then we'll see if we can add more features...).

If I understand correctly how tags works, first you have a table, #_tags, where each tag info (title, description, etc.) is stored

Then you have a table (#_ucm_content) where some of the content fields (arbitrarily chosen when the tags feature was implemented, I suppose) are duplicated: "title", "alias", part of the "body" (don't know how much and chosen on which criteria...), "state", "access", etc. You also have "core_type_alias" (which is fixed to "com_content.article" for com_content items and "core_content_item_id", which relates to the com_content table.

So, through indirection via this core_content_item_id field we can get whatever content we want.

There are is of course also another table,  #_contentitem_tag_map, which relates #_tags to #_ucm_content, but also has fields to relate to the original content.

Please someone correct me if I'm wrong...

[Webdongle Elgnodbew]

Hi duddy

"When you create a new menu item just choose: SongBook->Tag Blog or SongBook->Tag List in the popup

than you'll see that it asked you to select a tag not a category."

Nope

I've never intended to impose a new component. The purpose of the Songbook component is just to show how 

the tag view feature work.

We know what the new layout should look like ... it should look like a Category Blog but filtered by Tag value(s).  What we are asking for is the code (that integrates into Joomla) that produces that affect.

[theduddy67]

Hi Webdongle 

Please scroll down !! :)

[Bakual]

Yeah, "we" is not me. I don't want to add it to com_content. But if you want, just add a filter to the category view and add that join over the tag_maps table to the respective model. Done.
No need for a special view or layout at all. But you will couple com_content tightly to com_tags exactly like it's done to com_categories. That's why I don't like it (and tags imho should be extension agnostic).

[Bakual]

As said when you're looking at tags from an extension view, all you need is the #__contentitem_tag_map table.

The tag id is already known from the menu item, otherwise we don't know what to filter on. So we don't need the tags table for the query. The content_item_id is the field we will join our own table on. And then we filter on the type_alias field which is a string defined by our extension when we implemented tags, so we know that as well.
The whole stuff in the UCM tables is not relevant for an extension since that data is present in own tables anyway.

[Sergio Manzi]

To sum it up (and I ask Thomas to correct me if I'm wrong), I think we have two proposal on the table based on different philosophies and each with its own merits/limitations.

• A generic "Blog whatever based on tags" solution proposed by Thomas which will be implemented in the framework of com_tags and will be able to display "com_whatever" items based on how they are tagged (I fail to see how this can be achieved for generic content of unknown nature, but I think Thomas idea is to somehow leverage JLayouts to do that).
  This solution, being content agnostic, will be unable to set display options for the displayed items.
  
  
• Another proposal (which I can't say it's "mine", but which I "champion"), which will copycat "Category Blog", will be limited to com_content items (but keep in mind that customs fields are on their way...), but on the other hand will give more display options for displayed items: the same we currently have for "Category Blog"
  

I think it's a matter of choosing which one is preferable from user's perspective.

Note: up to this point we haven't addressed routing issues: I don't know if there could be for each one of the proposed solutions...

Sergio

[Webdongle Elgnodbew]

Hi Bakual

"That's true, com_content wouldn't need the additional data from com_content for obvious reasons. By the way, it wouldn't need a new view there as well. What you want is adding a filter to the existing category view (blog and list layouts)."

But would not create a new menu item type would it ?  All that would do is add more options to the edit screens of the  Category Blog and Category List menu item types wouldn't it ?

"The downside here is that this will only show items from com_content, while com_tags can show all tagged items regardless of extension"

But it's only Articles (selected by Tags) being displayed in a Blog that we are talking about.

[Webdongle Elgnodbew]

Hi Sergio

Another proposal (which I can't say it's "mine", but which I "champion"), which will copycat "Category Blog", will be limited to com_content items (but keep in mind that customs fields are on their way...), but on the other hand will give more display options for displayed items: the same we currently have for "Category Blog"

imho from a users point of view that is preferable and 'Does what it says on the tin'.  The other proposal is illogical because it uses the Tag component to display Articles.  i.e. The content component should be used to display Articles as Articles are content not Tags.

[Sergio Manzi]

Of course I agree, but I want to recognize Thomas proposal its merit: if it could achieve displaying content of mixed origin (different components) in the same page it would be really interesting...

[Michael Babker]

It's not that hard.  You're starting from a standardized set of fields (UCM) so really you just need to sort out sublayouts for different content types, querying extra data from the non-shared source, and plugin event triggers (onContent***).  Smart Search already deals with the sublayout thing.

[Webdongle Elgnodbew]

Hi Michael

Do it with com_tags or com_content ?

[Michael Babker]

com_tags if you are creating a multi-component type view.  Otherwise you'd be trying to teach com_content how to render data for other components that it doesn't already have awareness of.

Ya, I know earlier you said this isn't a good idea (articles should only be rendered with com_content).  As is, that's not the case today.  Both search components can render standardized snippets of articles (and newsfeeds, weblinks, etc.) already so the same kind of concept would apply in com_tags if a view which could render all content items (regardless of "owning" component) was created.

This is totally separate to adding any filtering options that may be added to com_content (or other components) to create a view that shows all content items from that component which has a certain tag.  Just so that's clear.

IMO, there are possible use cases for different users for all of those scenarios, and IMO they're all possible to implement in core.  Then it really boils down to your preference on how you want stuff displayed.

[Sergio Manzi]

Yes, you're right: the two proposal are not mutually exclusive and there are good scenarios for both.

That said and with the standard caveat (I'm not a core developer), I think filtering for tagged items within a single component (com_content in our case) would be much easier to implement and could be a good programming example for other components developers wishing to include that functionality in their extension.

[Webdongle Elgnodbew]

Hi Michael

"com_tags if you are creating a multi-component type view.  Otherwise you'd be trying to teach com_content how to render data for other components that it doesn't already have awareness of.

Ya, I know earlier you said this isn't a good idea (articles should only be rendered with com_content).  As is, that's not the case today.  Both search components can render standardized snippets of articles (and newsfeeds, weblinks, etc.) already so the same kind of concept would apply in com_tags if a view which could render all content items (regardless of "owning" component) was created."

Yep I understand that ... it's just that it will be a blog view and not connected with other components that I see it.  Yes other things are possible but the original concept was for displaying Articles (with the same Tags) in a blog layout.  That's why (as an end user not a dev) my preference would be from com_content.

Perhaps what we need now is a volunteer to do it and the 'powers that be' (don't know the name of the committee) to make a decision which method if it is to be done ?

[Michael Babker]

If you're going for a blog view with only articles having a tag then build it into com_content because it's only displaying com_content data.  No point in getting another component involved in routing/rendering in that case.

[Sergio Manzi]

A couple of questions for Thomas:

• How would you handle ordering in your "Multi-component Tags Blog" view?
  
  
• Which display options will be applied to each displayed item? The "Global component options" or the "Item options"? Could this be made selectable? (You know I'm very much opinioned about that...)
  
  
• Do you foresee possible unexpected side effects (routing & al.)?

Thanks!

[Bakual]

Just to show what I mean as a proof of concept: https://github.com/joomla/joomla-cms/pull/10242

Display options can be implemented easily based on the components global and item parameters, but only very limited based on menu parameters.

[Bakual]

Ordering is done the same as for the current tag view layouts. The layout doesn't do anything with that, that's the model who decides on that. The layouts just display the data the way it is given to them.

I would follow the way we have in other places as well. Take both and merge them, giving precedence to the item options.

There will be no unexpected side effects at all since it's just a regular layout file for a tag view. Routing will be the same like in the other layouts of the same view.

[Webdongle Elgnodbew]

Hi Bakual

Not a bad effort ...

In the menu item edit screen ... The 'Options' Tab is good and the last 4 Tabs match those of the Featured/Category Blog menu item type.  But the 'Category', 'Blog layout' and 'Options' Tabs (found in the Featured/Category Blog menu item type) ... have been replaced by Tabs not related to displaying content in a Blog layout.  This makes it impossible to replicate the layout of a Featured/Category Blog menu item type.  Also it is not what a user would expect.

I suspect that the wrong tabs is a result of using com_tags instead of com_content.  But if it isn't then replacing the wrong Tabs with the correct ones so the Category Options for Category Title etc.  the Blog Layout Tab for the columns etc. and the Options Tab for the Linked Titles etc. ... would make it as expected.

[Sergio Manzi]

Hi Thomas,

On 2016-05-04 23:38, Bakual wrote:

Ordering is done the same as for the current tag view layouts. The layout doesn't do anything with that, that's the model who decides on that. The layouts just display the data the way it is given to them.

That means we only have:

• Title
• Number of matching Tags
• Created Date
• Modified Date
• Published Date

A lot less than we have in "Category Blog" and particularly missing is (for obvious reasons) "Article order", so to impose a particular order one should resort to "hack" one of the dates fields.

I would follow the way we have in other places as well. Take both and merge them, giving precedence to the item options.

That would be right, but if I'm not mistaken this is not what's always happening "in other places" (If you remember, we have a discussion still open about that in https://github.com/joomla/joomla-cms/pull/9801)

There will be no unexpected side effects at all since it's just a regular layout file for a tag view. Routing will be the same like in the other layouts of the same view.

Yes, now that I've seen your code that's pretty clear.

I've also commented in https://github.com/joomla/joomla-cms/pull/10242 as it seems that for com_content only the introtext is displayed. I don't know if this is "by design" or a newly discovered bug in com_tags.

I'm cutting all the cited text below or this thread is going to explode!

Regards,

Sergio

[Sergio Manzi]

Michael,

I'm T_R_Y_I_N_G to do something along that lines, but the first conceptual obstacle I'm facing is that if I'm going to introduce a new specialized model/view for selecting com_content items based on tags, then I should also write a router for that, right?

It could be something like:

$link = 'index.php?option=com_songbook&view=tag&id='.$id;

but the problem is, how can I do that if I'm willing to handle multiple tags?

Thanks!

Sergio

[Sergio Manzi]

oops... com_songbook comes from Lucas component, in our case it would be com_content, of course!  :-)

[Sergio Manzi]

Does this commit:

https://github.com/joomla/joomla-cms/commit/80f110eca925eca629a05b50555936bfc094ac69

have something to do with our issue?

I can't find a corresponding PR/Issue on GitHub... Is this normal?

[in...@weblinksonline.co.uk]

Dont know

Download the zip from staging https://github.com/joomla/joomla-cms and install on localhost and check

[Sergio Manzi]

will do... tomorrow... (no need for downloading I have my local GitHub clone kept in sync with staging...)

[brian teeman]

The commit you are referring to is https://github.com/joomla/joomla-cms/pull/8846