Blog

The “Remove Format” button () within FCKEditor, only removes valid inline elements such as: strong, span, strike, font, em, etc.

If you want to be able to make the Remove Formatting function more flexible so that it removes block elements, you can do so by modifying the “fckconfig.js” file found within the FCKeditor folder.

Search for the “FCKConfig.RemoveFormatTags” line, which will look something like this:

FCKConfig.RemoveFormatTags = 'b,big,code,del,dfn,em,font,i,ins,kbd,q,samp,small,span,strike,strong,sub,sup,tt,u,var';

All you need to do now is add any additional elements you wish to remove from your content. In my case, I wanted the Remove Formatting button to remove all header tags. So I carried out the following:

FCKConfig.RemoveFormatTags = 'b,big,code,del,dfn,em,font,i,ins,kbd,q,samp,small,span,strike,strong,sub,sup,tt,u,var,h1,h2,h3';

I have been developing custom web parts and SharePoint customisations for a couple years now. During the early stages of SharePoint development I found a great deal of confusion when trying to retrieve information from different areas of an intranet through using the SPSite and SPWeb methods.

I think any other developer who is starting out SharePoint development may encounter the same issue. What I found useful was the “Site Architecture and Object Model Overview” diagram from the MSDN site.

It nicely breaks down the architecture of a SharePoint site. I highly recommend that you take look at the following links containing more diagrams:

• http://msdn.microsoft.com/en-us/library/ms473633.aspx
• http://technet.microsoft.com/en-us/library/cc263199.aspx

Whilst I am talking about SPSite’s and SPWebs’s in this post, I’ll give you quick overview on how they work using the (above) diagram. Basically, the top level site collection (SPSite) contains your root web (SPWeb) and subsites (SPWebs under SPWebs). So, a subsite will be any site (SPWeb) under the top level web site in a site collection (SPSite).

In light of what has happened recently with some 150,000 Google Account holders loosing their information due to a mishap at Google HQ over the weekend really reinforces the fact that our data is not safe…even in the “cloud”.

At the end of the day our information is stored on hardware that can fail. I think that this whole “cloud computing” malarkey has got all lured into a false sense of security where we think we don’t need to take measures to ensure our data backed up on a regular basis. I have to admit, I too have become a bit tardy when it comes to backing up my online data. If a large company like Google can get it wrong, what hope is there for other companies offering the same thing?

I practically live on the “cloud” in terms of what Google has to offer. I use their email, calendar, document and notebook applications. Even their mobile phone OS: Android! Luckily, there are steps we can take to ensure our data is backed up on your own terms:

	Google Calendar Google Calendar is the one application I use the most. If I lost all my data, I would quite annoyed to say the least (and be very disorganised). You can backup all your calendar entries by opening your calendar settings, click on Calendars and select “Export Calendars”. A zip file will be created containing your calendars in a .ical format.
	Gmail This a simple one. Use an desktop email client such as Thunderbird (or any other client you prefer) to download all your emails directly to you computer through POP access.
	Docs If you only store a handful of documents in your Google Account, you could just download them one-by-one. Understandably, if you have a long list of documents a more automated approach is required. Lifehacker.com shows a really great script you can use to that allows you to download documents in whatever format you require. Take a look here.

Hooray! Our data is saved!