I’m a huge fan of the Telerik RadEditor for rich-text editing in SharePoint 2007, however, since it’s release, there has been a very frustrating issue with the Reusable Content functionality in the control.  It hasn’t worked.

The core of the issue is that the relationship between the Reusable Content fragment and the Reusable Content list is severed when the page is saved.

You can read about the issue on WebGrizzly’s blog, as well as on Telerik’s site both here and here.  There’s even a post where Telerik says that they have done all they can and don’t think it’s possible to have Reusable Content in the RadEditor.

I didn’t like the sound of this, as I HAD to have this working in the RadEditor for a custom Feature I was working on, so in I dove.  By walking down the path that the content takes in SharePoint’s default rich-text-editor, I found that it’s a combination of both client-side and server-side code that makes Reusable Content possible.

In order to fix the RadEditor, you have to do a bit of custom coding.  I’m not going to go into Solutions or Features here, as you already should know how to create them if you want to fix the control, and to make things easier, I’ve posted the class file on CodePlex.  Essentially, you need to create your own custom implementation of the RadEditor by inheriting from the RadHtmlField and drawing the code out a little further to add the needed client-side and server-side processing to wire up the functionality.

If the task of creating your own implementation of the RadEditor seems a little daunting, trust me, it’s not that bad, and it’s completely worth it.  As you already know, the RadEditor is awesome, and Telerik’s controls are some of the best out there.  The controls in Telerik’s ASP.NET AJAX suite even work in SharePoint, and if you get the full version of the RadEditor for SharePoint, you actually are getting the full suite.

Download the RadEditor Reusable Content fix

So – you may be wondering, have you shared this code with Telerik?

I actually contacted Telerik and was surprised by the response I got.  I was asked if I had tested this fix with the blog and wiki editors, as well as the web part editor.  Telerik was also curious if I was able to fix the Reusable Content fragment selection dialog box (_layouts/ReusableTextPicker.aspx) in Firefox, as they were hesitant to implement code that still exposed some issues related with Reusable Content. I responded with my opinion that it shouldn’t matter as Reusable Content is a component of the Publishing Feature – the classname of the ResusableTextPicker is Microsoft.SharePoint.Publishing.Internal.CodeBehind.ReusableTextPickerPage – and the button for adding Reusable Content is on the toolbar of the out-of-box text editor for Publishing Fields.  The blog and wiki templates are part of WSS, not SharePoint, and the content editor web part, even added to pages on Publishing sites, does not have the ability to add Reusable Content.

As for the errors on the ReusableTextPicker page in FireFox, I don’t feel that it should be Telerik’s responsibility (or mine of that matter) to fix it. That problem is caused by the JavaScript used to retrieve the values of the expando attributes on the table rows of the page as it’s shipped by Microsoft.  If only they had used JQuery…

One final thing – this is not supported by Telerik!  If you implement, you have to give thought about your upgrade path when Telerik releases a new version of the assembly.  Also, I’m leaving my code in beta for right now as I’m the only one i know of that’s used it, so if you give it a shot, please let me know how it works out for you.

Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom column and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature, and this is why I created SPSource.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with (and has been tested with) WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as either part of the build process, or separately as a CMD file at the root of the project. By using the UI and SPD, items can be created and tested rapidly, then compiled into the WSP for deployment using familiar tools.

Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a pre-existing Visual Studio WSP project. SPSource will also create the file provisioning modules and site Content Type/Column definition files, as well as the lines needed in the ElementManifest section of the Feature.xml file.

Some examples of how SPSource can help:

• Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

• Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

• Add a custom Content Query Web Part (or RSS) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Eventually, I hope to get SPSource working with ListInstances and Workflows, but for right now, it only works with Content Types and Modules.

Check out this screencast where I create a custom Publishing Feature, with a new content type and page layout, execute SPSource on my StsDev Visual Studio project, package it all up in a WSP, and deploy in less than 15 minutes!

SPSource Publishing Feature Demo

Here's a short walk-through example of how SPSource works:

In the 'design' site, create a new Content Type for a Publishing page using the SharePoint UI, adding some new columns

In SharePoint Designer, create a new Page Layout based on the Content Type which was just created

Still in SharePoint Designer, add the new content field controls, a web part zone, and some other markup to the new Page Layout, saving it to the 'design' site Master Page Gallery
 


Now, over in a Visual Studio project, which in this example is based on StsDev, create a new Feature, and create some new Folders in that Feature. The folders aren't important in this case, they just allow for some organization.  SPSource has been tested using WSPBuilder, StsDEv, and WspProjectTemplate, but the type of project in Visual Studio really doesn't matter. It just needs to follow the 12Hive folder structure, which means SPSource does not work with VSEWSS.

In each folder, create a new file with the file extension '.spsource'.  This file extension is important, as the SPSource utility looks for these files to work it's magic.  The SPSource files are nothing more than a type of XML file and are what I call 'reverse manifests' as they are based on the same syntax used to push things into SharePoint, but in the case of SPSource, are used to get things out of SharePoint.

The SPSource file for the Content Type is just like a Content Type definition file, and is even based on the same schema. All we need is the name of the custom Content Type we want to have included in the WSP

The SPSource file for the custom Page Layout is also just like a provisioning module file used to put files into SharePoint. We just need to tell it the source list URL, and the file to include in the WSP

At the root of the Visual Studio project, I've got a CMD file that contains the information needed to execute SPSource


Source of CMD file

After SPSource is executed, there will be some new files in your Visual Studio project.

In the ContentType folder, there are now files for both the Content Type definition, as well as the column definitions.
Content Type definition:

Column definition:
 

The ASPX page in the PageLayouts folder is the same as what we added in SharePoint designer

The pagelayouts.Provisioner.xml file is the provisioning module file needed to put the custom Page Layout in to the correct location when the Feature is activated

The two *.ElementManifest.xml files are there so you have the lines needed to add to the Feature.xml file in the ElementManfiests section.  These lines are not automatically added to the Feature.xml as to provide greater flexibility by you to distinguish what gets included in the Feature.

After I add the lines to the Feature file:
 

Now I can build my project to compile the WSP and deploy it to the 'development' site.  SPSource can also be integrated with the MSBuild process to allow for updates to the files added by SPSource before the WSP is compiled.  This allows the WSP to be upgraded using items changed in the UI and SharePoint Designer.

After the solution is built and deployed, the Feature can be activated, and the pages will be added to the Master Page Gallery
 

Master Page Gallery


When I create a new page, the new Page Layout is available in the list, as expected
 

and, the page looks the way it should

Give SPSource a try, and see how much more efficient your Visual Studio WSP creation process can be!

Recently, I've seen a bunch of announcements about new public-facing Internet sites being released out into the wild running on SharePoint.  This is awesome because it's great to see people catching on to the web content management features in the product.  I do need get something off my chest, though...

If you've got a public facing SharePoint site that allows anonymous access, ACTIVATE THE ViewFormPagesLockDown FEATURE!!!!!!!

This is especially true if you've spent any amount of time customizing the branding of your site.

Sezai has a good post on the Feature, and the TechNet documentation provides the details.

ViewFormsPagesLockDown is a MOSS-only Feature (not in WSS) that does a couple things:

1) Allows users to only view the Publishing pages in your site, not any of the form or view pages (DispForm.aspx, AllItems.aspx)
2) Disallows anonymous access to pages in the _layouts directory that inherit from LayoutsPageBase.

This Feature is active on the Publishing Portal site definition by default, but NOT on the Collaboration Portal site definition.

Without this Feature active on anonymous public sites, any and all users - including search engines like Live and Google - will be able to view (and crawl) SharePoint out-of-box pages which are tied to lists and webs that allow viewing by anonymous users.  These users might not have the ability to do anything, but it most likely will not be what your organization would prefer of them to view.  In some cases, you might not care, but keep reading...

If you want to see some interesting and scary stats on how many sites there are that have NOT got the ViewFormPagesLockDown Feature activated, check out this result-set from Live Search.  Currently Live Search is returning 29,200 results, some being duplicates from the same site, but they are all links to sites that have the Publishing Feature installed, allow anonymous access, and have not activated the LockDown Feature.  It's also a great result set to see some public-facing SharePoint, but that's not the point.

This is an easy fix! Activate the Feature! Please rest assured, though, that if this Feature is not active, and your site security is configured correctly, anonymous users should not be able to do anything in your site.

One thing to note for you MOSS devs out there, I found that the lock-down on _layouts was a bit of a problem because I sometimes like to put custom application pages in the _layouts directory which I want to be hit by anonymous users.  To get around the lock-down, there's the UnsecuredLayoutsPageBase class you can use as the base class of your page, and there's always just the Page class as in a standard ASP.Net application page.