Pnp-modern-search: v3 Documentation Issue - Missing Info

[sympmarc]

Version used
Documentation

Describe the bug
The v3 documentation is missing details (which are pretty important!) about available tokens. If you look at the Out of the box query variables section and below, you can see what I mean. I'm also pasting in a screenshot below.

I've inspected the DOM, and the text simply isn't there. Where-o-where is it?

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):
I've tried Edge and Chrome

[wobba]

@FranckyC any idea why it's not showing as it's in the md file itself. Do we need to escape the {} perhaps or add bolding tags like the v4 docs have?

@sympmarc Until we figure out why the publishing fails you can use https://github.com/microsoft-search/pnp-modern-search/blob/feature/v4/docs/v3/search-parts/search-results.md#out-of-the-box-query-variables

[FranckyC]

@sympmarc @wobba should be fixed now.

[sympmarc]

Thanks!

[FranckyC]

You're welcome @sympmarc! BTW did you try the new v4 already?

[sympmarc]

I've looked at it, but as long as it has the big warnings about being a preview which shouldn't be used in production, I can't spend too much time with it.

[sympmarc]

I'm finding as I click around in the documentation, I'm landing on pages where I can't tell if I'm looking at v3 or v4 capabilities. I expect most people are still using v3, so it's important that the docs be easily distinguishable, IMO.

For example, this page clearly has v3 in the URL. What I want to find is the available tokens in v3. I'm not sure how to get there from here (though I can return to the link above which started this issue). If I click on the tabs across the top, I think I'm landing on v4 docs?

[wobba]

@sympmarc Should be a "-v3" on top of all v3 docs. And there's a TOC link as well. If it's missing somewhere let me know as I believe I added it on all of them. That said, I'll see if I can merge docs smart somehow, as the way we do v3 now was the quickest way to get it in as github don't allow publishing two sets of docs in an easy way (afaik).

[sympmarc]

Yeah, I know it's tricky. I expect you'll need to support both versions for a while, though. Maybe some sort of color difference so we at least know which set of docs we've stumbled into?

[sympmarc]

And since you're such swell guys, shouldn't this work as a default search query in v3?

* DepartmentId:{PageContext.hubSiteId} AND IsDocument:1

In the Properties coming back, I see:

                {
                    "Key": "QueryModification",
                    "Value": "* DepartmentId:{PageContext.hubSiteId} AND IsDocument:1 DepartmentId:{745065d8-3341-437b-ab56-20d47fcb2781} AND IsDocument:true -ContentClass=urn:content-class:SPSPeople",
                    "ValueType": "Edm.String"
                },
...
        {
            "Key": "SerializedQuery",
            "Value": "<Query Culture=\"en-US\" EnableStemming=\"True\" EnablePhonetic=\"False\" EnableNicknames=\"False\" IgnoreAllNoiseQuery=\"True\" SummaryLength=\"180\" MaxSnippetLength=\"180\" DesiredSnippetLength=\"90\" KeywordInclusion=\"0\" QueryText=\"* DepartmentId:{PageContext.hubSiteId} AND IsDocument:1\" QueryTemplate=\"{searchTerms} DepartmentId:{745065d8-3341-437b-ab56-20d47fcb2781} AND IsDocument:true\" TrimDuplicates=\"False\" Site=\"745065d8-3341-437b-ab56-20d47fcb2781\" Web=\"5a96eda7-40da-431e-8c7d-2bc73f487a3c\" KeywordType=\"True\" HiddenConstraints=\"\" />",
            "ValueType": "Edm.String"
        }

If I hard-wire it like this, it works exactly the way I want:

* DepartmentId:{745065d8-3341-437b-ab56-20d47fcb2781} AND IsDocument:true

                {
                    "Key": "QueryModification",
                    "Value": "* DepartmentId:{745065d8-3341-437b-ab56-20d47fcb2781} AND IsDocument:true DepartmentId:{745065d8-3341-437b-ab56-20d47fcb2781} AND IsDocument:true -ContentClass=urn:content-class:SPSPeople",
                    "ValueType": "Edm.String"
                },
...
        {
            "Key": "SerializedQuery",
            "Value": "<Query Culture=\"en-US\" EnableStemming=\"True\" EnablePhonetic=\"False\" EnableNicknames=\"False\" IgnoreAllNoiseQuery=\"True\" SummaryLength=\"180\" MaxSnippetLength=\"180\" DesiredSnippetLength=\"90\" KeywordInclusion=\"0\" QueryText=\"* DepartmentId:{745065d8-3341-437b-ab56-20d47fcb2781} AND IsDocument:true&#xA;\" QueryTemplate=\"{searchTerms} DepartmentId:{745065d8-3341-437b-ab56-20d47fcb2781} AND IsDocument:true\" TrimDuplicates=\"False\" Site=\"745065d8-3341-437b-ab56-20d47fcb2781\" Web=\"5a96eda7-40da-431e-8c7d-2bc73f487a3c\" KeywordType=\"True\" HiddenConstraints=\"\" />",
            "ValueType": "Edm.String"
        }

[wobba]

Sure it should work, if added to the query template field, not the query text.

[sympmarc]

So in the Query template on page 2, but not in the Default search query on page 1 of the properties? If I ever knew that, I'd forgotten.

Looks like it still has to be double squiggly brackets, as discussed in #251, though.

{searchTerms} DepartmentId:{{PageContext.hubSiteId}} AND IsDocument:1

[wobba]

@sympmarc which is an unfortunate data issue on what's stored in "DepartmentId", not a query variable issue. That the guid is stored and requires {} to match just confuses how to make it work.

DepartmentId:{1111} works while DepartmentId:1111 doesn't.

Knowing this we could add a hack in the web parts to add {} for this id in particular, but that has other site effects. As related hub sites is approaching you would query using:

RelatedHubSites:{PageContext.hubsiteId} and this property does not contain {}, but a comma separated list of related hubs. that said, you should be able to use RelatedHubSites today instead of DepartmentId.

Ideally we would have NormDepartmentID, like we have NormSiteID etc.