Need ability to get a list of pages matching multiple tags



6 years ago
6 months ago


(Reporter: sheppy, Unassigned)



(Whiteboard: [specification][type:feature])



6 years ago
What problems would this solve?
We have, upcoming, work we'll need to do with building templates that build lists of pages given a set of tags that need to match. For example, "all pages that are tagged with both 'Web' and 'Reference'". Or all pages tagged 'Web' that are also marked as needing Editorial review.

This will be used to build our zone system, to some extent, from a content side perspective, as well as for other landing and menu pages, special to-do list pages, and so forth.

Who would use this?
Template developers, especially me.

What would users see?

What would users do? What would happen as a result?
Ideally, we'd have a wiki.pagesWithTags() method that accepts an array of tag names, and returns a list of all pages matching those tags. Bonus points if the syntax is:

pagelist = wiki.pagesWithTags("/some/subtree/of/mdn", ["array", "of", "tags"]);

Is there anything else we should know?

Comment 1

6 years ago
A specific use for this came up during the WebAPI documentation meeting just now. We would like to use this capability to present a list of APIs that are available only in Firefox OS, badged based on which versions of Firefox OS they're available in.

Doing this will require that we be able to pull a list of pages from under Web/API that are tagged with "Firefox OS Only" (or similar) and another tag indicating which version they're available in.

Other cases similar to this are likely as well.

Comment 2

6 years ago
As a matter of reference, I've created this macro:

This is using the json feed for a review list and pulling out matching pages. This works, but is likely not as efficient as doing that lookup server-side. Also, it probably becomes less reasonable if you're going over every page on MDN looking at all their tags. :)

Comment 3

6 years ago
This will help us build landing pages, sidebars, and the like for zones, so adding as a blocker.
Blocks: 861991

Comment 4

5 years ago
this enables a et of pages with ALL of those tags.
Priority: -- → P2


5 years ago
Component: General → Tags / flags

Comment 5

5 years ago
It's worth noting that the more capable this feature is, the more we can offload from macros to KumaScript. We do a lot of scanning through pages looking for things, and sometimes we have to do multiple passes to whittle down a list to what we want.

If we could do something like "has tags AAA and BBB but does not have tag CCC", plus optionally specifying a base URL to search underneath, we could clean up a lot of macros.
This would offload from macros *to* KumaScript, or offload processing *away from* KumaScript?

:jezdez and/or :fscholz - do we have a search api endpoint to get pages by tags?
Flags: needinfo?(jezdez)
Flags: needinfo?(fscholz)
(not sure we want to have the offloading debate in this bug, but anyway)

I guess one offload would be the following: 
Currently we get a huge JSON containing all subpages of a tree. For example: /Web/API$children

After we have loaded that, we can filter that list and pick those pages we are interested in.
With this bug (and bug 963811) fixed, you can would hopefully get smaller JSONs containing only the things you are looking for. So, smaller JSON to load in KumaScript and less walking through it to get the things that matter. (Plus the search API might be faster than the Kuma API)
Flags: needinfo?(fscholz)

Comment 8

5 years ago
(In reply to Luke Crouch [:groovecoder] from comment #6)
> This would offload from macros *to* KumaScript, or offload processing *away
> from* KumaScript?

The goal is to stop having scripts manually grinding through multiple searches until they get what they want, and to offload that work from script to KumaScript (which hopefully, in turn, would offload most of the work to Elastic Search).
:groovecoder No, we don't have that option currently. I talked to :sheppy about it in Paris and think it can be implemented easily with the search view. We already store the list of tags for every document in the search index, so it's just a matter of defining what kind of queries we want to allow.

The amount of work depends on that, e.g.:

- simple: provide a list of tags and return all documents having one of the tags
- simple+exclude filter: like the simple plan but additionally the ability to exclude documents in the result set that have some other tags, ?tags=web,javascript,!dom. this wouldn't allow arbitrary logic queries though
Flags: needinfo?(jezdez)
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.