All project content is available for reading, but you need to be a member of the project for Subversion checkout of source code, or to create/modify any information.
Login if you are a member. Apply here to request membership (open to all).

Ticket #114 (new defect)

Opened 9 years ago

Last modified 9 years ago

Files linked in multipageproperty ignored in mirroring

Reported by: erik.nordin@… Owned by: steve@…
Priority: major Component: MultiPageProperty
Keywords: mirroring, multipageproperty Cc:


Mirroring from CMS 5 SP2 -> CMS R2 and no files linked in the multipageproperty is mirrored. Files from standard EPi-properties are mirrored. EPi-bug or something with this property?

Change History

comment:1 follow-up: ↓ 3 Changed 9 years ago by steve@…

I think it is something with this module. The property is inheriting from LongString, not XhtmlLongString which (I think) is a requirement for the files or links to be recognized and rewritten in CMS 5. (See the source.)

You could try to inherit from XhtmlLongString instead and see if that helps.

comment:2 Changed 9 years ago by erik.nordin@…

Thanks for the answer Steve! I'll look into it and hopefully come back with a good respone. :)

comment:3 in reply to: ↑ 1 Changed 9 years ago by erik.nordin@…

Hmm.. i changed to inherit from the xhtmlstring.

Before the change the link on the mirrored site still was '/Global/folder/file.pdf', but the file was not mirrored.

After the change the link is '/link/e107a030998148e38738d88efcf6ca6a.pdf' and it's still not being mirrored.

Any more ideas?

comment:4 Changed 9 years ago by johan.stahl@…

  • Keywords mirroring, multipageproperty added
  • Priority changed from major to critical

I have a similar problem with MultiPageProperty and mirroring. We use the MultiPageProperty in our site for PageLists. We have two environments, one site where the editors work (site A) and one site for the visitors (site B). If an editor creates a new page on site A the page will get a new pageID and a GUID, the new page will be mirrored to site B with a different pageID but with the same GUID as the page on site A. The editor change the MultiPageProperty to point to the recently created page. The Page with the MultiPageProperty will be mirrored to site B, but its PageReference to the new page will point to another page or it won't find the page because the pageIds differ on the different sites.

So the problem is that the mirroring holds the wrong pageID or it's problem with the mirroring function. Is this something you recognize and have a solution to?

comment:5 Changed 9 years ago by svante@…

The problem is multi-fold. First of all, you need to implement EPiServer.Core.Transfer.IReferenceMap - which PropertyXhtmlString for example does.

So the idea of inheriting from PropertyXhtmlString is a good one. However... The format is not HTML, and although it *might* work with a top node named <links>, the code should not parse it, since it expects HTML. Either change the format of the MultiPageProperty to actually be well-formed XHTML (nothing wrong with that, is there?), or make a custom implementation of IReferenceMap.

Also, it won't be fixed for existing data by the re-implemenation. IIRC the string is parsed on *setting*, storing it in a special format, and then reparsed and reformatted by ToString() (or whatever - writing this from memory).

My suggestion is to change it to inherit from PropertyXhtmlString, and change the format to be be proper XHTML. I don't really know how to handle the upgrade of current data... Probably it'll require some permanent run-time code in the getter, or ToString() or whatever checking if it appears to be old format, and then do a custom parse and reformat to the new format and re-save it. Maybe someone will think of a smarter way, but it really should be done automatically with no user interaction.

A possible other approach is to keep the current format and thus re-implement the required interface, perhaps by wrapping calls to the base class implementation after some tweaking (i.e. String.Replace("<link>", "<html>") etc etc. ugly, but perhaps workable.

comment:6 Changed 9 years ago by steve@…

  • Priority changed from critical to major

Thanks for the excellent input Svante!

I'm reluctant to changing the format as there are so many sites that rely on this property. There is really nothing wrong with being XHTML compliant, I guess this is just one of those things that was never considered during implementation.

I was thinking about just changing type (inheriting from XHtmlLongString) and then during load detect the content (old <links> vs something XHTML compliant). However - as you say - it won't help on existing content.

Going through all properties on all pages looking for this is an option, but it won't help for all of those that use the web part framework, as the properties are not stored as regular properties in EPiServer.

If we do end up with going through all props, we could just as well convert them to the new EPiServer Link Collection property (though it currently does not support all the features the multipage prop does.)

What a mess.

If someone feels up to the task of rewriting this, feel free. I do not have the time to tackle this at the moment.

Note: See HelpUser/Tickets for help on using tickets.