Beware with Unique Permissions on PublishingPages, AddAndCustomizePages and Embed Code in a page

Interesting puzzle solved: page authors complained that some of them face an issue when they try to insert a Microsoft Stream video via embed code in the page body:

The message clearly points to missing of 'AddAndCustomizePages' permission for the logged-on page author. However, on checking the permissions, all the authors / editors do have that permission via an assigned 'Content Management' permission level. After some trial-and-error, I discovered the SharePoint internal cause. The below error message on trying to insert a ScriptEditor webpart in the page content, led me to the Eureka insight:

This site says... Aha: In the site the permission inheritance is broken, to achieve that page authors can only create and modify page (= news) items, but are restricted from modifying anything else in the site. The 'Content Management' permission level is for that purpose not assigned to them on site level, but on the Pages library. On required permission for their author task this assignment is sufficient. But a flaw in SharePoint is that it checks in the 'Insert Embed-code' handling whether the 'AddAndCustomizePages' permission is granted to the logged-on author on site level.

With this insight / understanding on SharePoint level, the fix clear: make sure that all the page authors are also granted a permission level on site level that includes the 'AddAndCustomizePages' permission. And with that fix, all page authors are enabled / authorized to user-friendly apply 'Embed Code' in page edit mode:

Don't: Publishing + 'Anyone who can read items'

I got a Lync ('Skype for Business') call from a colleague informing me that the layout of our SharePoint 2013 based 'Digital Workplace' appears broken. I checked, and indeed it looked awful. So I asked in our team whether anyone was doing something to our intranet in production. After first denial (natural behaviour??), the perpetrator was identified. A developer had made a change to the masterpage, saved but intentionally did not publish to avoid that regular readers would already see it. Strangely however, as soon as saved, all intranet visitors saw his work - which was evidently still 'works in progress'. The explanation that all saw the unpublished version was quickly found: the Masterpage Gallery was incorrect set that 'Draft' items can be seen by "Anyone who can read items"... Corrected this to "Anyone who can edit items".

No silver bullet for multilingual SharePoint websites

In 2007 I wrote an advice on how-to deliver multilingual user experience in a SharePoint 2007 based public facing website. Althought the SharePoint Variations concept promised to fulfill this need, our experiences turned out differently. As result my advice was that we better just made a localized copy of the website per language.

This month I repeated the analysis on multilingual solution directions for SharePoint websites; now for SharePoint 2010 (and looking forward to SharePoint 2013). Sadly, the findings have not really improved compared to the 2007 support.

Aspects of multilingual in SharePoint sites

The information architecture of SharePoint based websites differs considerable from plain asp.net, php websites. SharePoint artifacts are typically administrated within the SharePoint content database, instead of physical files on the webserver. The SharePoint platform is also very rich with out-of-the-box capabilities and components that are used to construct a website. And for public facing websites it enables content managers to logical extend the websites with new content and composition pages.

In a SharePoint website the text displayed can come from any of the following places:

1. Contained within physical .aspx and .ascx files in the layouts folder; typically via asp.net Resources mechanism
2. Contained within code of SharePoint controls: standard and custom
3. SharePoint content database

On deeper level, the following multilingual aspects can be distinguished in SharePoint public facing websites

1. Multilingual of the SharePoint standard UI (MUI: Multilingual User Interface)
   • menu’s
   • list and libraries column names
2. Multilingual of custom developed SharePoint components
3. Multilingual of the SharePoint content
   • Publishing pages content
   • Static html in Masterpages, PageLayouts and SitePages
   • List and libraries items
   • Localized images
4. Multilingual of SharePoint navigation: Global, Current, Mega-menu
5. Multilingual of SharePoint search-discovery items: website title, friendly-urls

Solution directions

Manual website-copy per language

This is the most basic and also most flexibel approach. But it also implies that all multilingual aspects must be performed manual and repeated per language website-copy: at moment of the initial website provisioning, and later for each change to its information architecture and content. The latter also beholds a risk: site content manager forgets to propagate a change on the source site to one or more of the language copy-sites.

Site-copy per language via SharePoint Variations

Variations is an out-of-the-box capability of the SharePoint platform since 2007 version. The concept is that you declare one site in your sitecollection as the Variation root, and create + declare sites for other languages as so-called Label sites. Each change to site structure and publishing pages in the Variation root is propagated as draft to all Label sites. Per Label site, the content manager must next translate the propagated page(s), and publish them. Visitors do not see the content as it is propagated from the root site.

The most important limation of Variations is that it does not cover all the multilingual aspects. It only applies to publishing page content. SharePoint list and libraries are not in scope, and still need to be handled manual.

Another major limitation is that Variations cannot be applied as an afterthought to an already existing SharePoint site. It must be applied at start of provisioning the information architecture of the source SharePoint site.

In SharePoint 2007, the Variations functionality suffers from multiple issues that in general gave it a bad press; and there are very limited organizations that actually (trust to) apply it. In SharePoint 2010 the robustness of Variations behaviour should be a bit improved; but there are still only limited known practisioners in real world. Also noteworthy is that the STSADM VariationsFixUpTool is reported by Microsoft self to be still needed for fixing corruption in Variations Relationships list.

Multilingual in-place in the SharePoint site

The idea of this is that every localizable artefact (text + images) in the SharePoint site is inherent multilingual itself; and it server-side renders in the language of choice of the website visitor. Major benefit of such approach is that you avoid the need to maintain individual language site-copies consistent with each other. Most important limitation however is that it alone is not sufficent. You cannot apply this concept to out-of-the-box SharePoint menu’s, webparts and application pages, and also not without modification in SharePoint Web Content Management (Publishing Pages).

Multilingual via SharePoint Language Store

Basically a similar concept as ‘Resources’, and also somewhat comparable to the ‘in-place’ approach. Essence is that all text-parts are administrated in a Language Store that includes per text-part its translations in the multiple languages. The Language Store can be downloaded from CodePlex, however only for SharePoint 2007. It is not upgraded to SharePoint 2010. This approach has same limitations as the ‘in-place’ approach: does not work for SharePoint out-the-box ui-controls, menu’s, application pages, nor does it combine with SharePoint publishing.

Multilingual in SharePoint site via off-the-shelf products

Well, this in itself is a clear proof that multilingual is a complex matter in SharePoint context… The only 2 products found are from smaller and unknown companies (Oceanik and IceFire). Short evaluation of both propositions already demonstrates multiple shortcoming and functional-robustness issues – examples: mix language content on page, translation support not applied to standard SharePoint aspects (e.g. Reusable Content).

Conclusions

1. SharePoint multilingual is a complex matter.
2. Multilingual always implies extra work for SharePoint content manager → automatic text translation is yet immature to trust upon for public facing website
3. There is no 100% automatic solution for supporting all the SharePoint multilingual aspects

Unable to recover from a corrupted Publishing infrastructure

For a functional extension to the intranet (enterprise portal) of a client organization, we needed to provision a content page to an existing site. A precondition is thus that the Publishing infrastructure is activated within the context of that SharePoint site: at Site level (PublishingSite feature) and Web (PublishingWeb feature). Upon activating the latter we encountered the following error: Provisioning did not succeed. Details: Failed to create the 'Pages' library. OriginalException: The feature failed to activate because a list at 'Pages' already exists in this site. Delete or rename the list and try activating the feature again.

Strangly enough: via the SharePoint GUI the Pages library was not visible. Could be that it was set to hidden. But trying to directly navigate via its url merely resulted in a NotFound. Upon opening the site collection in SharePoint Designer, it showed there was a left-over of the Pages library: merely an empty folder, no Forms nor other content. But this presence was in the way of activating the Publishing feature. So we deleted this folder via SPD. And then tried to activate PublishingWeb feature again. This time it progressed a bit further, to stop with the message: The page you selected contains a list that does not exist. It may have been deleted by another user. Inspecting again: the Pages library was correctly available now, including associations with PublishingPage contenttypes. Missing this time was the Style Library documentlibrary. That is, when inspecting via SharePoint GUI. Again looking at filesystem level via SharePoint designer: same situation, Style Library folder present, but empty. Deleted this folder, and retried to activate the PublishingWeb feature. Sadly we kept on running into the error of missing List. Even after manually adding the Style Library; forcefully deactivate and re-activate the PublishingWeb feature. We did not manage to recover from the initial corrupted situation wrt Pages list. Search results on the Web for information on both the error messages gave some hits to problem descriptions, but sadly not to resolutions.

Due to a pressing time schedule, we therefore had to resort to a pragmatic alternative. Deleting the corrupted site collection, and re-creating it. This was a viable approach due to the current nature of the site collection: containing no content yet. But it leaves me with somewhat of a frustrated / disappointed mind. I would rather have seen us able to recover from the incorrect situation, while preserving the site collection.

AllUsersWebPart and SPWebApplication.ApplyWebConfigModifications don't match

• In a Feature, I apply the AllUsersWebPart construct to automatically add default webparts to all publishing pages based on the PageLayout File.
• In a Feature, I utilize the SPWebConfigModification class to add web.config modifications

When done in separate Features, both constructs operate successfully. However, when included within the same Feature activation, the invocation of ApplyWebConfigModifications method results in a SecurityException:

Access Denied
at Microsoft.SharePoint.Administration.SPPersistedObject.Update()
at Microsoft.SharePoint.Administration.SPWebApplication.ApplyWebConfigModifications()
at Microsoft.SharePoint.Administration.SPWebService.ApplyWebConfigModifications()

It looks as if internally SharePoint somehow puts a lock on the Administration persistent object. I tried to verify my suspicion via Reflector, but not surprisingly this internal code is obfuscated. The runtime error only manifests itself when the Feature is (re)activated via the GUI. The Feature activation via stsadm reports no problem, and successfully performs the deployment work.

Still, I want to hold on to the idea of one single self-contained Feature to deploy all the required parts. And I want to be able to turn the Feature on and off interactively via the SharePoint GUI (so that I can also operate the feature remote, without access to the deployment server). A resolution is to apply another approach to provision the default webparts on the pagelayouts. Besides the usage of AllUsersWebPart, it is also possible to directly include the webpart specifications in the PageLayout file itself:

With this construction, the invocation of SPWebApplication.ApplyWebConfigModifications method is done successfully. And as a bonus, also another problem is prevented; that of magically duplicating the default webparts provisioned via AllUsersWebPart upon Feature re-activation.

A final word of caution. With this approach I at first encountered another problem. When editing on a created publishing page the properties of the default WebPart provisioned via the PageLayout file, SharePoint displayed an error warning in the edit toolpane, "a web part you attempted to change is either invalid or has been removed by another user". Although the net effect of the WebPart settings is simple done, this is not very trustwordy towards the Web Content Manager. Hard to explain that they can just ignore this warning. Before deciding to then have to abandon the approach, I re-examed the default WebPart specification in the PageLayout file to see if anything there could be causing SharePoint to suspect a concurrent update. And yes there was, 'thanx' to the automatic editing behaviour of Visual Studio. When you add a control within an .aspx file, Visual Studio automatically add a default 'ID' property to the control. For the default WebPart however this is not needed, the property is actually set when creating a publishing page off this PageLayout. But the mere presence of it in the default part results in SharePoint detecting a concurrent update. So remember to don't include the 'ID' property within WebPart specifications included within PageLayout files.

PublishingWeb.IsPublishingWeb malfunctions on custom site definition

I typically apply a Feature-based approach for the provisioning of a SharePoint site into a full-functioning application . I prefer this above putting everything within a custom site definition. I'm in good company with my resistance against (overly complex) Onet.xml's [Andrew Connel, You don't need to create site definitions, Joel Oleson, Do you Really Need to Create Custom Site Definitions?]. I actually reuse the same site provisioning engine functionality within multiple SharePoint projects and applications. The reuse is made possible by specifying the provision actions via an XML feed file. Via this, the engine can be instructed to provision structure (Lists, Libraries), content (publishing pages, ListItems), and configuration (web.config via SPWebConfigModification, and PublishingWeb + SPWeb properties).

With respect to the latter, I discovered that the OOTB PublishingWeb.IsPublishingWeb sometimes plays tricks on you. Let me explain. In the provision engine I've implemented functionality to set diverse navigation settings: IncludeSubSites, NavigationShowSiblings, InheritGlobalNavigation, and so on. These properties can only be set on publishing webs, and are in the SharePoint Object API available via a PublishingWeb instance. In the engine code I first do a check whether the SPWeb on which the Feature is activated, is actually a PublishingWeb. And only then via PublishingWeb.GetPublishingWeb access a valid wrapper reference, and set the navigation properties.

This all worked fine in situations in which I applied the provision engine afterwards on an already created Publishing site collection. In my current project I do it slightly different. I've implemented a minimal site definition, and within the context of it activate per web in the created site topology the Publishing feature, and next execute the provision engine. In this setup, the navigation settings appeared to be ignored by the provision engine. When I debugged the provision execution, I discovered that PublishingWeb.IsPublishingWeb returned false for all webs in the site topology. Very strange, since I made sure to first activate the Publishing feature...

I ran into the forum-thread IsPublishingWeb() - what does it REALLY check for? posting a question on this issue. And followed up on the advice given there: implement an own SharePointHelper.IsPublishingWeb method to determine whether the SPWeb instance is valid for being wrapped into a PublishingWeb instance.

BTW: My own experiences learn that it is not due the asynchronous site creation behaviour. Also when later via site settings (de)activating the provision engine feature, PublishingWeb.IsPublishingWeb remains returning false, despite that the Publishing feature is activated on the (sub)web. It looks more as if PublishingWeb.IsPublishingWeb is somehow dependent on something that is set behind the curtains via OOTB Publishing site definitions.

Tip - HowTo Enable Anonymous Access to discussion board listview within a public readonly publishing site

For a public exposed website you'll need to enable anonymous access, to allow arbitrair visitors to see the published content, and search crawlers to index your site. You'll also want the site visitors to only be able to view the site contents, not to modify it.

There are some exceptions to this general permission rule. One is when the website contains 1 or more discussion boards. To enable any arbitrair visitor to participate in a discussion thread, she needs update permission rights within the SharePoint DiscussionBoard. In a former project we learned that it's not trivial to enable update rigths for anonymous users in a further readonly publishing SharePoint site. To spare you the time to discover yourself how to still achieve this, I decided to publish here the steps I needed to perform.

1. [Central Admin] create new web app
2. [Central Admin] create a site collection with Publishing Portal as template
3. [Central Admin] extend the web application for internet; and allow Anonymous.
   

   Note: in this stadium still WA allowed at the extended site.

4. [Site itself] open up the extended site; since WA allowed possible to change settings
5. [Site itself] enable anonymous access for entire site
   (site settings \ advanced settings \ settings \ Anonymous Access \ Entire Website)
6. [Central Admin] disable Integrated WA for the extended site to make it totally anonymous
7. [Shell/CMD on SharePoint server] !! toggle the lockdown feature on the extended site; and do either app pool recycle or IIS reset
8. [Site itself] provision a DiscussionBoard, and set its permission to allow anonymous access.
9. [Central Admin] re-enable WA on the extended site
10. [Site itself] allow anonymous access for both viewing and adding items on the discussionboard list
11. [Central Admin] disable again WA

This sequence of steps, and in this exact order, worked out for us. When deviating from it, we still experienced access denied issues; either upon trying to display the discussionboard ListView, or when trying to add a new thread or reply to existing discussion.

See also: Allow anonymous user access to display forms of discussion board list(view)

Tip – Provision custom publishing masterpage, pagelayouts and webparts always via a Feature with Site-scope, not Web-scope

The masterpage and webpart galleries for publishing sites live at the top level site (rootWeb) in a sitecollection, not at individual sites. This can be misleading, since every subsite get its own ‘_catalog/masterpage’ and ‘_catalog/wp’ folders. The Publishing functionality however only goes to the gallery at the top level site; for the masterpages (Site and System), pagelayouts as well as for building up the list of selectable webparts.
A best practice is to provision your custom masterpage, pagelayouts and .webpart definition files via a Feature. Thereby you must specify the level at which the feature is applied. For MasterPage, PageLayouts and .webpart files the appropriate level appears thus to be ‘Scope=Site’. However, it is also allowed to set ‘Scope=Web’, as long as you’re activating the web-scoped feature in the rootweb. But when you activate such a feature in a subsite, the results are less. It appears as if the SharePoint feature mechanism simple ignores the request to provision masterpage and pagelayouts into ‘_catalog/masterpage’, and .webpart files into ‘_catalog/wp’. They are simple not added anywhere. Not at the indicated subsite level, which would also be useless given the publishing behaviour. But also not at the rootweb level. Annoying is that no signal of this is given, no error reporting but simple ignored to provision the SharePoint files at the incorrect subsite level. Ok that stsadm doesn’t signal it, but I would have expected an error indication when activating the feature via the GUI. And at the least I expected to find some information about it in the extensive SharePoint logs in the 12hive. In reality none, instead the feature framework just silently ignores the feature specifications which are logically incorrect when activated at subsite level.

So, what then to do when you what to provision content to a publishing site at subsite level ? I recommend the following 2-steps approach:

1. Provision your masterpage, pagelayouts, and .webpart files to the catalog gallery at rootlevel; apply a Feature with scope = Site.
2. Provision your site structure (libraries, lists) and content via a Web-scoped Feature; and activate this against your specific site, the root or a child subsite. E.g. http:<root-entry>/Intranet