For years, my biggest gripe with Drupal has been how hard it is to get data in and out. When I started (mid D6) the best solution was the Node Import module. It worked ok, but the interface struck me as large, involved, and focused on covering edge cases. Two years later, when I moved to D7, the maintainers of Node Import didn't create a D7 version, and instead guided us users to Feeds. Feeds is more flexible than Node Import, but even less friendly -- you can't even read the headers from a CSV file directly, you have to type in the header names. Case matters! Only a mother could love that interface.

D8, of course, is making it even harder. Migrate. You have to write an object-oriented module. Easy to do, for Donald Knuth.

Meanwhile, install Wordpress and you get this in your main menu:

screen shot 2014-12-20 at 9 37 56 am

Can't we do something to help non-gurus get their data into (and out of) Backdrop? It's incredibly important. More than the code, more than the design, more than anything, the data is what people care about. Every single Drupal project I've been involved with -- without exception! -- has struggled with this. We should do better.

I took at look at what would be involved in porting Feeds to Backdrop myself, but it seems daunting. It's big, and depends on Ctools, which is also big, and probably already at least partially included in Backdrop. Eventually I could give it another shot, but rather than struggle and curse alone, I wanted to see what other people thought. Especially since I'm concerned that low-level architecture decisions being made now (or possibly already made) might easily make this easier or harder.

My strawman blue-sky suggestion: A facility that would spit out all of the nodes in a Backdrop system (and obviously other entity types, but nodes would be a good start) as, probably, JSON files. Probably as big aggregate files, though I'd be interested in one file per node, which a beginner could construct by hand. The important thing is it should be able to import whatever it exports. If you have that, then an end user can re-create those export files in whatever way is comfortable to them.

I realize there are lots of edge-cases; custom or contrib modules that store data in all sorts of wacky places. But following our 80/20 rule, if we support data import and export for sites built with non-extended Backdrop, we can worry about other cases later -- but we would already start out miles ahead of any version of Drupal in a feature that is extremely important to our core audience.

Thoughts?

[2020 edit - adding some more screenshots from recent WP v5.4]

Screen Shot 2020-07-16 at 4 17 46 am Screen Shot 2020-07-16 at 4 18 21 am Screen Shot 2020-07-16 at 4 20 35 am Screen Shot 2020-07-16 at 4 21 42 am

GitHub Issue #: 
487

Comments

Agree passionately. The ability to both import and export would be a bright feather in the Backdrop cap. Ideally, the import should provide a UI that facilitates field-mapping in the way that (I think) Access used to do (or still does).

I also agree that a system that initially works with non-extended Backdrop would be the way to go.