Both ways should work, especially since the SEF converter does convert the array (as in "expected") to a comma-list (as in "steps to reproduce").

Please provide steps on how to produce this.

I added a description how to trigger the SEF convert to the main post.
I'm new to GitHub, so maybe I'm not using it in an optimized way... I'm sorry for this and appreciate any tips! E.g. I forgot to add a com_tags label when I uploaded the issue and now I don't find a way to add it any longer... maybe somebody may add it.
Should I translate the fix from the German forum to English or is it clear anyway (it's technically quite simple, I think, but maybe somebody has a better solution)?

Are you manually typing index.php?option=com_tags&view=tag&id=1,2,3? If Joomla generated this link, then please provide steps in Joomla how to reproduce.

The correct syntax is index.php?option=com_tags&view=tag&id[0]=1&id[1]=2&id[2]=3.

Thanks for replying back! The syntax you labeled "correct" is the array syntax which works as expected. If you provide this type of link to the Joomla Router in one of the described ways (as I did in a custom extension), it will be converted to the comma seperated list, looking as follows:
/component/tags/1,2,3
This list will be truncated to just 1 by com_tags (/models/tag.php; line 181), which was the problem that originally brought me to this issue. In the component itself, it is mentioned (see com_tags/router.php line 83), that the ids should be decodable in all three formats (single integer, array, comma list). Since the comma list actually does not work but is truncated, I opened this issue.
I'll attach a fixed version of com_tags/models/tag.php, just scroll down to the passage "MY FIX", it hopefully should explain itself via the comments:
components - com_tags - models - tag (fixed).php.txt
Maybe you have a better fix in mind?

@Waldbaer88 you can propose a pr yourself is easy https://docs.joomla.org/Using_the_Github_UI_to_Make_Pull_Requests

Where does it say that ID as comma separated values is supported? They shouldn't be because with Unicode Aliases enabled commas are allowed in aliases.

@SharkyKZ: It is said e.g. here (comment 1) and in com_tags' router, which converts the array to this format (components/com_tags/router.php line 83). If this is a general problem, I'll probably to unexperienced to solve it...
@alikon: Thanks, I'll see what I can do!

@Waldbaer88 In your issue description there is a mistake.

You wrote:

index.php?option=com_tags&view=tag&id[0]&id[1]=2&id[2]=3

But i think it should be something like this, with providing some value for id[0]:

index.php?option=com_tags&view=tag&id[0]=1&id[1]=2&id[2]=3

@richard67 You're completely right, of course, I corrected it.

@Waldbaer88 Beside this, I am against your requirement, because it is syntactically not correct. Defining an array as once would not be 1,2,3, it would be [1,2,3]. Or how else shall any parser see whether it shall be a single string "1,2,3" or an array? Shall the parser read the mind of the guy who has set up the web site?

// ID in com_tags can be either an integer, a string or an array of IDs

It does not state comma separated. Please use the correct format. There is nothing to fix here.

@richard67 Nice idea, but the format being simple 1,2,3 is not my idea, but already implemented in parts (as written above) - just not consequently as it looks. I see two solutions to this:

1. The component gets a fix to be able to read id=1,2,3 as well as id[0]=1&id[1]=2&id[2]=3 (easy and without problems that did not exist before as far as I can see it; I'll add a pull request for this soon)
2. The router gets a fix to no longer convert id[0]=1&id[1]=2&id[2]=3 to 1,2,3. This will not help anyone who may have used the 1,2,3-syntax (as I said, not my idea), but will at least make SEF Uris with multiple tags possible.
   @Quy The format described is the router's idea, not mine. An Uri coming out of the router should work, shouldn't it?

You are not reading/understanding the code correctly. I don’t know how else to explain it.

That may be - as I said, I'm not that experienced, sorry for that.
Maybe you can explain to me why an array-link (e.g. index.php?option=com_tags&view=tag&id[0]=1&id[1]=2&id[2]=3) generated by an extension gets overwritten automatically to /component/tags/1,2,3 (EDIT: /component/tags/tag/1,2,3) which displays just the same as /component/tags/1 (EDIT: /component/tags/tag/1)? Is this really intended?

/component/tags/1,2,3 Are you sure as I am unable to reproduce this URL?

Sorry, should be /component/tags/tag/1,2,3. What does your result (EDIT: of JRoute::_('index.php?option=com_tags&view=tag&id[0]=1&id[1]=2&id[2]=3')) look like?

Sorry I’m not at my computer to test to let you know.

No problem, just take your time!

@Waldbaer88 To me it seems that /component/tags/tag/1,2,3 is a SEF URL, or am I wrong? If I am right: What happens if you switch off SEF URLs in global config?

@richard67 You're right, of course it's a SEF URL (just as I wrote in the topic), that's what JRoute::_() is for, isn't it? So yes, the automatic conversion can be turned off via the global setting, but the link it generates should work with it turned on, too, doesn't it?
The actual conversion of the array seems to be done by the line I linked to above - at least I can change its format by changing that line (e.g. do the implode using '/' or 'foo').
@SharkyKZ That brings me to the idea that we could easily replace this comma by something else to avoid the problem you mentioned with the unicode aliases. Any suggestion?

@Waldbaer88 I may be wrong, but as far as I know, the router is not there for SEF only. I wanted to know what happens when you switch SEF off in order to see if the behavior with and without SEF is the same, for diagnostic. I never said that anything should not work with SEF on. The opposite is true regarding interpreting that query parameter: It should work in the same way with and without SEF URLs, and that was what I asked you to check.

@richard67 Thanks for explaining - I'm sorry, if I sounded rude, I appreciate your thoughts! According to the documentation, the SEF/"humanly readable URL"-conversion is at least the router's main purpose (JRoute and Route class docs) and I did not find anything additional until now. Anyway, I found another (not connected) little problem with my custom extension by turning it off, so thanks again for the idea!

Why not create a menu item for it so you have friendly URLs instead of /1,2,3?

@Waldbaer88 adding comma separated list to and input parameter makes less sense especially if we already support the array syntax and support it in the sef router.

So you why don't you use SEF urls?

In the meantime I close this because I don't see a good reason for adding this feature.

Re-open please. Router does set SEF segment as a comma-separated list of IDs. I.e. if you build an URL like index.php?option=com_tags&view=tag&id[]=2&id[]=3 the SEF URL is index.php/component/tags/tag/2,3.

Tag component frontend is broken in general due to multi-tag capability in tag view. I looked into this in the past and to me this capability doesn't make sense. E.g. how to handle access levels, how to set metadata when multiple tags are used?

Re-open please. Router does set SEF segment as a comma-separated list of IDs. I.e. if you build an URL like index.php?option=com_tags&view=tag&id[]=2&id[]=3 the SEF URL is index.php/component/tags/tag/2,3.

Oh yes the router doesn't explode the ids back to an array on parse that should be fixed.

Oh yes the router doesn't explode the ids back to an array on parse that should be fixed.

Anyone here who wants to fix this?

I'm glad that my problem finally got clear. I'm sorry if I did not succeed in communicating this earlier...

I remember having added a pull request some days ago (following the tutorial alikon pointed out) fixing this problem by inserting some lines here. I also used #24980 in its name but I don't find it any longer. I did not receive any comments on it; may it have been deleted or might there have been a technical problem and it was not submitted correctly? I can resubmit it if you wish, but if it got deleted by purpose I don't want to make you more trouble, of course.
If somebody has a better solution or this is the wrong place to fix this, I'm open to your suggestions of course!

@Waldbaer88 We do not delete pull requests. As far as I can see your pull request did not come through. You can check your pull requests at this link:
https://github.com/joomla/joomla-cms/pulls/Waldbaer88

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

Please test PR #25065