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.

[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.