Our vendor has set up a Sharepoint installation and created a publishing portal with a pages library. So far, so good, but we have the following questions about this implementation:

  • It seems impossible to immediately publish a new article since you have to wait for the search crawler. Can continuous crawling solve this?
  • They implemented some web parts with FQL. And with FQL it is impossible to filter on time. e.g. It is not possible to plan a news article to go online at 3pm and go offline at 4pm.

Are we missing some OOTB functionality or do we have to solve this with customisation?

  • If you create a Publishing Page, then you can immediately publish it. I don't think so it has any connection with Search. It only matters when you display the list of page in Content Search Webpart where the continuous crawling will solve your problem. – Asad Refai Feb 4 '16 at 9:46
  • @AsadRefai Thanks. But related to server load: is continuous crawling a good idea? – Citizen SP Feb 4 '16 at 9:48
  • 1
    Yes continuous incremental crawling is not a problem. My previous client was a large bank with more than 14K users. They implemented Continuous Incremental Crawl. – Asad Refai Feb 4 '16 at 9:49

A project I was on had a similar implementation and it worked but with a few hiccups. To answer each of your questions first:

  1. Can Continuous Crawling allow you to publish an article immediately? Technically immediately, no, but it will significantly reduce latency. Ours was about 10-20 minutes.
  2. FQL does support granularity down to fractions of a second. See this MSDN reference. Unfortunately we could never get it enabled (despite repeated requests to MS SP Cloud Tech Support)

Now the caveats.

  1. Timezone difference - our instance was in the cloud and articles were set for a day, not specific hours. Because the SP instance was in a different timezone we experienced issues with article publishing/unpublishing a few hours outside our primary users' timezone.
  2. Time values in Zulu and Local time - I remember some fields storing time in local time (to the server) and some in Zulu time. This became more confusing when factoring in the difference in time zones between users/publishers and the servers, and daylight savings time.
  3. Similar articles hidden vs duplicates - One day we noticed articles that were very similar (e.g. Adopt-a-pet in June; Adopt-a-pet in July) were being collapsed due to the Search Result WebPart having TrimDuplicates turned on. When we turned it off, we sometimes found duplicate articles when poor maintenance resulted in orphaned index records.

Unfortunately, this is one area where using a Search engine was not as precise (and reliable) as using CMS features with properly tagged content.

I hope this helps.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.