Not a bug Two issues related to unfurling URLs

[Chromaniac]

Affected version

XF 2.x

First one is really weird.

Here is what happens.

1. I post a link in a post. I publish the post. Link is unfurled.
2. I edit the post and edit just the link bit. Publish the post. Updated link appears as linked url and does not get unfurled.

I am not sure why XenForo does not update the URL on editing the post if I made change to an existing URL. If I add another URL during editing, it gets processed just fine. I did some more tests and realized that if you manually create a link with [URL unfurl="true"] bit, it is never processed during publishing. unfurl="true" has to be added by XenForo itself and this is where the link is processed and the content is added to the database which is then used for that URL and any future mentions of the exact same URL in future.

This creates the second problem. Folks migrating from other platforms to XenForo have tried finding and replacing [url] to [URL unfurl="true"] only to see that these links never get unfurled. I have considered doing the same for my historic links to get them unfurled. But as mentioned above, these would never get processed. Even if the post is edited and saved again. User would have to kill the URL bbcode completely to get XenForo to process these links.

When the unfurl feature was announced, one of the devs mentioned that XenForo would periodically update the URL. I have seen this happen and it's useful. But I have also noticed that the links are never cleaned from the database. If I added a link but removed it, it would continue remain in database for ever. I can see that this is a more efficient way to deal with unfurling URLs. But it would have been nicer if unfurl database was processed similarly to oembed content. Where you can set it to be cleaned up periodically and refreshed on a future page load. If the user has not set the caching settings to be permanent. Looking for feedback from the community and thoughts from the developers. Cheers!

 

[Chris D]

Ultimately this is just how the feature works.

There's a bunch of important stuff going on behind the scenes which enables [URL unfurl="true"]<url>[/URL] to be converted to the unfurled information when the thread is rendering.

In short, you can't just edit the link part of the tag because it skips the code which does all of the necessary things to fetch and save the information we need to display that link's unfurled info.

If you're aiming to modify the link, you need to delete the entire [URL] tag and replace it with just the link (keeping it on its own line) - this is the same process you follow when creating the post in the first place, you post the link, we detect it, we fetch the info and we store all of the metadata that we need for the system to work.

We've never intended to have any sort of migration path for existing URLs to be converted to unfurls and to be honest I'd actively discourage it. On particularly old posts you may be converting what was a simple link into a picture, title and description that no longer represents what the content was originally at the time the post was originally created.

For example, imagine if some URL now redirects to adult content and your thread pages may now be laden with images and wording from adult content which may not have been the original intention.

Of course if a previously valid link now points to undesirable content people may click on it and be faced with that, but the content might not be something you want appearing in search engine results via an unfurl.

Finally in terms of deleting the unused ones, at the end of the day it's a couple of bytes in the database and doesn't amount to anything significant. We don't track the usage of unfurls so there's no metric that exists for us to detect when it is no longer in use (it could be in use in multiple pieces of content) so there's not a lot we can do there.

Ultimately nothing here that is a bug but if you have further need to discuss changes that'd be best done through suggestions in the suggestions forum.