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:
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:
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:
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 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
In SharePoint 2013, it is not necessary anymore to use XLST to customize ListView web parts.
Here are some links:
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:
With SharePoint 2013, .NET 4.5 has met the SharePoint world, allowing for example to use the latest versions of the Entity Framework during custom solutions development.
And finally, Visual Studio 2013 will carry MVC development! You can read more info in the blog post Introducing MVC support for apps for SharePoint.
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:
The same concept is described in the article Opening WebPart Maintenance Page.
In the blog post Deploying master pages and page layouts as a feature it is described how to deploy publishing page layouts, and automatically associate them with content types.
In the blog post Why should 'one' always save publishing pages in "Pages" list in MOSS !!! Bend It !!!! it is described how have multiple page libraries in a publishing iste