I am looking for a supported way to cause the XPM indexing function to reload part of a page (or the whole page) without actually causing a full browser page load or refresh. The reason I ask is (you guessed it) to design a Single Page Application that uses asynchronous Javascript (AJAX) to load sections of the page instead of making full page requests.

As far as I can already tell, XPM indexes the page using the Site Edit markup after the OnDOMLoaded event. I've seen posts about using client side MVC frameworks and making sure that the markup exists prior to this event firing, but what I want to have is a way to trigger the XPM functionality to re-index a set of elements for editing after the initial indexing already happened (through Javascript preferably).

This is for Tridion 2013 +

Thanks ahead of time!

  • My colleague was wondering out loud if Single Page Application's could have a bookmark to a certain location in the application. Maybe something like "URL hash" techniques would let you refresh anyways?
    – Alvin Reyes
    Mar 21 '15 at 3:42

If it is really for 2013 + then you could be in luck, provided you wait long enough (I'm hoping we will get it in 2015 ;o).

Unfortunately currently there is no way of telling XPM to reindex the page, it does this automatically as soon as the dom has loaded for the first time, and it ignores changes of the dom (as you already found out).

I discussed this with the developers a while ago, checking if I could perhaps call an unsuported method to reindex, but it is simply not there. If we were to try, we will probabaly end up with all stuff being indexed twice and XPM failing.

  • Thanks Bart, that's pretty much what I figured, but at least as I was hoping, it sounds like it's on the roadmap! And wow -- you pretty much answered my next question as I was typing it: How about any "unsupported" ways to do this? I'm guessing based on your edit that the only way to hack this would be to reverse engineer the majority of the XPM code and re-write a portion of it to properly re-index parts of the page? Sounds like a bit of overkill, I suppose waiting for support is the best option Mar 20 '15 at 15:29

I've marked Bart's answer as correct but I just wanted to share a little of my own research:

XPM seems to works primarily off of event listeners that are attached to the document object of the inner iframe (the frame that is running the content delivery website). If you are ok with a completely unsupported approach, you should be able to theoretically remove those event listeners from the document and call those JS methods that start the re-indexing of the page.

Where the hacking starts is removing the event listeners. Currently, those event listeners are added via anonymous functions so they're not able to be removed as they are. Theoretically (again) you should be able to override document.addEventListener and keep track of all event listener functions added to the DOM. In this way, you have a reference to the event callbacks and can therefore use document.removeEventListener().

Note: This is pretty crazy and goes completely outside of the expected functionality and behavior of XPM. Should only be approached with the full knowledge that it would be a hack, likely detrimental to performance, might not work in all browsers, and is liable to break with new Tridion versions or hot fixes.

  • Thanks for the added info Josh. As Bart said, we are looking into this.
    – Nuno Linhares
    Mar 21 '15 at 12:39
  • Hey Nuno -- looking forward to it! Thanks for confirming Mar 21 '15 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.