Try our conversational search powered by Generative AI!
AI OnAI Off
CreatingPage event inconsistent?
Just to keep viewers updated EPiServer have registered 2 bugs:
#9635: When using the event CreatingPage or SavingPage to save properties, then the page has to be reloaded to see the changes in edit mode.
#9712: Importing will trigger the SavingPage event twice
EPiServer support acknowledge that it's impossible to reliable tell the difference between a copy operation and a create page operation from within the CreatingPage(SavingPageArgs) event. You'll only find out afterwards when either your property is set (create) or not (copy).
However, I was able to work around this problem, thanks in part to Steve Celius (general EPiServer genius) by using the HttpContext.Current.Items to store a flag during CreatingPage(CopyEventArgs) that can be picked up by subsequent events in the request to tell the difference between the two scenarios.
The downside of this is that it will break if you copy pages in a scheduled job, because there's not HttpContext.Curren, of course :)
The EPiServer Event "Items" property is also unfortunately useless here, because the Items property passed seems to be in pairs, so the Items in CreatingPage(Copy) and CreatedPage(Copy) are the same. SavingPage, SavedPage are the same, CreatingPage(Saving), CreatedPage(Saving) are the same, and so on.
Andy
Apr 18, 2008 13:46
Hi all,
Can anyone tell me how to tell a CreatingPage event (DataFactory.Instance.CreatingPage) has been originated from a page created by an editor directly and a page created as a result of a page copy operation please?
Basically I need to set a page property during the CreatingPage event. This works absolutely fine when creating a page in edit mode using the normal "Create Page" operation:
1. Intercept the CreatingPage event
2. Set the property on the Page object passed in the SavePageEventArgs
3. Success!
However, when copying a page, there are two CreatingPageEvents fired:
1. CreatingPage (CopyPageEventArgs)
The Page parameter is null, so no setting properties here!
2. Creating Page (SavePageEventArgs)
The Page parameter is not null, but if I set a page property here it is lost because of the next events...
After this the following events are fired:
3. CreatedPage (SavePageEventArgs)
Page parameter still reflects updated value
4. SavingPage (SavePageEventArgs)
5. SavedPage (SavePageEventArgs)
(then events 6 & 7 are repeats of 4 & 5, EPiServer support confirms this is a bug, so ignore these)
7. CreatedPage (CopyPageEventArgs)
The page parameter shows the properties I set are overwritten by the data copied from the source page.
--
My initial solution idea was to wait for CreatedPage(CopyPageEventArgs) and reset the property there, but that doesn't work because then the code that should set the property during "normal" page creation operation needs to set the property there.
So, basically, I can fix this *if* I can tell the difference between:
1. CreatingPage (SavePageEventArgs) - as fired as part of a "normal" page create creation, and
2. CreatingPage (SavePageEventArgs) - as fired as part of a copy/paste operation.
But I can't see a way to do it, can anyone help me please?
I've raised this here as I think there's 3 bugs in EPiServer here:
1) It not possible (hopefully I'm wrong here!) to tell the difference between two CreatingPage events which have different behaviour
2) It is not possible to modify a page's properties during a page copy operation.
3) There is incosistent behaviour and conditions in the CreatingPage event.
-- FOOTNOTE
The best solution I've thought of so far to try setting a flag during CreatingPage(CopyPageEventArgs), to remind me to not try setting the property during CreatingPage(SavePageEventArgs); then unsetting it again in CreatedPage(CopyPageEventArgs), however I don't know whether this will work when:
1) Copy a deep hierarchy of pages
2) Copy in a multi-threaded environment.
3) If another CreatingPage event handler set CancelAction = true thus causing the other events to not be fired (in principle) and I'll never unset the "ignore" flag.
Basically, this solution seems to be highly dubious and there's too many assumptions for me to be confident that it will work in all scenarios.
-- END FOOTNOTE
Best Regards,
Andy