Comcode link parsing is not guaranteed when using WYSIWYG due to a high degree of complexity regarding different parsing scenarios. Wherever possible (i.e. when direct Comcode is not used) we want to avoid doing a full Comcode scan of the HTML, because it is possible for it to conflict, or break reasonable assumptions by the content author, and Comcode doesn't actually recognise HTML properly to resolve those kinds of conflicts or know what the user intended.
One specific scenario is we will skip link parsing if an explicit <a> tag is already in this code. As we take this as a signal that the written URLs have been put there to be displayed literally without parsing.
You shouldn't think of the WYSIWYG as laid on top of Comcode, you should think of it as an alternative to writing Comcode except when you actually want a Comcode tag (in which case you can build that visually).
Automatic link parsing, and some other minor Comcode features, are not guaranteed to work when using the WYSIWYG editor. This is due to a complex set of conditions for what depth/type of Comcode parsing Composr goes into. These conditions are designed to minimalise corruption through incorrect or unnecessary assumptions made by Composr.
You should use the features of the editor to explicitly mark up your content as you want it and think of it as mainly an alternative to writing Comcode, rather than a supplement to it.
To me at least then, the feature is inconsistent. If it's not going to be fixed, it should be removed and it should not have any form of automatic URL to link converting. It degrades UX quality for Composr.
It's more subtle than that though. If someone pastes a YouTube URL they will expect that to show as an embedded video, and they can't mark it up as a hyperlink because it's not. But, if someone explicitly sets one link, but writes another out literally as a written example of what to type, they would not expect their written example to parse.
So it's not inconsistent, it's just a set of complex rules that do their best to optimise a difficult situation.
It's fine. The issue was there was a link in the text I copied and pasted to the WYSIWYG, so that probably triggered Composr to not parse any other links automatically.
I still feel this is a UI / UX issue that can be improved though. We can't assume users will know that if one link is explicitly included, then it disables automatic link parsing. I think there should be another way to do it. For example, instead of automatic link parsing, perhaps make it semi-automatic instead (the user would have to, say, highlight text to inspect and then click a button to automatically parse the URLs to links in the editor prior to submitting. If they don't do this, then URLs remain plain text).
That doesn't cover the case of YouTube videos though unfortunately, as those would need marking up with a Comcode media tag, which means a lot of heavy work trying to merge the Comcode and CKEditor UIs.
What we could do is make it tell you whether it has done a Comcode scan or not. And also let you explicitly say what kind of scan you want. I'll add a separate issue for that.
One specific scenario is we will skip link parsing if an explicit <a> tag is already in this code. As we take this as a signal that the written URLs have been put there to be displayed literally without parsing.
You shouldn't think of the WYSIWYG as laid on top of Comcode, you should think of it as an alternative to writing Comcode except when you actually want a Comcode tag (in which case you can build that visually).
Automatic link parsing, and some other minor Comcode features, are not guaranteed to work when using the WYSIWYG editor. This is due to a complex set of conditions for what depth/type of Comcode parsing Composr goes into. These conditions are designed to minimalise corruption through incorrect or unnecessary assumptions made by Composr.
You should use the features of the editor to explicitly mark up your content as you want it and think of it as mainly an alternative to writing Comcode, rather than a supplement to it.
So it's not inconsistent, it's just a set of complex rules that do their best to optimise a difficult situation.
I still feel this is a UI / UX issue that can be improved though. We can't assume users will know that if one link is explicitly included, then it disables automatic link parsing. I think there should be another way to do it. For example, instead of automatic link parsing, perhaps make it semi-automatic instead (the user would have to, say, highlight text to inspect and then click a button to automatically parse the URLs to links in the editor prior to submitting. If they don't do this, then URLs remain plain text).
What we could do is make it tell you whether it has done a Comcode scan or not. And also let you explicitly say what kind of scan you want. I'll add a separate issue for that.