SOLVED

SharePoint modern news webpart "something went wrong"

Steel Contributor

Hi everyone,

the news webpart in list and carousel mode doesn't show the news items that exist, unless you specify them explicitly using the "organize" function of web part.

What this means is that the most recently added webpart doesn't show up at the top of the "News webpart" list.

The news webpart gives "something went wrong" error.

Same error in IE and Chrome.

 

I thought it was caused by new news items with titles that contained maori characters e.g. Staff Announcements: Pānui Kaimahi - 22 Āperira 2020
BUT even when i rename the aspx files in PageFiles to remove the accents above the characters I still get the errors.
I've also seen the same sort of error when a users creating the news item was on a very slow connection.

 

In both cases the news item page works fine if you go to it specifically in the browser window. It is the filter or select statement in the News webpart that is having the problem.

 

Note the middle column of the home page is using the Modern Yammer web part. Could it be some cross over error ??

 

Please tell me how to find the news pages which are causing the issue, and how to fix it !

Many thanks

 

Dorje

7 Replies

This is the error I'm getting with the News Web part

 

Something went wrong
If the problem persists, contact the site administrator and give them the information in Technical Details.
TECHNICAL DETAILS
ERROR:
[HTTP]:400 - [CorrelationId]:2be64e9f-1093-b000-e342-23e5870c0b79 [Version]:16.0.0.20022

CALL STACK:
Error: [HTTP]:400 - [CorrelationId]:2be64e9f-1093-b000-e342-23e5870c0b79 [Version]:16.0.0.20022
at https://spoprod-a.akamaihd.net/files/sp-client/sp-dataproviders_en-nz_d963ee69f4b838a804bae9d8a288a6...

Hi, @Dorje McKinnon 

 

I have the same error. I figure out that this problem happens when I have more than 8 "Managed metadata" fields.  After I created another managed field, the "News Webpart" stop working if I have selected from"This site".

 

I need to selected from "This site" in order to use the filters by field properties, so, my unique options is not use more than 8 managed metadata fields.

 

I hope SharePoint could help us, increasing this limit.

@Dalejo 

Gracias

 

I'll look into that and see if that is the same cause for me.

 

Dorje

@Dalejo 

 

The "Site pages" library where the news items are giving the news webpart error has:

7 Content types

  • Site page
  • wiki page
  • Web part page
  • Repost page
  • Ourcustom content type 1
  • Ourcustom content type 2
  • Ourcustom content type 3

These 7 content types mean we have 20 columns for this library

  • 8 of the 20 are Managed Meta data

To try and get to the bottom of the issue I used ShareGate to migrate all my news items to another Teams SharePoint sitepages library. In that site collection they don't cause the error when using the Modern News Web parts.

In my Test Site collection SitePages library there are:

5 Content types

  • Site page
  • wiki page
  • Web part page
  • Repost page
  • Ourcustom content type 1

These 5 content types mean in the Test Site collection sitepages library we have 18 columns 

  • 7 of the 18 are Managed Meta data

In my live intranet, with the error. I'll try to remove one of the Managed Meta Data columns and see if that fixes the issue.

Thank you for suggesting I check this.

 

 

 

 

Ola @Dalejo ,

 

I removed one of my content types, and one of the columns in the library (managed metadata), so that I now have 7 managed metadata columns in my Intranet SitePages library.

I have a test home page with NO other web parts on it

When I add the News web part I get

CALL STACK:
Error: UnexpectedRetryableError
at https://spoprod-a.akamaihd.net/files/sp-client/sp-dataproviders_en-nz_24aff8c00dbefa9b3dc09ef8196c3c...

 

Which seems to be the same as the error I was getting with 8 managed metadata columns.

For testing I set up another Site collection, with a site pages library, and I had copied all news items from the intranet to this test site pages library. Wen I create a test home page, with the news web part in it the test site pages news items load and display fine. If I change the test home page news webpart to use "Select sites" and choose the intranet, I get the same error as on the home page of the intranet.

Interestingly on the main intranet home page if I use "select news source" and choose the test site collection the news doesn't load and gives the same error (above).

 

So it seems the intranet site collection or sitepages library itself is the issue.

 

Anyone have suggestions on how I can track it down ?

best response confirmed by Dorje McKinnon (Steel Contributor)
Solution

And so eventually we've found a solution.

Two Search Schema managed properties with the same names or alias.

Thanks to Mike Lee (Boston) and his excellent post about how the Modern News Web part is reliant on search

https://techcommunity.microsoft.com/t5/sharepoint-support-blog/sharepoint-online-news-from-associate... 

 

Though my issue was different, I felt there might be something in what Mike Lee (Boston) had documented.

AND yes there was.

We too had a Search Managed Property called AuthorOWSUSER and another Managed property Refinablestring05 with the Alias of AuthorOWUSER.

 

After moving to SharePoint online, but before modern sharepoint search and news was available we had, as I know many organisations did and do, a customised search page with multiple filters. Refinablestring05 was used on that classic custom search page to provide an Author refiner to staff searching for specific content. We had done this because the search managed property Refinablestring05 could be set to Refine/Sort etc unlike the default AuthorOWSUSER managed property.

 

As modern search became available we found more value in it than maintaining our custom search page so we moved across to SharePoint online modern search, and all went well for 9 or 10 months until we started seeing the error outlined in this post.

 

As per Mike Lee (Boston) 's blog post, as soon as I had altered the name of Refinablestring05's alias to be different than managed property AuthorOWSUSER the news web parts started working fine.
So our issue wasn't due to Maori letters in file names, nor was it due to too many managed metadata columns (though they may cause issues in some situations), but due to search configuration.

 

Here is the Refinablestring05 managed search property after I renamed the Alias to AuthorOWSUSER1

 

authorowsuser.jpg

Comment for Modern News Web part team and other Microsoft staff

I think that this issue is a classic example of assumptions not being true and testing being done with test data rather than real tenant setups. SharePoint has been around a long time, so organisations have lots of legacy settings (best practice at the time) which don't have an impact or are even remembered. Then with a small code change, and I couldn't find any mention of changes to the Modern News web part code, weird and non-useful errors are returned to the users.

Please - take a leaf from the OneDrive team's book and make EVERY error useful in that it tells the person who sees it what to do next.

 

 

@Dorje McKinnon 

 

Hi folks,

 

We had a simular problem, but with a different reason and sollution. In our case we had a page library with 5 different custom contenttypes based of 'sitepage'. Not every contenttype had the same metadata which made we had a page library containing 14 managed metadata fields.

 

This is where things went wrong. Apparently you can only have a maximum of 12 fields which are either of the types: look-up', 'managed metadata', or 'personfield'. SharePoint already uses 3 fields of this type by default, namely: 'made by', 'modified by' and 'check-out by'. This means that you can have a maximum of 9 additional fields of this type. If we'd go over this limit, the news webpart gives no result back.

 

Our solution was to not go above nine fields of the type 'person', 'look-up', 'managed metadata'. If you encounter the problem, try deleting some of these fields and the news webpart should be working again.

1 best response

Accepted Solutions
best response confirmed by Dorje McKinnon (Steel Contributor)
Solution

And so eventually we've found a solution.

Two Search Schema managed properties with the same names or alias.

Thanks to Mike Lee (Boston) and his excellent post about how the Modern News Web part is reliant on search

https://techcommunity.microsoft.com/t5/sharepoint-support-blog/sharepoint-online-news-from-associate... 

 

Though my issue was different, I felt there might be something in what Mike Lee (Boston) had documented.

AND yes there was.

We too had a Search Managed Property called AuthorOWSUSER and another Managed property Refinablestring05 with the Alias of AuthorOWUSER.

 

After moving to SharePoint online, but before modern sharepoint search and news was available we had, as I know many organisations did and do, a customised search page with multiple filters. Refinablestring05 was used on that classic custom search page to provide an Author refiner to staff searching for specific content. We had done this because the search managed property Refinablestring05 could be set to Refine/Sort etc unlike the default AuthorOWSUSER managed property.

 

As modern search became available we found more value in it than maintaining our custom search page so we moved across to SharePoint online modern search, and all went well for 9 or 10 months until we started seeing the error outlined in this post.

 

As per Mike Lee (Boston) 's blog post, as soon as I had altered the name of Refinablestring05's alias to be different than managed property AuthorOWSUSER the news web parts started working fine.
So our issue wasn't due to Maori letters in file names, nor was it due to too many managed metadata columns (though they may cause issues in some situations), but due to search configuration.

 

Here is the Refinablestring05 managed search property after I renamed the Alias to AuthorOWSUSER1

 

authorowsuser.jpg

Comment for Modern News Web part team and other Microsoft staff

I think that this issue is a classic example of assumptions not being true and testing being done with test data rather than real tenant setups. SharePoint has been around a long time, so organisations have lots of legacy settings (best practice at the time) which don't have an impact or are even remembered. Then with a small code change, and I couldn't find any mention of changes to the Modern News web part code, weird and non-useful errors are returned to the users.

Please - take a leaf from the OneDrive team's book and make EVERY error useful in that it tells the person who sees it what to do next.

 

 

View solution in original post