This project is read-only.

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.

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:

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

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

Mar 18, 2012 at 6:43 AM

Please file a bug.