Pnp-modern-search: Query string and Url fragments not working in Search Box

[jagasset]

Version used
Ex: 3.13.0.0

Describe the bug
Search box has stopped retrieving query string from url in what was a working solution until today. This is also the case for another search box using url fragment as dynamic source.

Could this be SharePoint changes impacting the pnp search functionality?

Anyone else experiencing these issues?

To Reproduce
On a modern page, place search box and search results
set search box to dynamic source
Select Page Environment as 'Connected to source'
Select Query String as 'Page environment's properties'
Select Query parameters as 'Query string'
Select 'What ever user defined string' as 'queryParameter's properties'

Set search results dynamic source to search box

Expected behavior
Search box shows query string text and or url fragment text
Search results returned based on connected search box query

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

Desktop (please complete the following information):

Browser Chrome

Additional context

[jagasset]

Also getting the following error when just hooking up the search results to page environment query string as per above instructions.

Error making HttpClient request in queryable [400] ::> {"odata.error":{"code":"-1, Microsoft.Data.OData.ODataException","message":{"lang":"en-US","value":"An unexpected 'StartObject' node was found when reading from the JSON reader. A 'PrimitiveValue' node was expected."}}}

[jennyrobb100]

We are also experiencing this issue across 2 tenants. please advise resolution as soon as possible. We are having to revert to the OOTB SharePoint search function in the meantime

[syed-info]

We are also getting the same error on multiple tenants with version 3.9
Error making HttpClient request in queryable [400] ::> {"odata.error":{"code":"-1, Microsoft.Data.OData.ODataException","message":{"lang":"en-US","value":"An unexpected 'StartObject' node was found when reading from the JSON reader. A 'PrimitiveValue' node was expected."}}}

[gregwilton]

We're seeing the same issue (using an old version but have also tested with 3.13.0.0).

I'm wondering if the format of the dynamic value may have changed from a string to an object and is now being ignored. The below code is from SearchBoxWebPart and it looks like it only processes inputValue if it's a string.

let inputValue = this.properties.defaultQueryKeywords.tryGetValue();

if (inputValue && typeof(inputValue) === 'string') {

  // Notify subscriber a new value if available
  this._searchQuery = decodeURIComponent(inputValue);

  // Save this value in a global context
  GlobalSettings.setValue('searchBoxQuery', this._searchQuery);

  this.context.dynamicDataSourceManager.notifyPropertyChanged('searchQuery');
}

But when I output inputValue, I'm seeing an object with the following structure:

{
  queryParameters: {
    k: 'test',
    q: 'test'
  },
  fragment: ''
}

When a querystring of ?k=test&q=test is used.

[wobba]

Created a fix which seem to work in #330 but I'll let @FranckyC review when he can :)

[priyarane30]

We are facing same issue from morning , getting the following error when just hooking up the search results to page environment query string as per above instructions.

Error making HttpClient request in queryable [400] ::> {"odata.error":{"code":"-1, Microsoft.Data.OData.ODataException","message":{"lang":"en-US","value":"An unexpected 'StartObject' node was found when reading from the JSON reader. A 'PrimitiveValue' node was expected."}}}

[kachihro]

Same issue is within the SearchBox and SearchResults webparts - it's trying to do a searchText for a JSON object - not a text value...

[srinutamada]

Any new SharePoint online updates happen yesterday night? because we are facing the issue from today morning only.

[spo365]

Yes this is happening for me as well, may know what has been changes which break the functionality ?

[wobba]

We have a pending fix in #329

[jagasset]

@wobba - I have applied the pending fix to a test version of the webparts - it appears to fix the described issue - but the connected search results webpart does now show/update results when search box gets queryParameter from URL - can anyone else confirm this?

[priyarane30]

I download latest code from repository,and upload package and check it is showing same error

[jagasset]

@priyarane30 the latest code would not have the pending fix in it yet.

[priyarane30]

Thank you @jagasset ,when it will be available ? any idea

[wobba]

@jagasset I cannot repro - seems to work just fine on my end.

[jagasset]

Thanks @wobba - Would the version make a difference? I tried it on version 3.6.3.

[wobba]

We're on 3.13, so I'm testing with the dev branch code.

[jagasset]

@wobba - Figured out what the issue was - the URL fragment I was passing through needed to be decoded like so:

decodeURIComponent(inputValue["fragment"])

Might be worth considering wrapping it in the decodeURIComponent

[wobba]

Thank you @jagasset and added it as a comment on the PR by @kachihro

[srinutamada]

Can you tell when can we get latest code?

[axelgz]

We getting the same error. We using 3.10 version with configured to used Querystrings, Search Box, and Search Results webparts connected to Page environment >Property: Search > Search Query. It was working, you are able to user links with querystrings and use the Search box.

I updated to 3.13 and the issue still happening with same configuration but if I change connection to Search Box, the Search Results works but we no longer are able to use links with querystrings.

Thank you

[wobba]

@axelgz we have a fix in PR review, but not released. But this seems to be a change on sp side.

[wobba]

I'm checking internally as well if we are aware of why page environment for query param/hash has changed.

[apzl808]

Thanks wobba, I did using your changes, the "queryParameters" and "fragment" are working,

but still not working on "SearchResultsWebPart" using:
Connect to source: Page Environment
Page environment's properties: Current User Information
Current user information: User Name

Thanks

[axelgz]

Thank you wobba.

I tried the PR fix and did not work for the SearchResultsWebPart using Page Environment connections. In my case, trying to use:
Connect to source: Page environment
Page environment's properties: Search
Search: Search Query

[Nowshad07]

Could you please let me know when the updated solution package will be available for use? Thanks

[jagasset]

Hi All,
I have implemented the pending fix and packaged a TEMP solution for anyone who needs an urgent working solution This is based on latest version 3.13 so please be aware of any breaking changes if on a lower version.

Please note this is NOT an official release and should only be used as a temporary fix until an official release is made available via the official release page. This solution has been tested and confirmed to be working with ONLY queryParameters and URL Fragments. There may also be other issues which are yet to be identified!

Also just for full disclosure, I am not an official contributor to the project and or associated in any way.

Temp Packaged Solution

THIS CODE IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING ANY IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR NON-INFRINGEMENT.

[thakmeet]

Hi All,

Any updates on the newer version with bug fix.We are using this component on an Intranet Portal for both People Directory Search and Document Search and its a major issue.Any help or ETA would be really helpful.

Currently we are using the SEarchResults with connected dynamic source of search box and its not working since today morning

[priyarane30]

@jagasset ,what is to be fix in code ,can you explain in details ,your package is working fine but our custom changes in UI and functionality will get affected .

[wobba]

I have verified this is a service issue by testing. It works as "expected" in the local workbench, but not in prod. Still following up internally but don't have a timeline and due to timezones we might not see anything happening until evening time CET.

[srinutamada]

@jagasset the temporary fix is working fine only if the query parameter value present in the url. If the query parameter is missing, earlier default query used to work, but its not happening.

At this moment, my main purpose of the search is achieved.

[wobba]

Fixed with #340 and merged to dev. Will have to consider if we do a point release or wait for the next one.

[wobba]

@srinutamada can you check if the commited fix takes your default query into account?

[axelgz]

The fix seem to only work for QueryString and Url fragments. Other Page properties still failing, Site properties, Current user information and Search

Still getting the Error:
_Error making HttpClient request in queryable [400] ::> {"odata.error":{"code":"-1, Microsoft.Data.OData.ODataException","message":{"lang":"en-US","value":"An unexpected 'StartObject' node was found when reading from the JSON reader. A 'PrimitiveValue' node was expected."}}}_

Should I start a new ticket for other Page properties since QueryString and Url fragments were fixed?

[kachihro]

I'm checking internally as well if we are aware of why _page environment_ for query param/hash has changed.

Any response from internal technical folk about why this was changed ??

[kachihro]

The fix seem to only work for QueryString and Url fragments. Other Page properties still failing, Site properties, Current user information and Search

Still getting the Error:
_Error making HttpClient request in queryable [400] ::> {"odata.error":{"code":"-1, Microsoft.Data.OData.ODataException","message":{"lang":"en-US","value":"An unexpected 'StartObject' node was found when reading from the JSON reader. A 'PrimitiveValue' node was expected."}}}_

Should I start a new ticket for other Page properties since QueryString and Url fragments were fixed?

Have included a new fix + PR for this - and tested with the Page Properties Settings - User / Site / Query

[phillipharding]

I'm using v3.9.0.0 and this started affecting me today and seems to be an issue with the QueryText property

"Querytext": {
    "rawInputValue": "",
    "enhancedQuery": ""
},

Causes the issue, but

"Querytext": ""

Works.

Given that this used to work, has something changed on the SharePoint side?

I've quite a few clients using different versions of the Search webparts, am I going to have to upgrade all of these to get the issue resolved and al the search pages - thinking specifically of the changes to the Pagination webpart?

[wobba]

@phillipharding if you read this issue and see linked other issues you can figure out the state of thing 😉

[kachihro]

I'm using v3.9.0.0 and this started affecting me today and seems to be an issue with the QueryText property

"Querytext": {
    "rawInputValue": "",
    "enhancedQuery": ""
},

Causes the issue, but

"Querytext": ""

Works.

Given that this used to work, has something changed on the SharePoint side?

I've quite a few clients using different versions of the Search webparts, am I going to have to upgrade all of these to get the issue resolved and al the search pages - thinking specifically of the changes to the Pagination webpart?

Yes - there was a breaking change in the SharePoint page properties. There is some frantic activity to fix it - pls. check back in a day or two... (or - can pull from the DEVELOP branch - if you're willing to UAT the changes)

[wobba]

Feel free to like/comment on https://github.com/SharePoint/sp-dev-docs/issues/5947 as well.

[saregbesola]

@wobba I downloaded version 3.13.0.0 yesterday. Initially it worked fine but started throwing the same bad request error later in the night:
Error making HttpClient request in queryable [400] ::> {"odata.error":{"code":"-1, Microsoft.Data.OData.ODataException","message":{"lang":"en-US","value":"An unexpected 'StartObject' node was found when reading from the JSON reader. A 'PrimitiveValue' node was expected."}}}

Or is this not the correct version that contains you fix? Kindly advise. Thanks

[wobba]

We have not built a version with the workaround. It will be part of the next release, or you can build yourself. I'd rather SPFx revert their change.

[saregbesola]

@wobba okay. Thanks

[wobba]

Have an update, and the team is looking into it.

[wobba]

We just made an early June release with the fix - https://github.com/microsoft-search/pnp-modern-search/releases/tag/3.14

[axelgz]

We just made an early June release with the fix - https://github.com/microsoft-search/pnp-modern-search/releases/tag/3.14

Thank you for the release.

The Page property configuration is working but I noticed that the Default search query is not working

[manishasakarvadia]

We just made an early June release with the fix - https://github.com/microsoft-search/pnp-modern-search/releases/tag/3.14

Will this solve issue for old version of pnp modern search 3.9.0.0 and 3.10.0.0 ?

[wobba]

@axelgz we'll address this..I marked 3.14 as a pre-release for now.

[wobba]

@manishasakarvadia it includes code to work around the issue with dynamic data. You can also wait for SPFx team to fix the underlying issue.

[wobba]

@manishasakarvadia updated the release sppkg to 3.14.1 which resolves the issue of default query.

[manishasakarvadia]

@manishasakarvadia updated the release sppkg to 3.14.1 which resolves the issue of default query.

Thanks for new realease. It works now. :)

[wobba]

Keeping it open until fixed from SPFx side

[stevebeauge]

Not sure to understand... if the old version of the Pnp Modern search were compiled using the SPFX version available by this time, why newer version of SPFX would break these ?

Hope there's will be a solution. I can hardly afford to rebuild all pages of all customers' search pages we've built, and which were on releases < 3.11 (where a lot of breaking changes where introduced)

[stevebeauge]

Also, an important question.

You releases the v3.14.1 with a fix that solves the issue. Can we take this as a permanent fix ? Or is it just a workaround that may itself fail if something changes from the SPFX side ?

thanks

[wobba]

It's a server side dependency, provided by a SPFx feature - which can probably change dependent on the actual runtime. Doesn't really matter how as it has happened imo.

3.14.1 should still work if SPFx reverts, as we check on string vs. object and handle both scenarios. The local workbench still returns a string. I don't have a timeline on SPFx work/revert but have asked.

[webbrewer]

@stevebeauge You shouldn't have to rebuild anything - if you replace the solution in the app catalog with 3.14.1 as a new version, the web parts you've configured should start working again and won't need to be reconfigured.

[wobba]

@webbrewer depends on what version you're on and features you use as 3.11->3.12 had breaking changes.

[phillipharding]

@webbrewer @stevebeauge @wobba
For upgrading from versions prior to v3.11.0, the pagination webpart was removed and needs to be replaced with a web component?
https://microsoft-search.github.io/pnp-modern-search/search-parts/search-pagination/

[phillipharding]

@wobba is there any timeline on an SPFx fix?

[wobba]

I will report if I get any. You could also log a support ticket to escalate the issue.

[wobba]

A fix is scheduled to roll this or next week. And for this scenario a simple rollback was not possible.

[haydio]

Any updates on if the fix was rolled out @wobba?

[wobba]

Checked right now and seems deployed as the property is read correctly as a string and not an object. Closing for now.