SharePoint: access denied to the root site even if granted access to the default page

Today I had a problem: even if visitors had access to the site home page, when pointing to the site url directly, they got an Access Denied error, instead of being redirected to the home page.

I have done some research on Internet and it seems that enabling anonymous authentication at the web application level, and then removing it, is able to fix the problem (!).

 

Here some links I have found:

SharePoint: how add web part to DispForm, NewForm, EditForm pages without Designer

I'm working in a environment where SharePoint Designer is not allowed, and above all even server-side development is forbidden.

 

To customize DispForm, NewForm and EditForm pages, I needed to find the following pages helping me:

SharePoint field definition: DisplaceOnUpgrade="TRUE"

When coding SharePoint features to deploy fields and content types, a common problem is that when upgrading the solution, fields are not upgraded too.

The reason is that each field definitions should contain the following line:

DisplaceOnUpgrade="TRUE"

In this way, when upgrading the solution, even if the field is already found, it is upgraded.

 

To upgrade content types, adding or removing fields, SharePoint 2010 introduced the concept of UpgradeActions, as described in my other blog post SharePoint 2010: feature upgrading.

SharePoint: choosing between Custom Web Templates and Custom Site Definitions

SharePoint 2010 introduces the concept Web Templates of SharePoint 2010, that should take over the Site Definitions.

In the article Deciding Between Custom Web Templates and Custom Site Definitions it is described that:

  • the prefered approach is to use now Custom Web Templates instead of Custom Site Definitions;
  • there are a few exceptions when Custom Site Definitions have still to be used.

 

Advantages of Custom Web Templates are:

  • They can be modified without affecting existing sites, while Site Definitions are immutable to maintaining them requires to create new and updated versions, and instruct the users to use the latest version... (not very user friendly);
  • They can be deployed in Sandboxed Solutions and SharePoint Apps too, while Site Definitions require farm solutions.
  • They are easier to upgrade with next versions of SharePoint

SharePoint 2013: JavaScript Dispaly Templates

In SharePoint 2013, it is not necessary anymore to use XLST to customize ListView web parts.

In fact, JavaScript display templates have been introduced, allowing to develop customizations in JavaScript instead of XSLT: in this way, code is easier to develop and understand, other than debuggable.

 

Here are some links:

SharePoint 2013 and 2010: deploying pages with features and modules

After my previous article SharePoint 2007: how deploy pages and web parts via feature I have found a better way to deploy web part pages via features.

 

You can create a Module and use the following properties:

  • Path: it is about the source file included in the wsp
  • Url: it is about the destination file included in the SharePoint database

Both properties can be define both at Module level and at File level; if present at Module level, they are combined.

 

Each file is an aspx page that in traditional way contains multiple ContentPlaceHolder controls.

 

To include web parts:

SharePoint: web part maintenance page

Sometimes web-part added to a web-part page generate run-time exceptions, that doesn't allow the page to be view or even edited.

In this case, a possible solution is to remove the offending web part from page. But how, if the page can't be edited?

The solution is to open the page in "web part maintenance" mode: once opened, it will list the web-parts used in the page, allowing the editor to delete them (none, one or more).

To run the page in "web part maintenance" mode, it is simply possible to retrieve it from a browser window, adding the parameter:

?contents=1

 

The same concept is described in the article Opening WebPart Maintenance Page.