-
Notifications
You must be signed in to change notification settings - Fork 41
WordPress Import #147
Comments
Exporting user information is the part I'm stuck on. There are several approaches we could take:
The third option is the easiest for me, but creates a bad transition experience for a multi-user system. |
@paragonie-scott I was thinking about that while writing the description - my opinion would be to go with option 3 (it's the most secure, as it doesn't require handling a weak hash), and if there's pushback (or a large org willing to sponsor), then go with 2. |
The folks I've asked on IRC said that 2 would be most useful for them. This means: I need to build a WordPress Import gadget that shims in the hashing (and, likely, add a UI wizard to the Bridge to ask for MySQL information to facilitate the import). |
I would suggest not relying on having access to the original WP DB; as the airship instance may not be on the same server / infrastructure. For me, due to the different requirements of Airship versus WP, Airship runs in a separate VM (in a different datacenter), so if it relies on DB access, it would require firewall games to allow access. If a user is coming from a shared host, they may not be able to expose MySQL at all. My opinion is that it should export to a file, and then upload the file to Airship to be processed. I know it's a bit more complex than pulling it in directly, but it should greatly reduce the pain for users in the future. |
That's a very good point. I'll look into their custom format ASAP. :) |
See #147. This allows password hashes to be imported by some process (currently not yet implemented). Users can log in with their old WordPress password.
The framework now exists for importing password hashes from other projects. We ship with a WordPress password hash migration utility. Others can be added in the future. |
I know this has been discussed, but to get it documented...
There should be an Import tool that can be used to import content from an existing WordPress blog, to simplify the transition. Given the size of the WordPress user-base, it makes sense to be the first target for importing content.
I see two routes to go here:
WordPress Export
WordPress have a native export tool which uses a custom file format to export most of the key content, though doesn't include media, or any configuration. This still leaves a fair bit of work to be done, but it is probably the simplest option.
Custom WordPress Export Plugin
Another option would be to build a plugin for WordPress that exports as much as possible - comments, media, configuration information, user information, etc. This option would be more complicated as it requires not only building the import into Airship, but building the plugin for WordPress that would export all of this data.
Going with the custom export plugin would make for the easiest transition, as it would require the least effort for transitioning users, and would bring over all of the content that Airship can support. Though at a cost of several times the amount of work required.
Either option would be a substantial improvement over the current very manual process.
The text was updated successfully, but these errors were encountered: