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
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
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)
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.
<Override xpath="/CommunityServer/CSModules" mode="add"> <!-- Register your CSModules Here –> </Override>
<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).
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
(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
(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
(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.
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.
A section is a Forum, a Weblog, a MediaGallery or a Hub.
Post is the base class to store blog posts, blog comments, media gallery posts, media gallery comments and forum posts
Messages include Conversations, Activity Messages, Announcements, Profile Comments and Status Messages.
Again I’m not providing descriptions because the events are self explanatory.