Why are oneboxes cached into posts?

One of the things that bother me a bit about Onebox is that the content of Onebox is cached in the post and does not change by changing the fields until the post is edited.

For example, we create an OneBox from an account, and a week later the user changes his biography …

Re-downloading the Onebox every time the page was viewed would slow things down quite a bit. It would be silly to re-download a onebox that never changed. There’s no way to know that it’s changed, so forcing a post-rebuild (with the wrench or by editing) is the way to go. If you knew that some category was likely to have oneboxes you want to update regularly, you could create a plugin that would, say, rebake all the topics in the category on a daily basis.


In general Oneboxes are cached because you want to rate limit scraping of external sites locally to prevent you being banned! (but sure caching has a performance benefit too!) To get around the cache on the odd occasion you need to just add a fake querystring like:


or something at the end of the link.

That will cause a refresh.


Onebox caching is absolutely necessary for external content and there is no expectation that it will be refreshed. I meant internal Oneboxes. As I mentioned in the example above, the Onebox created by a user is expected to be updated on all sites by changing the person’s biography.

Also, Oneboxes should be cached for internal content, and this is necessary to reduce the load, but maybe it is not bad to have internal Oneboxes indexed somewhere, and if the source record changes, an update task will be scheduled for them.

In the current situation, if the discourse updates the formatting of the Onebox changes (for internal cases), in the old posts it will still be displayed with the same pattern. This problem will be solved if we cache the content of the Onebox as JSON in the post and format it by the client.