We are trying to enable SiteEdit editing in a page conformed by several sections, each one is shown as an include of another page.

We are using SDL Tridion 2011 SP1 and SiteEdit 2009 SP3. SiteEdit is working correctly in another sections of our site, but in this specific case we faced some troubles:

  • SiteEdit seems to be included, and in fact if we enter to each page included separately all of them show SiteEdit as enabled, but otherwise when we enter the "main" page only the last include is enabled for editing. No matter which one, only the last one everytime.


  • Other problem is that, in a single section conformed by different component presentations disposed horizontally, SiteEdit borders and "pencils" appear superpossed, not respecting the layout of the page. [EDIT: Problem solved].

Could anyone help? As I said, in other pages of the site SiteEdit, or the own includes separately, both problems seem to work correctly.

  • Welcome to the community and posting a clear question. Is this behaviour happening up for all the browser or a specific browser (specifically on IE)? Aug 5, 2014 at 8:27
  • Thanks for the welcome, and for the previous service received as an annonimous consultant of StackExchange, I hope my future contributions to this site are worth. Answering your question, it happens for all browsers.
    – G. López
    Aug 5, 2014 at 8:49
  • Do you need SiteEdit for the pages when they're not referenced as includes to that combined page? Perhaps the SiteEdit script from each included page conflicting when on the combined page. To test, try removing the SiteEdit page markup from each section and checking how the combined page responds. Aug 6, 2014 at 3:30
  • Alvin: I've already tried as you suggest, and I'm checking that SiteEdit works correctly with components of the current page "main" and only one include (the last one added), and I need to enable SiteEdit in every page included in the main (as I said, every include has SiteEdit enabled individually). Maybe SiteEdit has these limitations (at least the version I'm using)? That's something unknown for me.
    – G. López
    Aug 6, 2014 at 7:48

1 Answer 1


SiteEdit 2009 uses a single Page TCMURI for tracking the current page. It neither has the option to work without a page, nor to work with multiple pages at the same time.

So no matter where the Component Presentations in the HTML come from. For every CP it checks whether it can find that Component Presentation in the current Page XML in the CMS.

  • If it finds the Component Presentation in the XML, it makes it editable (depening on your permissions of course).

  • If it doesn't find the Component Presentation in the XML, it assumes that the Component Presentation was removed from the Page and shows the "not editable, it is gone" icon.

The second situation is unwanted in the case that you intentionally put Component Presentation on the page HTML that are not part of the Page XML in the CMS. You have one such case here, but there are others... such as when you dynamically put Component Presentations on a page based on a query.

For such situations you can put the "IsQueryBased" : true attribute in your SiteEdit comment. This essentially tells SiteEdit "It's OK. I know this Component Presentation is not in the Page XML, just allow me to edit its content anyway.". SiteEdit will enable content editing actions in this scenario, but will keep actions related to the page (such as moving/removing the CP) disabled.

These questions and their answers may be helpful for you:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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