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

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

I see a few other possibilities for solving this issue:

We have a landing page for our site built in Reactjs and our Discourse forum is one half of the total platform. I want users to be able to search the forums from that landing page so they can go directly to where they want.

We actually load the Reactjs landing page inside of our Discourse (for unrelated reasons), so Discourse is open in the same window and the search function is in the header, but we want to pull it into the Reactjs page.

These are the three options i can think of:

1 - As Discourse is already open i was thinking perhaps its possible to simply mirror whatever is typed into that search bar into Discourse’s search function.

2 - Perhaps its easier to send the search call to Discourse via API

3 - Discourse uses url’s in a very clear and open manner. Would it be simpler to just create a new function which searches by navigating to the search url? For example Search results for 'homelessness order:latest' - Public Happiness

with option 3 the parts that would change in the search function is the word ‘homelessness’. The main issue with this method is that i don’t believe the function can support multiple words

If you were tackling this task which one of those would you try, or something totally different?

@Marvelxy I thought of a hack to get this feature working, although it would need to be improved in the future. What do you think of this:

When a user clicks on the top search bar the search feature at the top opens instead of the expected behaviour where they’d be typing into the text entry box.

Even better if we can also inject a # into that search box as that is how users search by category or tag (advanced users can simply delete the hashtag).


A script saying something like:

  • User clicks on X element in page

  • do Open Search bar and type ‘#’

From a user point of view they’d just be typing into a different field entry box than they clicked. I think that would be intuitive fairly quickly, although they might be a little confused the 1st time it happens.

We could also tell Discourse to open the search popup as a large modal window with the search function centered. That would remove the initial confusion for the user as their click is is not opening something in an unexpected location anymore.

I’ll make a mock-up

Something like this would be sufficient, with Discourse opening the search popup in the middle of the page and it opening with a # in the text box.

The ideal solution would be closer to this:

But i believe that’s very difficult to achieve as we’d be asking Discourse to track an element that is loading on an external site in an i-frame, and open it search dropdown exactly on top of it. The 1st solution in this comment would be easier as is wouldn’t have to track that element, just open it as a big arse white modal in the center of the page.

Here’s a reply i got from Renato in a DM.

if you’re using an iframe to show the React app, I’d try your first option, reusing the Discourse search from inside the iframe. You can use the postMessage API to listen to events on a Discourse theme component, where you probably can manipulate the native search, and send those events from the iframe. It’s just an idea though, would need to try to confirm it’s doable.

That’s cool, i wasn’t aware we could sniff what a plugin was doing, grab the native search box and pull it into Discourse to combine the two search boxes.

@AndyatFocallocal, Do we have a full search page I can get the codes from? Or I have to use the one on the dropdown?

1 Like

I couldn’t find a separate page for the search, just the search drop-down with advanced selected.

I think that the search function in Discourse is basically a command line/URL modifier. When you click advanced, type something in or click boxes, all it does is add pre-defined code to the URL. You can see it live if you tick a box the URL changes ready for you to hit enter, so we’re just copying parts of that function directly or opening the drop-down centrally when users type there.

1 Like

Wait, I’m wrong.

1 Like

Nice! I will try to work eith the code on the search page. I will pit it on in iFrame. I hope it works.

The issue you might run into is that we already have an i-frame active on the whole site with the Docus plugin. Perhaps it’ll be ok, or you can work through the existing one. Tbh I don’t know much about whether i-frames can coexist successfully

Hmmm… I’ve never placed an iframe inside another iframe before. Let’s see how it goes.

1 Like

Btw, notifications are working great right now

1 Like

That’s awesome!

I’ve been looking into this feature, and I think we can link to the search page instead of reinventing the wheel of creating the search on the homepage. The search page is much robust, Search results for '' - Public Happiness, an I think we should use it.

These are my findings so far:

  1. The iFrame method looks difficult to work on locally because fl-maps is sitting outside Discourse
  2. If I build a custom search component that redirects to the main search page, it’d be a total waste of time. I suggest we link to the search page as I’ve mentioned above.

We can discuss this tomorrow.

1 Like

Sure, I agree.

It’s a bit if a pain tech wise tbh, the designers thought it worked well design wise.

The issue is that typing in what users want to see is the primary step we want when they arrive on the platform, so both searches should function on the first step rather than being on a separate page.

Users do have access to the Global search function on the home page, it’s just in the top corner rather than central.

Can we just mirror what they type into the top search bar? Or open it when they click the middle Global search bar, although I imagine if a different element from the one you click opens it might be confusing


Here’s my suggested hack to get this working this for now

Turns out mspaint doesn’t allow a dotted line which was what i planned on using to show there is a transparent button over each search bar.

The advantages i see with this temporary solution are:

  1. Its quick and simple
  2. It isn’t too far away from our existing UX path
  3. I can use the pre-populated text in the search bars to explain to users what will happen when they click, and what they can do on the page it takes them to

Hello @AndyatFocallocal ,

I have an incoming pul request for this. Where should I open it to? Master or deploy-phm? I forgot :man_facepalming:

All three, we’re keeping them all at the same state right now until we have the testing server up and running (although BTM isn’t compiling).

1 Like

Merge request created!

1 Like