+1 On Jul 22, 2014, at 3:47 PM, Glen Mazza <[email protected]> wrote:
> Team, our "Export Weblog" screen, usually kept disabled (hidden) because of > the weblog.export.enabled=false setting in roller.properties, is in pretty > poor shape, I don't think anyone has looked at it in quite a few years. The > Blog base URL entry field is ignored, while the "Export Resources" button (to > get a ZIP of all images) just creates a corrupted file. The Movable Type > format that it exports may also need updating. > > The HTML export utility that Dave created a while back > (https://cwiki.apache.org/confluence/display/ROLLER/How+to+back+up+a+Roller+blog) > has worked fine for me for several years, and WordPress can happily handle > HTML imports (https://wordpress.org/plugins/import-html-pages/). Blog > clients can probably also take from Roller and publish to other blogging > software. That might be good enough for us today, I'm wondering if we can > avoid a need to maintain a separate weblog export page. The only thing I > find still useful about this page is the Export Resources button, but that > can be put on the Media File Views page once somebody gets it working again, > a separate export screen shouldn't be needed for that. > > In general, our focus should remain on improving Roller for those wishing to > remain with us rather than spending considerable time trying to streamline > exports to our competitors. Usually blogging software puts effort into > making it easy to *import*, not so much *export*--facilitating the > transferring process from one blogging product to another is usually the > effort/responsibility of the blogging product "winning" the blogger. > WordPress, for example, goes to great length to show the many ways you can > import into their tool (http://codex.wordpress.org/Importing_Content) but > offers just a generic XML export of WordPress content > (http://en.support.wordpress.com/export/), much like what we have now with > Dave's HTML utility. > > WDYT? > > Regards, > Glen >
