run code on every page load

Rita Mikusch asked on February 7, 2017 22:43

Hi,

(Version 8.0)

I have a piece of code that I'd like to run on every page load.

I could create a custom RequestEvents handler ... but there are several items requested for every page load, so it'll run MANY times per page load.

I could create a webpart and add it to the master file. But if somebody creates a new master file for a new section of the website, they might forget to add that webpart to it.

What other options are there to run a piece of code on every page load?

thank you, Rita.

Correct Answer

Peter Mogilnitski answered on February 8, 2017 17:12

Rita,

I see what you are saying. Your handler is called a few times because these are a few different requests.

If you take a look at the actual URL (put a break point in the code below) of your requests you'll see that these are calls to images, web services etc in addition to your actual page call. The first call is your page and then a browser (while it parsing the returned content) starts downloading images, running scripts and it produces several extra calls to the server that go in the same pipeline where your event handler is hooked. 

    RequestEvents.Begin.Execute += (sender, args) =>
    {
            var r = System.Web.HttpContext.Current.Request;
            var url = r .Url;
            var contentType = (r.AcceptTypes!= null)? r.AcceptTypes.FirstOrDefault() : "";
            var extension = String.IsNullOrEmpty(r.CurrentExecutionFilePathExtension)? "": r.CurrentExecutionFilePathExtension;

            if (contentType == "text/html")
            {
                // process here.
            }

    };

Images will have "image" present in there content type, web services will have " * /*". Your actual page will have "text/html".

0 votesVote for this answer Unmark Correct answer

Recent Answers

Zach Perry answered on February 7, 2017 23:04

Have you looked into the custom events?

Guessing this has something to do with your previous question

1 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on February 7, 2017 23:16

Regarding the webpart, what development mode are you running? Are you using portal mode or aspx mode? If portal, then I'd assume if someone creates a new master page it would be a developer of some sort and not a content editor. If you're using ASPX then all of your master pages will inherit that code so no need to worry about including it on every page or master page because it should already be included.

0 votesVote for this answer Mark as a Correct answer

Rita Mikusch answered on February 8, 2017 01:11

Thank you, Zachary.

Yes, that previous question was also mine. I've been experimenting a bit ... but now I've actually got to get this thing done :).

I'm unsure about how I would use these "custom events". All of the templates on our site are "portal pages" ... does that mean PortalTemplate.aspx.cs is the basis for every page on our site? In which case I would add the custom event handler to that class? Is there a better place to put it?

From what I've read elsewhere, changes I make to PortalTemplate.aspx.cs are lost everytime kentico is upgraded ... though I guess that won't normally happen very often.

0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on February 8, 2017 10:41

Hi Rita,

I would like to add to what Zachary posted - global event handlers.
Here, you will see an example of the event handler and also where to create the code to be upgrade/hotfix safe. Plus, you may need to use the events mentioned in Zach's link.

0 votesVote for this answer Mark as a Correct answer

Zach Perry answered on February 8, 2017 22:13

Did you look at the cms page events in the link I provided? You should be able to do what you want by using the CMS.UIControls.CMSPage.OnAfterPageLoad event.

0 votesVote for this answer Mark as a Correct answer

Rita Mikusch answered on February 8, 2017 22:36

Thank you everybody, I have something workable now!

I finally got the CMSPages event handler working (ugh had a stupid error in the code), though I ended up finding the RequestEvents handler easier to deal with.

With RequestEvents, it was easier to understand when and why it was being called, and therefore easier to filter out the calls I didn't want.

I used Peter M's code to filter out the content types that I didn't want the handler to run for. And I filtered out any paths that started with "/admin/" or "/CMSModules/". So now the RequestEvents handler is just running for the live site page loads (according to the limited testing I've done so far :)).

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.