Custom separator also used for string concatenation

I've already added my working code to the fork branch. I also included a test method analogous to testSeparator, but I couldn't find a good test case for creating metatags without having tokens. Maybe somebody has an idea.

Thank you for pointing out this flaw, and yes, there needs to be a distinction between the two operations.

I turned your issue fork into a merge request and it has triggered the testbot, let's see what the tests say.

Changing this to a bug, because it's a regression on existing functionality, and this blocks the 2.0.0 release.

I wonder if it'd be better to just identify where values are combined and change those lines to use commas to join the strings instead of using the custom separator?

Let's go with my comment above and fix the output so strings are concatenated the old way.

Going with a fixed comma to combine results into a string is a valid option, indeed. I may have gotten carried away making it configurable.
Of the top of my head, I can't think of a case, where we actually need a configurable value. Especially, as it is a global setting.

I would still use MetatagSeparator::getCombinator or similar to get the value, even if it is fixed. This would allow to easily add a configurable option or alter it in the future.

I think using a method to get a fixed value is overdoing it, we can just do commas for now.

I've added a second branch where the combinator is a hardcoded comma.

Thank you. I'll review that today.

DamienMcKenna → closed merge request !84

Committed. Thank you!

Automatically closed - issue fixed for 2 weeks with no activity.