CSModules allow you to plug into Community Server and run your own code when certain events happen.

In fact CSModules are so good that a lot of Community Server functionality is implemented through CSModules (77 are used out of the box!). This means you can remove or replace Community Server functionality without having to touch the core source code. Examples of functionality implemented with CSModules include

  • Activity Message Logging
  • Email Notification
  • Points
  • Spam Filtering

Creating a CSModule

To create a CSModule you need to create a class that implements the CommunityServer.Components.ICSModule Interface. This interface has one method – Init – with two paramaters

  • CSApplication – this contains the events you want to hook into
  • XmlNode – This is the XmlNode that was used to register the CSModule. This can be used for custom configuration options.

Additional events for Wikis are available by hooking into events in CommunityServer.Wikis.Components.WikiEvents.

Once you’ve created your CSModule, you need to register it so that CS knows to use it. CSModules are registered in the <CSModules> section of communityserver.config. To add your custom module, just add a new node to this section with the following markup.

<add name="Your_Module_Name" type = "Namespace.ClassName, Assembly" />

(n.b. where possible you should use an override file to do this – see below)

Tips and Tricks

Register / Remove CSModules with Override Files

For a more detailed explanation of Override files and why you should use them, read this article on Override Files.

Essentially by using a communityserver_override.config file to register CSModules you make upgrading to future versions of Community Server easier.

Below are two example overrides for adding and removing CSModules.

  • Add a CSModule
    <Override xpath="/CommunityServer/CSModules" mode="add"> 
    <!-- Register your CSModules Here –> 
  • Remove a CSModule
    <Override xpath="/CommunityServer/CSModules/add[@name='ModuleName']" mode="remove" />


Events on the CSApplication object in the ICSModule Init method do not fire for Wikis. To hook into events fired for Wikis, you should hook into events in the CommunityServer.Wikis.Components.WikiEvents class (in the CommunityServer.Wikis assembly).

Pre or Post (Before or After in WikiEvents)

When you look through the list of available events, you’ll often see two similar events – one PreSOMETHING and another PostSOMETHING. The difference between the two is the Pre event is fired before the object is saved or deleted to the database, whereas the Post event is fired after

  • Pre / Before – use this version of the event if you want to make changes to the object that you want persisted in the database.
  • Post / After – use this version of the event if want to run code after an action has successfully completed.

Object State

(N.B. Doesn’t apply to Wiki Events)

Most events fire when a relevant object is being created, updated or deleted. However you may not want to run your code in all these scenarios. To determine the scenario you’re in, you should look at the State property of the event’s EventArgs

  • ObjectState.Create – the object is about to be added to the database for the first time(Pre / Before) or has just been saved to the database for the first time (Post / After)
  • ObjectState.Delete – the object is about to be deleted from the data store (Pre / Before) or has just been deleted (Post / After)
  • ObjectState.Update – the object has been previously saved to the database, but is about to be updated in the data store (Pre / Before) or is has just been updated in the data store (Post / After)

Application Type

(N.B. Doesn’t Apply to Wiki Events)

The SectionGroup, Section and Post events fire regardless of whether the object is to do with Blogs or Forums etc., but you may only want your code to fire in one scenario. For that you should check the ApplicationType property of the event’s EventArgs.


You may have noticed that the CSModule Init event has two paramaters – the CSApplication which provides the events to hook into, but also an XmlNode. This is the xml node which you used to register the module in the <CSModules> section of communityserver.config.

This means that you don’t have to hard code variables into your CSModule, and can instead specify them on the XML Node you use to register your module – this means you can change the variables at a later date without having to recompile your module

Troubleshooting CSModules

  • Make sure your Module class is marked as public
  • Changes made to communityserver.config (or communityserver_override.config) may not take effect until your website is restarted. You can force a restart by touching the web.config file.
  • Check the Community Server event logs – events are recorded there if CSModules can’t be loaded.

CSModule Events

(N.B. for wiki related events, refer to the WikiEvents section below)

I haven’t included descriptions of most events because they’re fairly self explanatory.

  • Pre...Update events are fired before the ... object is added, updated or deleted from the data store
  • Post...Update events are fired after the ... object is added, updated or deleted from the data store

For those events which aren’t so self explanatory, descriptions have been included


These events are for Section Groups, not Hubs (which are called Groups in the front end). For Hub events use the Section events.

  • PreSectionGroupUpdate
  • PostSectionGroupUpdate


A section is a Forum, a Weblog, a MediaGallery or a Hub.

  • PreSectionUpdate
  • PostSectionUpdate


Post is the base class to store blog posts, blog comments, media gallery posts, media gallery comments and forum posts

  • AuthorizePost – Never Fired
  • PreProcessPost – Fired before just before the PrePostUpdate event
  • PrePostUpdate
  • PostPostUpdate
  • PreRenderPost


  • PrePostAttachmentUpdate
  • PostPostAttachmentUpdate


  • UserValidated – Fired after a user’s credentials are verified
  • UserKnown – Fires as soon as CS knows the user who is viewing the page (this may be the anonymous user)
  • PreUserUpdate
  • PostUserUpdate
  • UserRemoved – Fired after a user is removed from the data store


  • PreUserInvitationUpdate
  • PostUserInvitationUpdate
  • UserInvitationAccepted


  • PreUserFileUpdate
  • PostUserFileUpdate
  • PreUserFolderUpdate
  • PostUserFolderUpdate


  • PreFriendshipUpdate
  • PostFriendshipUpdate


Messages include Conversations, Activity Messages, Announcements, Profile Comments and Status Messages.

  • PreMessageUpdate
  • PostMessageUpdate
  • PreMessageRender
  • PreSearch
  • PostSearch


  • PostConfigurationInitialized – Fired after Community Server loads configuration data for the first time.
  • PreConfigurationUpdate
  • PostConfigurationUpdate


  • Category – fired whenever a PostCategory (Tag) is updated or deleted (but not created)
  • Rate – Fired after any content is Rated
  • Favorite – Fired whenever an item is added or removed as a favourite.
  • SectionMembership – Fired whenever a user joins or leaves a Hub.
  • CSException – Fired whenever an ASP.Net exception is thrown at the application level.

Wiki Events

Again I’m not providing descriptions because the events are self explanatory.


  • BeforeAddWiki
  • AfterAddWiki
  • BeforeUpdateWiki
  • AfterUpdateWiki
  • BeforeDeleteWiki
  • AfterDeleteWiki


  • BeforeAddPage
  • AfterAddPage
  • BeforeUpdatePage
  • AfterUpdatePage
  • BeforeDeletePage
  • AfterDeletePage
  • RenderPage

Page Comment

  • BeforeAddPageComment
  • AfterAddPageComment
  • BeforeUpdatePageComment
  • AfterUpdatePageComment
  • BeforeDeletePageComment
  • AfterDeletePageComment
  • RenderPageComment

Page Revision

  • RenderPageRevision