<> Embed function / Insert Media-popup
Kaspar
Moderator
Discovered that the Embed popup/flyout is a little weird.
(screenshots are from Vanilla OSS forum)
Clicking the [<>] icon and inserting a link - the "Insert" button is toned down (greyed out)
Removing a letter from the link(t removed in "https") - "Insert" button lights up.
Clicking insert result in "Request failed with status code 500"
(error expected...)
Putting the t back in - Insert is toned out again.
However, I have also tried removed g in .png or the a in uploads (and several other letters/numbers) and putting it back in
In that case the "Insert" button stays lit - clicking it results in this
I will try posting a comment to this thread with the above.
For reference, this is the link used in the above examples but I have tested with sevral links - same outcome.
https://us.v-cdn.net/5018160/uploads/529/K3HJJ0LJ53TQ.png
The same happens with a link to a post on the forums and a youtube video.
Difference is that the post and youtube video renders/embeds when "Insert" is clicked (after removing and reentering a letter or number in the link)
Removing, reentering:
Seems anything in "https://" tones out the Insert button
Seems anything after "https://" leaves "Insert" lit.
I do see some issues/pulls on github that mention embed but not anything fitting this - or I do not undertsand that is this ;-)
Comments
testing
That's a bug.
PR with a fix here
Yay, PR just got its 2nd approval.
Assume! that means it may make it into next release? ( as I recall next release is close, so it may be to late for that)
So I had branched
release/3.2with ourrelease/2019.010but my colleague @initvector will be the one actually handling the next couple OSS releases. There are a few bug fixes I plan to back-port to that release before it goes out to the OSS community though, and this will be one of them. Either that or we'll re-branch it entirely when we make our cloudrelease/2019.011.This next release has a branch new text formatting pipeline & a completed new embed system, along with a slew of deprecations, so we're trying to make sure the interfaces are finalized, and that it has adequate test coverage before passing it along to the community.
That merged PR was actually fixing a regression that wasn't present in 3.1, but the issue in the OP here has a fix that was merged yesterday as well: