Search is undoubtedly the heart of today’s World Wide Web. Everybody loves, or at least can’t live without, Google.
Still at times the need arises to hide parts of a web site from search engines. More often than not it is private content (customers’ account information, contact information for individuals, etc.) that the client does not want visible to the public. It could also be third-party information like ads. Yet another example is duplicated information across the website as it could negatively impact the page rankings in search engines.
In this article we will first go through the technique that allows us to exclude entire pages and directories from the search crawler. Then we will look into the trickier topic of hiding only part of the page content from the search engine spider.
I have been doing all of my development activities in a virtualized environment for quite some time. Programming for Microsoft SharePoint Server almost certainly requires a virtual machine but I have come to know that using one is convenient regardless of the target platform. Virtualization makes it easier to do backups and to hand over my work to another developer if need be.
When I had to do a project targeting Windows Phone 8, I found out that the system requirements for building a developer environment requested a dedicated host machine in order to successfully run the Windows Phone 8 emulator which is a virtual machine on Hyper-V itself.
Unhappy as I was with this requirement, I searched for workarounds and I found here a complete dummy-level detailed article on how to build and configure a virtual machine for developing Windows Phone 8 apps. Almost all steps are quite trivial for someone dealing with virtualization on a daily basis so I will just summarize the main caveats.
Recently, we encountered an interesting and quite unexpected issue while working on a publishing site based on SharePoint 2013. Let me share some details on that particular scenario and a simple workaround in case you come to struggle with the same problem.
A client of ours has a large number of pictures that they use when authoring content for a publishing site. They store the images in the Site Collection Images library. To make it easier to classify the images and simplify the work of content authors, they added a Managed Metadata field named Category to the library. This works pretty well since a new feature in SharePoint 2013 now allows to conveniently sort and filter by taxonomy fields in the list view:
Recently in one of our projects we had to write some code to get items from a list in SharePoint 2013 using CAML. “Easy Peasy Lemon Squeezy” … I hear you say. It should be quite trivial especially given the fact that CAML has been around since SharePoint Team Services – the very first version of the platform.
Well, not so fast. If my experience as a SharePoint consultant has taught me anything, it is that even the most seemingly trivial task in SharePoint can kill you a couple of hours. That is – if you are lucky.
So let’s see where the catch is in querying Boolean fields with CAML.
This post is a sequel to the article Deploying Publishing Page Layouts and Pages Using Features in which we examined the step-by-step process of deploying publishing pages based on a page layout using SharePoint features. As we saw, apart from a few caveats, that approach was quite straightforward and beneficial, allowing us to easily move a solution between environments.
However, the previous solution had one disadvantage – the page layout and the publishing page itself were deployed within the same feature. While this works for our small sample, it is not the cleanest approach for a real-life project.
In an end-user solution it is better to package page layouts in one feature and publishing pages in another. This way we are able to deploy content separately to development or QA environments for testing purposes and a clean solution without content to production.
In the end we would like to re-structure the solution to look like this: