Isn't it the expected result that an article (that's not assigned itself to any com_content menu item [article, category]) is displayed on the home page?

ItemID108 is a com_tag menu item. Thus I don't expect to see an article (com_content view) there.

We tell users that they can choose which menu items to show modules on. This breaks that. Currently it's more like "You can choose which menu item to show modules on.... oh, unless, that menu item uses com_tags."

Surely if a user says that they want a module to only show on menu item X, that we should only show the module on menu item X. Currently I have modules that are set to only show on my homepage, but Joomla shows them on almost every page of my whole website, regardless of which menu item they click.

You wouldn't expect to say "Only show this module on the home page" and have it show up on every other menu item that was a category blog. It doesn't work that way for any other menu item type. Why would it be different if the menu item uses com_tags?

It seems pretty clear to me, that this breaks the whole system of users being able to assign module visibility by menu item. As far as I can see, this is neither expected by users, nor useful.

The fix is simple. Just have com_tags list articles using it's own ItemID just as com_content does.

And what's about tagged categories, newsfeeds, contacts, 3rd party extensions...? They're all listed in a menu item of type Tags » Tagged Items.

The fix is simple

Provide a PR! At the moment I don't see an easy way to implement that (maybe one of the profs here?). Each component uses its own router. Com_tags calls them to get the specific URL/route for an item. .

And what's about tagged categories, newsfeeds, contacts, 3rd party extensions...?

All I know is that com_tags already apply an ItemID, and we know the ItemID of it's menu item, ergo using the right ItemID (which is known) should not be hard.

Provide a PR!

Clearly, if I knew how to code, I would have fixed this already instead of spending so much time and energy trying to report, demonstrate and explain this bug. Accordingly, telling a non-coder to provide a PR is not helpful (in most cases they're not even likely to know what PR stands for). I am not blaming anyone for anything. I am merely reporting a bug, where the system is working differently than how the documentation describes and doing everything that I can to help the relevant developer to fix this, from detailed system information, triage info, illustrations, a demo site etc.

At the moment I don't see an easy way to implement that (maybe one of the profs here?).

All we need to do is get the ItemID, exactly as other components like com_content already do, and use that in links listed by com_tag. What is particularly complicated about that? As far as I can see it's just appending / replacing one string with / to another in the HTML output.

Each component uses its own router. Com_tags calls them to get the specific URL/route for an item.

Yes, I managed to figure that much out, looking at the files in the com_tags folder. I tried bringing over the relevant looking code from com_content, but as I said before, I'm not a coder and had no idea what I was doing. I wasn't surprised at all when it didn't work and I had no idea why. :)

Just to clearify: I wrote "Provide a PR" because you wrote "The fix is simple.". So I thought you know the solution that we could test then. For me it's too complicated to change several routers.

You say it's a bug. I think it's not but rather the expected result. Some of my pages count on this current behavior.

Let's wait for someone more clever than we are to come to a decision

So imagine a user chooses for modules to "Only show on these menu items" and only ticks the menu item "Home page". Are you really saying that they should expect that module to appear on other unrelated menu items they didn't select?

If so - and this isn't considered a bug - then I'm clearly missing something and the documentation needs to be updated.

Resetting priority according to our standards https://docs.joomla.org/Priority

Currently, it's advertised that users can choose which menu items to have modules show up under. If they have a com_tags menu item, it doesn't work and links clicked on bring up the modules for the home page instead. How is this not "causing a major loss in advertised function" meriting at least "Medium high"?

On a side note, when filing a bug, it says that if there is loss of advertised function to mark "Urgent", which disagrees with that docs page linked to, which is why I filed as such. It would be useful to reconcile the two.

I've lost quite a few hours due to this and I agree with @Bugsbane that is a bug. Displaying the content in the context of the home page makes only sense with certain home page layouts but not in every case. Our website uses a module to display a large banner on the home page. It doesn't make sense for it appear above most of the content that we have on the site.

I'd be grateful if this could be fixed so that the behaviour is consistent with Category Blog menu items.

Unfortunately because of the way that com_tags works this will not be possible in the current joomla code base.