add automatic filter to search results with documentation you have currently open

[tmotyl]

User is using the search box on certian documentation (e.g. changelog or ext:news).
He is putting keyword in the search box.
he expect to have a facet with current documentation preselected and results shown only from this documentation

[brotkrueml]

Hmm, I am not sure, if this is the way it should work: Searching directly on "docs.typo3.org/" results from all manuals/versions are displayed. Using from a search box in "TYPO3 Explained" I only get results from this manual in that specific version.

At least, the context should be given near the search box (above, below, before, after) so this is visible to the user, like "Searching in TYPO3 Explained", "Searching in News" or "Overall search". And no: a placeholder is not accessible.

My 2 cents ;-)

Edit:

• Of course we then also need a link to the overall search to be explicit about that feature.
• And this contradicts the current search in the docs on the left side. I am fine with that. But then we should render all manuals in all versions again to get rid of that search box. And I will wait until it is decided if this is the way to go to implement the search box on the left side for the new rendering (or not).

[linawolf]

The idea was to have something like the search on github:

So that uppon searching you can pick the context you would like to search in

[linawolf]

Search in this manual all versions,
Search in this category (official docs, or extensions, ...)
Search all over

[brotkrueml]

So, some JavaScript thingy with an Ajax backend. Okay, I would love to see a prototype for the frontend beforehand.

[brotkrueml]

Search in this manual all versions, Search in this category (official docs, or extensions, ...) Search all over

Searching in all extensions/versions is mostly not what you want. Just my 2 cents ;-)

But it does not hurt.

[linawolf]

From the search side of things we would need these tags. So that we can search for manual:TYPO3-Explained and filter by manual. The rest about the frontend is independent from that

[brotkrueml]

Yup, but the GUI is an important part. And: no user will remember how the manual they is searching for is written correctly to type it manually. So we need something like a list with checkboxes/radios (at least for the manuals) and/or a suggest thingy.

[linawolf]

true, just saying where the manual is not rerendered it keeps working as-is and you can then put in more facets on the search page itsself

[brotkrueml]

I am looking forward to this. And as already said, I postpone the local search for the new rendering until it is decided/implemented that this is the way.

[soee]

I have spent some time on this task, mostly thinking about concepts and how they could work, as well as discussing on Slack with members of the documentation team. I proposed to create some draft how the new search could look. Here are the drafts:

This is a very general concept at the moment, and there are many edge cases that need to be discussed. I have not included any filtering by versions here - maybe they should also show up in some form (perhaps a separate filter). Anyway, this is how I see it, but it still needs many improvements. From my perspective, this single task should be discussed in the context of a separate/dedicated budget.

What has to be done here:

• we need a technical draft of how the whole search process should look, what filters we will offer, how they will work, etc.
• extend/modify how and what data we are indexing, as we will need more detailed information to be indexed to support extended suggestions
• implement on the backend side advanced suggestions handling (endpoints to handle requests from the frontend), where we receive filters from the frontend, parse them, and build an ES query to fetch suggestions, then return them to the frontend
• build a new search interface on the frontend side as a component (search box) which will process data received from the backend, render forms, handle requests and responses from the backend asynchronously

[brotkrueml]

@soee Thank you for your work :-)

Just one remark for the records: "core_ext" and "ext" should be merged to "ext". Reason is: a sysext can be moved to user land (like "sys_action") and a user land extension can land in core (like planned for content_blocks for v13). This may then cause confusion.

[linawolf]

however system extensions are part of the official api, third party extensions are not.

[linawolf]

solved by #47