Hi Deane!

We do not have any known bug at the moment that match your description. Our guess is that the property/properties that you want to replace with fetched data might not be null. Could you check these properties (either in the database or in code) to see if they are null. It could be a problem with a blank space or similar that is entered when creating new pages thus not making the property return IsNull which results in the value not being replaced.

Regards
Linus Ekström
EPiServer Development Team

Has this functionality always worked this way?

I had a similar situation creating some demo templates in CMS6, where the 'Fetch content from another page' functionality didn't work as I expected. It was as Linus said because one of the page properties was non-NULL.

This just seems counter-intuitive to me and not particularly user friendly. There should at the very least be a notification displayed informing the user that the functionality won't work unless each matching property is empty in the original page. It would have saved Deane and myself the frustration of checking at the database level to try to figure out what was going on........

All properties are as NULL as I can make them, I'll say that.

WYSYWYG fields pre-populate with an empty P tag (see below). I removed it, but it gets re-added either by EPiServer or TinyMCE.

Every other property is empty, except for a default selection in a dropdown.

I iterated all the properties I added to the page:

• MainBody: <p><br mce_bogus="1" /></p>

• Tags: 
  

• Icon: 
  

• SideNavLabel: 
  

• ShowChildren: 
  

• ShowInFooter:

Like I said, they're as empty as I can make them.

Here's what's going on --

Based on your previous post, Linus, I created a new page type: "Null Page."  It has NO added properties at all.  THIS WORKS -- it fetches data just fine.

So I went back to my original page that wasn't working, and I wrote some code to turn the "MainBody" field into NULL.  This is the field that I can't stop TinyMCE from saving some content into.

THIS WORKS TOO.  Now that "MainBody" is genuinely null, the page fetches.  When I went back, edited the page, and hit "Save and Publish," it broke again, because TinyMCE dumped some content in there.

I am going to write a PagePublishing hook to detect this string from TinyMCE.  If that's the only thing in the MainBody, I'll set it to NULL.

A couple questions here --

• Has this always worked this way?  We have a bunch of pages which worked fine.  I went back and looked at them, and when they were saved (six weeks ago or whatever), TinyMCE didn't insert anything into them.  This means that the way TinyMCE works changed, and it must have been from the upgrade from RC1 to CTP.
• This strikes me as fundamentally odd, that a page fetch requires all properties on the calling page to be NULL.  This could result in some weird behavior for editors in a lot of cases.  Shouldn't a fetch be binary -- it just fetches or it doesn't?

I'm working on CMS 6.0.530.0 which (the final release version), and TinyMCE doesn't add any code into a blank input when saved, so this behaviour must have been changed / fixed between CTP and release. Is there any reason you haven't upgraded all the way to the release version Deane?

I completely agree with your second point - about the fetch. It should either happen or not.....

Hi!

I also tried to reproduce this on a local EPiServer CMS RTM release without success. You write that you have upgraded from RC1 to CTP. I guess that you really have upgraded to the RTM release, right Deane? Or are you still on a release candidate?

Regarding how properties work there is some information about it here (although it does not reflect the fact that properties that is considered to be null means that the property delegate handler skips the property):

http://sdk.episerver.com/library/cms6/Developers%20Guide/Core%20Features/Properties/Working%20with%20page%20properties.htm

It's possible to write your own get property delegate and replace the default property get handler if you want to change this behavior, though I have not heard of an actual case where someone has done this.

Regards
Linus Ekström

Guys -- sorry, I meant RTM.  I'm on 530.

I have a suspicion at the cause of this.  Am testing now.

One solution could to make your own property that inherit from the propertyxhmlstring and return IsNull true if the content is only the empty p

All:

Thanks for your input on this problem.  It has been fixed, so this is a post-mortem on it just so I don't leave it hanging --

The problem was pretty clear -- TinyMCE was inserting some junk HTML into my XHTML property and there was no way to stop it.  (See posts above for the exact HTML it was inserting.)

I couldn't replicate the problem either, on a brand-new CMS 6 install.  My production install was upgraded from RC1, so perhaps that had something to do with it.  On a new install, TinyMCE was clear.

One possible factor: I was experimenting with a TinyMCE plugin -- I had a class compiled in which added some configuration options to TinyMCE.  Perhaps this did something?  I removed this (I didn't need it), but I don't know for sure that this was the source of the problem.

What I did was write an event hook for PageSaving which detects this code and strips it out, so all pages are working again if we "Save and Publish."

And, for now, the weird TinyMCE behavior is gone.  New pages have an empty editor.

(A final, possible factor: I swear I had some weirdness in the control factory element of the web.config.  I remember going in there and finding something under the commented-out elements for the legacy editor.  I removed them, and perhaps this helped too.  I'd like to be more specific about this, but even going back through Subversion, I can't find these phantom elements that I swear were in there...)

Thanks, everyone, for your help.

Deane

I found it!!

After posting the above, I suddenly thought that perhaps I could Google what TinyMCE was inserting (again, see above).  So, I went looking for "mce_bogus."

Turns out that TinyMCE inserts this for a number of a reasons. For example, it makes it easier to click into a table cell if there's a BR in there to prevent cell from completely collapsing, so TinyMCE inserts placeholder tags into empty cells.

Anything with "mce_bogus=1" is supposed to be removed on serialization.  So...why wasn't it?

Turns out that this removal is dependent on TinyMCE's "cleanup" routine running.

I checked the TinyMCE plugin I had in the project at the time of the problem.  Sure enough:

 EditorInitConfigurationOptions = @"{
 custom_elements: '~test[if]',
 extended_valid_elements: 'test[if]',
 valid_child_elements: 'test[%itrans|%btrans|#text],p[%itrans|%btrans|#text]',
 cleanup_on_startup : false,
 cleanup: false
 }"

So, there you have it -- it was my fault.

The moral of this story: Don't disable cleanup in TinyMCE or page fetching will break.