It’d be super great if these was available via an API call that could be iterated over time. That way we use it to identify trending topics/content.
If you can find the data that you are looking for at /admin/reports
, you can query the report through the API. Try /admin/reports/trending_search.json?category_id=all
for trending search terms. You can set the category_id and search period as parameters.
Ahh didn’t realise that was an open API call
Same thing for admin/reports/top_referred_topics.json?category_id=all
!
Everything you see in Discourse is an API by definition, as we are a JavaScript application that runs in the browser. See How to reverse engineer the Discourse API
Side note, this feels a bit like saying it’s self documenting code and I should just go figure it out. As a customer, rather than being told that it’d be great to have something added to the docs if it’s being added as an API. Even if it’s just a “this exists here” rather than a full breakdown, it’s a start.
As an open source community member and user, I totally get it’s open and accessible and I would be happy to make more PRs on the docs to expand what’s there.
It’s just finding the tricky balance between these two
The problem with documentation is that it tends to be speculative; my recommendation is to look at the network requests for the exact thing you want to do in the UI which is quite surgically precise
I can totally do this, it’s not a big deal for me technically.
As a customer, my feedback is that it doesn’t feel right that you are telling me I need to analyse network calls of the code in the browser to figure out functionality that could be documented.
We are going to expose /admin/reports
properly once it is ready and the reports inside it are properly documented and corrected. I think you just have to hold tight here while we clean stuff up.
Ahh great, thanks for the heads up