Fetching content from another page in EPiServer has stopped working

Vote:
 

The ability to fetch content from other pages in my CMS 6 installation has stopped working.

We have pages we created some time ago which fetch data from other pages.  These pages work fine.

But new pages we create, and attempt to fetch data from other pages -- these do not work.  They simply do not fetch the data.

I'm starting to think that, at some point in time, this broke.  Pages created before this point in time work correctly.  Pages created after this point in time do not.

For example --

I have a "source page" somewhere.

Months ago, we created a page ("Page A") which fetches content from Source Page.  This works fine, and has always worked.

However, today I created another page ("Page B") which fetches content from Source Page.  This does not work.  I just doesn't fetch the data.  Its properties do not populate with the content from Source Page.

I iterated all properties in Page B (the one that DOES NOT work).  These two properties --

PageShortcutType: 4
PageShortcutLink: 351

-- should indicate that Page B is linked to Source Page.

I did the same thing with Page A (the one that DOES work):

PageShortcutType: 4
PageShortcutLink: 351

They're identical in this respect.

I went into the database and looked in tblPageLanguage.  Both pages are the same:

FetchData: 1
fkPageLinkID: 351

Yet one fetches data, and the other one does not.

At this point, NO page we create will fetch data from another page.  But, again, pages we created in the past that worked are still working.

The only major change we've had is that we upgraded from CMS 6 RC 1 to CMS 6 CTP.  I cannot guarantee that this is when the change happened, but the timing could have been right.  The pages we created that worked were all created before the upgrade.

#39097
May 03, 2010 18:24
Vote:
 

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

#39100
May 04, 2010 8:56
Vote:
 

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........

#39104
May 04, 2010 14:02
Vote:
 

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.

#39108
Edited, May 04, 2010 15:47
Vote:
 

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?
#39112
May 04, 2010 16:54
Vote:
 

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.....

 

#39113
May 04, 2010 17:01
Vote:
 

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

#39114
May 04, 2010 17:26
Vote:
 

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

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

#39116
May 04, 2010 17:46
Vote:
 

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

#39117
May 04, 2010 17:51
Vote:
 

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

#39286
May 08, 2010 15:13
Vote:
 

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.

 

#39287
Edited, May 08, 2010 15:21
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.