A bit like highlighted content webbpart but better.

A link could be created - that opens a page or a webpart that its easy to define layout and views of a pre defined search. So link says find all policy docs, or all forms. And as libraries across multiple hubbsites have a managed metadata for document type set up it would then be possible to define that when the search runs how these are displayed - so it would say group the found policy documents under each hub site it found them.

So look like this

Refiners policy | forms | procedures

Search results

Mainnhub
Columns. Columns columns
Policy 1 Info. Info
Policy 2 Info. Info

Second hub site
Policy 3. Info. Info
Policy 4

For large sites with many, detailed crawl rules it quickly becomes confusing to administer these rules. I'm asking for something as simple as an annotation (comment) to be added to each crawl rule. That way we can understand why it was added in the first place.

Use case: We run multiple large internet-facing web sites. For one of these sites we have about 250.000 searchable items that we support on our on-site search. We need around 50 crawl rules to ensure we include/exclude parts of the content.

We have a 10 year history of maintaining rules to include/exclude content. When users report that some content should/should not be part of search, we use the crawl rules test feature in Central Admin to verify if the URL should be crawled.

Finding an offending rule is easy enough. But, we cannot simply remove or invert a rule based on a single end user report. The rule was added for some reason at some point. An annotation/comment on each rule would greatly simplify the management of these rules.

The following are the list of features will enhance the wiki platform in sharepoint:
1) Provide time bound widgets like New and Changed, Alerts, Must Read & Acknowledge to help the users to identify different types of contents and even be forced to read for compliance purpose.
2) Allow articles to be tagged and promoted as Featured content within a site or subsite and presented in the form of a webpart (similar to Popular articles)
3) Ability to archive wiki articles in the same site while retaining all its tags and exclude them from search results for the viewers
4) Ability to search archived articles by the authors
5) Hide the archived articles from the Popular Articles web part
6) Ability to publish and expire on a future date. On expiration, the article should be “Archived” and pulled out of search view
7) Auto alerts to author group on content expiring on a certain future date

Creating or updating managed properties is incredibly slow. We have a requirement to mirror the data models in other systems (SAP, databases, etc.). We do this by creating and/or modifying managed properties.

Every night we have to traverse our data model of 4000+ managed properties just to check if there are any changes. We use the out-of-the-box PowerShell cmdlets to do this. We have a pre-made list of properties with settings in a file. We then loop through this and compare against the managed properties defined in SharePoint.

The best performance we can get is to check 3 properties per second. Usually it takes 20-60 minutes to complete one such scan.

Can you please look into the performance? I cannot understand why it should be this slow. It should be possible to loop through 4000 properties and verify that there are no changes in less than a minute.

PS: Referring to SP2013.

Queries are processed internally. For example the query is tokenized, lemmatized, word breaker is applied, synonyms, white-/blacklisting, etc. To understand what happens with a query we have to scour through ULS logs today.

The search API should include an annotation list that explains each step and modification that is done to a query. Similarly all modifications done to results should also be annotated. This was a feature in FAST ESP prior to SP2013.

The API can be extended with annotations without breaking compatibility with the current API. It will be an invaluable tool for developers and admins as part of debugging. Furthermore it can be used by applications that use the search API. For example by explaining to end users that what kinds of modifications were done to their query.