The bug happened because the hashtag link won't get parsed by the
extension. This is desired for mentions because you don't want to
re-notify a user if you haven't updated the text in which you notify
somebody. For hashtags this is undesired and would lead to transforming
the hashtag link into a normal link on the next edit of a post.
This adds consistency: The mention links with `@` was implemented
that way already. Instead of parsing the URL, we add some redundancy and
add another attribute: data-hashtag-id
So, what characters are valid for html attributes?
Read: https://stackoverflow.com/questions/925994/what-characters-are-allowed-in-an-html-attribute-name
Thanks to @Tirokk, who added some validations on the hahstag ids, I
think we are all set. If you try to write a hashtag with a `"` double
quotation mark for example, it gets automatically replaced with a valid
hashtag. If someone wants to send us invalid hashtag ids to the backend
directly, the regex there would filter it out.
I believe this is obsolete code. Could someone double-check?
@mattwr18 I tried to see any difference to `master` and I couldn't. Did
I miss sth.?
For context: During my work on https://github.com/Human-Connection/Human-Connection/pull/1517
the webapp was complaining about missing mutations when I changed the
dropdown.
- set items to the full list of hashtags or users to avoid unnecessarily reassigning the items variable based on suggestionType
- refactor tests to trigger onFilter, which calls filterSuggestionList, then check that it returns a maximum of 15 items both for queries and empty queries
- fix description with incorrect type(users, instead of hashtags)
- return 15 items, not 14
Apparently the default pasteRules of tiptap interfere with the
pasteRules of a Link (in our case an Embed node). Consider this example:
https://de.wikipedia.org/wiki/Yin_und_Yang
Depending on some random conditions, tiptap might parse the `_und_` to be
italic because it's wrapped with underscores (markdown syntax). The
result is:
https://de.wikipedia.org/wiki/Yin # link
_und_ # italic
Yang # plain text
So let's remove the default pasteRules of `Bold`, `Strike` and `Italic`
marks respectively to prefer our Embeds. Who is copy+pasting from one
tiptap editor to another tiptap editor anyways?
* Add target="_blank" (on embeds only!)
* When pasting a link, the cursor position is moved after the paste
* Can't reproduce a link slipping into the embed in front of it
@Tirokk it is an unpleasant side efffect that mentions + hastags appear
differently on Edit+View. That's because they don't get parsed from
HTML, it's a one way, they are write only. So, when viewing content,
hashtags and mentions appear as plain links. I don't think I can do
anything about it.
Regarding some links not being embedded: Only those links that have an
oembed provider in this file:
f44d0f1f96/backend/src/schema/resolvers/embeds/providers.json
...will be embedded. Your example `http://backreaction.blogspot.com` and `https://de.wikipedia.org/wiki/Yin_und_Yang`
have no embed provider and won't be embedded.
We would have to add oembed providers to this list if we wanted to embed those
links, too.
