HXH
HXH
May 11, 2010
visibility 5142
star star star star star
(0 votes)

Adding an Additional Layer of Logging to EPiServer Actions

Part of my standard Workflow Implementation is an additional layer of logging that sits in a table outside of the standard EPiServer installation. I’ve found that keeping a record of a few basic EPiServer actions can really help to paint an accurate picture of which editors are doing what.

To log the actions as they are executed, I first created a custom property with the [PagePlugIn] Attribute. I then created a method called Initialize, which adds additional processing capabilities to events exposed through DataFactory.Instance.

The result is something like the following:

    [PagePlugIn]
    public class CustomPageActionControl
    {
        public static void Initialize(int bitflags)
        {
            DataFactory.Instance.SavedPage += LogSaved;
            DataFactory.Instance.PublishedPage += LogPublished;
            DataFactory.Instance.MovingPage += CheckIfDeleting;
        }

private static void LogSaved(object sender, PageEventArgs e)
        {
            LoggingTools.LogVersionStatus(e.Page, "Saved", "Details: Version saved.", EPiServer.Security.PrincipalInfo.Current);
        }

        private static void LogPublished(object sender, PageEventArgs e)
        {
            LoggingTools.LogVersionStatus(e.Page, "Published", "Details: Version published", EPiServer.Security.PrincipalInfo.Current);
        }

        private static void LogReadyToPublish(object sender, PageEventArgs e)
        {
            LoggingTools.LogVersionStatus(e.Page, "Publish Requested", "Details: Version marked as Ready to Publish. ", EPiServer.Security.PrincipalInfo.Current);
        }

}

This could be enhanced to log additional system actions..or be made more flexible so I’m only calling one Log procedure and then have some logic within to determine what the appropriate message should be… but you get the idea.

May 11, 2010

Comments

error Please login to comment.
Latest blogs
Surviving a Dirty Feed. Part 3: Error Handling and Event Batching

Committing a 250,000-row Optimizely catalog import row by row, returning a per-row failure report, and coalescing catalog events into one per batch.

Stanisław Szołkowski | Oct 16, 2026 |

Building UI Extensions for Optimizely SaaS CMS

Introduction Developers have been extending the functionality of Optimizely PaaS CMS for years using addons built in C# and deployed as NuGet...

Mark Stott | Oct 15, 2026

Cheapskate AI Translator: Because Translation Should Not Require a Second Mortgage

There is a particular kind of software project that begins with a detailed architecture document, a product roadmap, and a carefully assembled...

Linh Doan Cuu | Oct 15, 2026

Computed Fields in CMS 13 Content Contracts with Optimizely Graph

Content Contracts in Optimizely CMS 13 allow different content types to share a common structure when querying Optimizely Graph. But what if the...

Mardy | Oct 14, 2026