Thursday 24 November 2016

Modern SharePoint pages and team news pages - how to query/search for them

Modern pages are now in SharePoint team sites in Office 365, and this includes the new “team news” facility. This is a simple way of creating news articles within a team site - it’s no replacement for an organization-wide intranet news facility, but it is useful for teams to convey news or other information within their group. And whilst it’s called “news”, of course the pages themselves could be anything – reminders for the team, current priorities/focus areas, policies and procedures, and anything else. One key element is that users can easily submit these articles from their mobile device – specifically the SharePoint mobile app. But it’s just a page with text, images, and any other web parts that the author adds (though that bit needs the PC experience).

I spent a little time looking at how all this works, and how developers and power users can query and search for such pages. Just to set the context since this is all shiny and new at the time of writing, this is what a display of team news looks like:

(By the way, excuse the horrible branding in this tenant - I use it to clearly tell me which of my test tenants this is!)

News page

In the context of a group site (i.e. a modern site attached to an Office 365 Group), things look a little different in terms of the page header/banner, but largely the same:

News page - Group

..and then to zoom in a little on the “News headlines” control:

News headlines

..or as an alternative, the “News list” control:

News list

Both of those are new web parts that you can add to a modern page – and since new-style web parts developed with the SharePoint Framework can be used in “classic” pages, it should be possible to use these new web parts everywhere. However, since classic pages use the old web part gallery and picker, it could be that we need to export and import one of these web parts to add them to a classic page.

General notes on news:

  • When a news page is created, it gets displayed on the site *immediately* in the “News headlines” and “News list” controls – no waiting for a search crawl
  • It’s important to click the “Add” button next to news to create a news page. Otherwise you’ll get a modern page, but it won’t show up as news - because it isn’t a news page. As Elio points out in What makes a page be a news page in SharePoint Online?, news pages have a field called Promoted State and the value gets set to 2. So that PromotedState=2 is the thing that identifies news pages
    • Note that this isn’t exposed in the UI, so there’s no easy way (outside of code/PowerShell/tool) to update this once a page has been created (at least for now)
  • Images uploaded during news page creation go into Site Assets/Site Pages/[escaped page name], like this:

     SNAGHTMLf13e9a2

So that’s a sense of how team news works in team sites. But what if you want to search/query for these pages as a developer or power-user?

Searching for modern pages and news pages

Searching for news pages

The main thing I wanted to say here is to extend Elio’s message and say that there is also a Managed Property with the same name (“PromotedState”), and so we can use search to find these pages too (e.g. if we wanted to roll-up team news from many sites):

image

..and so with a Content Search web part or similar, we can use this in a simple query to find results:

SNAGHTML16154ef2

For now it seems only news pages use this property, but it might be wise to add a filter on say, content type, in case Microsoft decide to use it elsewhere in the future.

Other notes:

  • The content type is the same for standard modern pages and news pages – here are the details:
    • ContentType (name) = “Site Page”
    • ContentTypeId = 0x0101009D1CB255DA76424F860D91F20E6C411800D294F66E48650D4DB0D1477463DC0B51
  • Data for all web parts is stored in one page field in the content type, and that translates to one managed property in search – here are the details:
    • Field name = “CanvasContent1”
    • Managed property = “CanvasContent1OWSHTML”
    • Sample data:

      SNAGHTML16253821

So, this idea that everything is stored in one field can potentially be a challenge with modern pages. It’s not going to be easily possible to query/filter on something that’s stored in the page because the data isn’t broken out into separate fields on the content type as we might normally do in a publishing scenario (e.g. show me news articles where category = ‘Politics’). That’s just a trade-off that comes with the flexibility and simplified page editing experience of modern pages I guess – I’m not sure Microsoft had too many options there.

The JSON response from the _api/sitespages/pages/feed endpoint (which the news headlines/news list controls use behind the scenes) looks like this:

Summary

The new modern pages are here, and the "team news" feature in team sites is one example of their use. Developers and power-users will find it useful to understand what things look like underneath, and for news pages it's the PromotedState=2 field value (and managed property) that identifies them. Thanks to Elio for pointing out the field value, and consider also the managed property which may be useful to you in search.

2 comments:

Luis Mañez said...

God bless you!! (and the Search Query Tool :)). Great stuff mate, thanks for sharing!

Dave said...

I have to say, as much as I appreciate the new direction Microsoft is taking with SharePoint and understand the reasons for doing so, I am beginning to miss the old days of monolithic step-releases and on premise.

Modern page and site functionality is being drip fed out to us at a glacial rate - visible enough to raise questions about how we use it, but nowhere near finished enough to actually use. So we're left with questions about what to sell to clients in the here and now...

Do we play it safe and go for modern team sites and pages, accepting the woefully incomplete out of the box functionality, the broken navigation, the poor user experience, the utterly baffling coexistence of groups/outlook/sharepoint?

Or do we stick with traditional team sites and branding and web parts knowing that this technology is ultimately a dead end, with all the risks and consequences that implies?

The smart money must surely be on the first option - but it really doesn't seem like the kind of functionality I'd be comfortable putting in front of a client and won't be for the next 6-12 months...

Does anybody have any thoughts on this?