Wednesday, November 28, 2012

When to use the Content Search Web Part (CSWP) or the Content Query Web Part (CQWP)



The Content Search Web Part (CSWP) is a Web Part introduced in SharePoint 2013 that uses various styling options to display dynamic content on SharePoint pages. But when do we use CSWP or the CQWB

First this is a link to introduce the Content Search Web Part (CSWP)

Now to decide any one to use, The CSWP can return any content from the search index. Use it on your SharePoint 2013 sites when you are connecting to a search service and want to return indexed search results in your pages.

The CSWP returns content that is as fresh as the latest crawl of your content, so if you crawl often, the content that the CSWP returns is more up-to-date than if you crawl infrequently. If you need to display instant content or the refreshed version of content, use the Content Query Web Part (CQWP) instead.

Search crawls only the major versions of content, never the minor versions. If you want to display the minor versions of your content, do that by using a CQWP.

Some site collection administrators mark sites to not be indexed. Content marked in this way is not available in a CSWP. If you want to return results from a site that is marked to not index, use the CQWP instead.

Mixed Http and Https Content with SharePoint 2010



Hello All,

                Securing your claims authenticated publishing web application specially FBA sites is very important if your content have very valuable data , but what all we need here is to secure the important pages in the site we are implementing (Registration – Forget password – Login – any pages with valuable data “Visa Cards, Enterprise data , etc …..”), the steps to approve that   is very simple .

1-      First you have to plan the architecture and permission levels for the anonymous and authenticated user (Optional)
2-      Then you have to configure SSL over your web application pool or the extended zone web application pool
3-      You will notice that during the implementation for SSL that Notice that even if you authenticate via https, your authentication isn’t recognized when you switch over to http. The reason for this is because SharePoint has hard-coded logic that says if it’s generating an authentication token for an https connection, then turn on the SSL Only flag on the cookie. An SSL Only flag means that the cookie can only be accessed via https. So as soon as you change the address to http, your authentication cookie is no longer recognized and you have to login again. The following post resolved this issue

Voila !! The important pages in your site is now secured , and can feel secure & safe J

Note: You can decide whether to secure the  whole site or specific pages in your site just a matter of implementation and your business needs

Preventing authenticated visitors from browsing system pages



SharePoint Publishing sites became a very important trend in the SharePoint world , but thinking that your site will face the public users through the internet and your system pages will be vulnerable  for users – even those users are authenticated against any provider FBA or third party – that is a big issue, This issue is a “Heart attack” for your public site.

Surfing for the solution, I found a lot trends for avoiding this problem , but I think that the following solution is very easy and strait forward one. So I wanted to share the solution – may be helpful for someone- 


Hope this link is helpful.

Enabling you published Sharepoint Site -Full Site - on mobile phones and tablets



One interesting feature of SharePoint 2010 is that it automatically shows a nice mobile experience when mobile devices browse the site. There is no need to type in the mobile URL (by appending /m to the URL).

                While this is terrific for intranet sites, its less than ideal for public internet sites, especially ones that have a lot of custom branding. In those cases, typically you would want smart phones like the iPhone , Android phones to see a standard rendering of your site. So, how do we turn off the automatic mobile experience? There doesn’t appear to be a setting for this in the Site Settings or in Central Administration.

Solution:
Turns out you need to edit the “compat.browser” file for your SharePoint site. To find this file, look in your IIS directory for your SharePoint site and look for the App_Browsers folder. Mine file was located at: C:\inetpub\wwwroot\wss\VirtualDirectories\2020\App_Browsers\compat.browse

This file has settings for MANY popular browsers, including most mobile browsers, so I located all tags looking like “<capability name="isMobileDevice" value="true" />” and changed the value property to “false” .

now when I browse my SharePoint site I see the standard branding, just like the desktop full site version

Using Page Output Cache with Content by Query web part



1-      We have SharePoint 2010 internet facing site with page output caching enabled.

2-      We have one IMtech CQWP with 2 paging parameters.

3-      This is not working when we do caching. Once I remove caching paging works

-          /Pages/default.aspx?p=1 -> results for page one

-          /Pages/default.aspx?p=2 -> Cached result for page one

        I found Vary by Query String Parameters option. Which was a life saver, as we can’t just get rid of caching – for Performance wise

Solution:

-          In the Site collection cache profiles, Edit the “Public Internet (Purely Anonymous)” cache profile.
-          Locate the “Vary by Query String Parameters” property.
-          Right down all the parameters you want separated by ‘,’ e.x. p,pNavigation,pHome

This way your cache will work as follow, all URL with any query string will be considered as separate URL and cached separately


References :