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? ===================== n/a 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? ======================================
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.
As a matter of reference, I've created this macro: https://developer.mozilla.org/en-US/docs/Template:NeedsReviewWithTags 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. :)
This will help us build landing pages, sidebars, and the like for zones, so adding as a blocker.
this enables a et of pages with ALL of those tags.
Priority: -- → P2
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?
(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)
(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).
You need to log in before you can comment on or make changes to this bug.