Import Fields data issue in 1.4

Topics: Core, Troubleshooting
Mar 14, 2012 at 4:41 AM

Hi there,

I'm having an odd issue where the data from multiple fields is not importing properly in 1.4

In an upgraded instance of Orchard 1.4, I have created some new content types with 2 additional fields (one text, one html flavor). I've populated the data & exported it via import/export module & checked that all the data is there.

However, when I clean out the database & import that recipe, the data in just those fields is not imported properly (body etc are fine).

When I check in the database, I can see that the imported data from the fields has been put into the Orchard_Framework_ContentItemRecord table, but editing those content types in admin, there is nothing there in those fields.

If I add new data into those fields & republish & check the db again, I see that the just-added data is put into the Orchard_Framework_ContentItemVersionRecord table, but not into the Orchard_Framework_ContentItemRecord table. There are ContentItemRecord_Id's in the Orchard_Framework_ContentItemVersionRecord table matching all the data I first tried to import, but there is no real data, just a "<Data />"

Any ideas what is happening here?  Thanks in advance.

Mar 15, 2012 at 5:25 AM

Haven't got to the bottom of this yet, but I have managed to dig further and find what seems to be a hacky work-around.

When debugging I can see that it hits the Creating method in Orchard.ContentManagement.FieldStorage.InfosetStorage.InfosetHandler when importing a new content item. I don't quite understand what this code from the method is doing:

            var infosetPart = context.ContentItem.As<InfosetPart>();
            if (infosetPart != null) {
                context.ContentItemRecord.Data = infosetPart.Infoset.Data;
                context.ContentItemVersionRecord.Data = infosetPart.VersionInfoset.Data;

                infosetPart.Infoset = context.ContentItemRecord.Infoset;
                infosetPart.VersionInfoset = context.ContentItemVersionRecord.Infoset;
            }

 

But I can see that infoPart.Infoset.Data contains the full content item XML, whereas infosetPart.VersionInfoset.Data just has <Data />. I can't see where these are set in the entire codebase.

Changing the code to be:

                context.ContentItemRecord.Data = infosetPart.Infoset.Data;
                context.ContentItemVersionRecord.Data = infosetPart.Infoset.Data;

 

makes the problem go away and the content imports correctly. The fields are all there after import. Re-exporting then does not show up any differences from what I imported in the first place.

So I don't understand the entire problem or the solution for that matter. I'm not too sure what side-effects this might have. I definitely don't want to be hacking in the depths of Orchard if I can help it. So if anyone can shed more light on this, it would be greatly appreciated.

Orchard.ContentManagement.FieldStorage.InfosetStorage
Mar 17, 2012 at 5:30 AM

Exactly the same thing happening to me as well; 'yet another issue that is driving me completely nuts!'  First of all, I have several custom types that weren't importing correctly after export - simply put - import was supposedly successful, but like you've stated, it was blank -- this lead me to this thread:

http://orchard.codeplex.com/discussions/297291

So I added the 'identity part' to my type manually in my working orchard version, exported the type, then added identity manually in my testing version - imported, and all was well! So naturally I thought problem was solved -- nope!  After changing my migration file to include 'identity part' within my types in my working version, clearing the solution and adding a fresh DB, I tested the import/export of some data and got exactly the same result as what you've described!!!!! Surely we're not the only ones?

I'm now in the process of trying to re-create my only successful import to see whether I can shed any light on what's going on. Cheers pg

Mar 17, 2012 at 9:36 AM
Edited Mar 17, 2012 at 9:40 AM

It appears to me importing/exporting custom fields has never worked.  I'm using a fresh 1.4 source copy, I add a new content type with 'Identity, Body, Containable' parts [or whatever], and all behaves accordingly when importing/exporting...however, adding one custom field to the mix - and that field will be forever blank on import? Surely this is a bug, or perhaps this module was never intended to support custom fields?

You might be interested in the following - http://orchard.codeplex.com/discussions/285708  ends up accosting the same issue?

Mar 17, 2012 at 12:37 PM

@dyrgutt - being able to import/export custom fields is a fairly fundamental requirement of any 1/2 decent CMS, so I can't imagine this Module doesnt support such on purpose.  Maybe one of the developers could put us out of our misery with a heads-up? thanks pg

Mar 17, 2012 at 1:20 PM
Edited Mar 17, 2012 at 1:20 PM

I had this or a very similar issue a coupe of weeks ago but Sebastien has since fixed it. For me it was on MediaPickerField. http://orchard.codeplex.com/workitem/18488. Importing works now with my recipes.

Are you using the latest code in the 1.x branch? What changeset are you on for the orchar code and for the orchard.fields sub-repository?

Coordinator
Mar 17, 2012 at 10:05 PM

I'm not sure we're a half-decent CMS, but what field type are we talking about here? Many old fields don't implement import/export. Their fault.

Mar 17, 2012 at 10:53 PM

@bertandleroy - haha, give yourselves more credit [BTW, it was imagefield, textfield (default and html based)]...but new developments:

@TheMonarch, I had just recently installed tortoise and followed one of the guides fort this very reason, upon completion I assumed it would’ve been the latest […now I understand 6048 did not include the fixes you talked of]. So I just went guns a blazing and updated to 6100 [at the time the latest, but I understand not the most stable - just to test]. Sure enough, after copying my modules over and running, all my fields did indeed work correctly; thank you very much.

Now I know this isn't definite [as i've only done minimal tests], but so far so good! ;)

PS> I’m completely inexperienced with mercurial, but have noted when I’ve copied a cloned directory manually in explorer to another location, tortoise seems to continue bindings to the new location, is there any way to completely sever this connection [I assume if I delete the .hg folder it would, but didn’t want to risk it]; I mean, I would like to develop a separate branch copy without fear of me inadvertently updating/resetting it etc. to test further with a complete db refresh? Cheers again, pg

Mar 18, 2012 at 12:43 AM

Ok, after doing a more thorough test, the only issue I see now, is that upon export where the 'imagefield' is concerned, the file name automatically has "-1" attached to the string of all such types? Other than this, everything appears to function as it should e.g. xml should be:

<ImageField.IntroPic Width="565" Height="377" FileName="~/Media/Default/Content/Images/Projects/ss01_01.jpg"/>

but ends up being:

<ImageField.IntroPic Width="565" Height="377" FileName="~/Media/Default/Content/Images/Projects/ss01_01-1.jpg"/>
Any thoughts?

Mar 18, 2012 at 2:11 AM

Hmm, interesting default behaviour by the imagefields part, I never realized it added -1 by default to the filename upon upload; kind of annoying really?  Basically, I started afresh with an orchard project and copied my modules across, ran it, then imported the data [that originally wouldnt work] and noticed the image fields not displaying dute to my original image files existing in my theme not having the -1 that the imagefield adds; so, import/export module is behaving properly, it's the image field that needs looking into. Thanks guys

Mar 18, 2012 at 3:36 AM

I have seen this happen, but only when I try to upload or resize a photo that already exists, using the media picker. If there is a physical image in the Media folder with the "-1" then I don't see the problem here. I don't see why the export process would alter the file name. If it helps, I haven't had this issue and i upload, and import/export content with MediaPickerFields on a regular basis. 

Mar 18, 2012 at 5:51 AM
pubgrub wrote:

so, import/export module is behaving properly, it's the image field that needs looking into. Thanks guys

@TheMonarch: Yeah mate, I realized there was nothing wrong with the export side of things, but with the Image field itself.  Simply put, if I upload an image into a fresh directory without any other images, it attaches the "-1" by default - very strange? Cheers pg

Coordinator
Mar 18, 2012 at 6:43 AM

Please file a bug.