This project is read-only.

Import/Export Issues: Where (and should) they be Reported?

Topics: Administration, Core
Jun 13, 2013 at 8:23 AM
Edited Jun 13, 2013 at 8:23 AM

There's YAIEI (Yet Another Import/Export Issue), this time with the Vandelay meta data. To reproduce:
  1. Add the Meta-Data part to a Content-Type
  2. Fill in Meta Data; save
  3. Export
  4. Import
  5. Meta-data gone
I haven't yet looked into the code, but it seems that import/export is left to the individual modules, and it makes the whole experience very inconsistent and unpredictable. Perhaps what is needed is a framework for modules to use to implement import/export.

At this point I feel like I'm beating a dead horse. Should this be reported as an issue? If so, to whom?
Jun 13, 2013 at 9:51 AM
Edited Jun 13, 2013 at 9:55 AM
Hi nunez

Yes the import/export is left to individual modules, but is not enforced (perhaps it should be). You'll find examples in many of the ContentPartDrivers for modules throughout the solution. The issue you're running into has already been reported here and the code provided.

Perserve with your learning curve, Orchard is very rewarding once you get over the initial hump.

Edit: Forgot to say, if you are on the 1.x branch there is atleast one fairly nasty import/export bug that I know of that could be mucking you around, I would go back to 1.6 if you're pushed for time, although the one I'm thinking of has been marked to be fixed in 1.7 which should be very soon.
Jun 20, 2013 at 11:17 AM

OK, so let me get this straight so I understand.

What we know:
  • Import & export is left up to the individual modules to implement
  • Building a recipe using import / export seems to be the recommended way for multiple developers, designers and content authors to work together by being able to regenerate the complete site and contents at any time.
  • Import & export is unreliable because of the inconsistent implementation among modules
  • Errors that are reported to module authors may not get fixed in a timely manner (such as the meta-data one, where one poster provided a patch about a year ago
  • Errors that are fixed in a module aren't automatically updated by Orchard, nor provide notification (I'm thinking WordPress here)
So, it seems we have two choices:
  1. Fork the code for each module we need to use and maintain it independently, while keeping an eye on each module in case the author decides to fix a reported bug
  2. Forgo using any third-party module and build everything ourselves with proper import / export support
Have I missed something or is there an easier way to make all this work? The main problem in adopting Orchard here as I see it is that the infrastructure for a team workflow isn't there, along with module behavior being a bit inconsistent and requiring a lot of manual intervention and oversight. It's not just about making beautiful and functional websites, Orchard already does that, it seems to be the more mundane human and organisational factors that make adoption difficult (more correctly, the lack of technology support for them)

Any good solutions other than the ones above?
Jun 20, 2013 at 1:46 PM
Edited Jun 20, 2013 at 1:47 PM
I would say I was sharing the same opinion but I realized that:
  • important modules get patched in acceptable timeframe for non business intensive requests (dont expect H+4 :) ) AS FAR AS you provided a clear repro process and eventually the patch. Important means the most demanded.
  • the others modules, you had rather clone or replace by your own...and beware
  • there is also a solid support, here, on stackoverflow and through many blogs, from other Orchard users and comittee team(sometimes some of them like answering with questions :), certainly because it's crazy to support this board repeating always same answers...)
  • if you are in a hurry, don't try unexpected non common things with Orchard, it certainly could do them, but if you are a beginner, you will spent a lot of time making you mind between options
  • 1.7 version will have many improvements to make it more stable (may be 1.7.1)
    Work in progress
Jun 25, 2013 at 4:16 AM
Right, OK.

Does anyone have an idea when the Vandelay industries module will be fixed, if ever? The patch was submitted a year ago now, and given the fact that it provides some very useful functionality and is written by one of the contributors, I'd have thought the patch would have been incorporated by now.

Any other options for meta-data that are supported and aren't broken when it comes to input/output?
Jun 26, 2013 at 3:27 AM
I'm working on a number of fixes to Vandelay. No ETA, but I'm on it. Please make sure to file a bug on the module's CodePlex site if there isn't one already for your issue.