Find the Discourse API for the 'tagged' search bar and pull it into the new homepage

By right clicking an element in Discourse you can find its API directly in the pages source code.

It is the ‘tagged’ search bar we want:

Please be aware that the ‘all of the above tags’ box needs to be selected or it won’t work correctly.

If its difficult to make it work another solution would be to add the main search box and have ‘tags’ typed in automatically when a user clicks it, and a ‘+’ key. You can see the advanced filters actually works by adding text to the main search box itself: ‘tags: backlog+webdev+reactjs’

Here’s is the documentation on working with Discourse API’s: Integrations: Discourse API

1 Like

Hello @AndyatFocallocal , I’ve been having challenges trying to get the search API. Can you send it if you can? So I don’t spend too much time looking for it.

1 Like

It looks to me like you need to install the discourse gem to be able to search for the api’s. I don’t have a local version running so i can’t try that out, but i’ll do a bit more reading. don’t forget you can ask in the forums how to get a hold of that api code.It was my understanding that it was all just there in the source code of each page.

1 Like

I don’t really understand the Gem above, but i followed the post on ‘reverse engineering the api’ and got this:

Its basically just telling you what the url is that it is searching. That mean the the search bar can actually be a browser bar in disguise. When the search icon or enter key is clicked it needs to load the page:*webdev

For our use case it would need to load:

https://[the site user is currently on]/search/query?term=tags:[words a user enters separated by *]

I guess that means the search bar doesn’t need to be pulled in via API at all, it just needs to load that page. I’ll look more into it as we will need to pull in other stats later on in this build.

1 Like

That’s also the 1st of the 3 items we need for pulling an element in via API: How to reverse engineer the Discourse API - developers - Discourse Meta

If we were to use API the second needed item, the payload, is here


(although i don’t know what it wants from that information)

I’ll try again on some stats in the admin area

Ok, now i’ve inspected element on the total number of page views.

I had to search through a few names as all the elements are the network > fetch/XHR tab, but after clicking on a few i found one which mentioned ‘consolidated page views’ in it

I see that item two, the payload method is ‘GET’

Item 1, the request url is:[consolidated_page_views][facets][]=prev_period&reports[consolidated_page_views][start_date]=2021-12-24&reports[consolidated_page_views][end_date]=2022-01-24&reports[signups][facets][]=prev_period&reports[signups][start_date]=2021-12-24&reports[signups][end_date]=2022-01-24&reports[topics][facets][]=prev_period&reports[topics][start_date]=2021-12-24&reports[topics][end_date]=2022-01-24&reports[posts][facets][]=prev_period&reports[posts][start_date]=2021-12-24&reports[posts][end_date]=2022-01-24

1 Like

I’ve asked where to find item 3 here: Discourse API Documentation - #317 by Drew-ART - developers - Discourse Meta

1 Like

I posted as its own post and got the solution: Discourse API Documentation. Can't find the parameter sent - #3 by Drew-ART - support - Discourse Meta

Also, Good news! We have the venue for the Hackathon. A WW1 Fort in Amsterdam

I’ll check contacts and see if we can make it happen. It would be to launch the crowd action climate version of our app, which is probably the most urgent one with the widest appeal, so it’s a good choice to begin with

It’s a cool venue

There will be one in July and one in March. In the Netherlands you need to apply for an event permit 8 weeks before an event. We can get around that if the 1st Hackathon is a ‘planning’ Hackathon planning the second one. It can be functionally the same though, just with some focus on advertising and creating a plan for the 2nd one

1 Like
1 Like