New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WordPress Importer #49
Comments
@obazoud does arranging a skype call sometime so we can brainstorm an architecture to support multiple importers sound good to you? Hopefully I can make them some sort of plugin, so people can easily write their own importers and we could provide a generic ImporterPlugin class for them to extend that will contain a bunch of common functionality. Thoughts? For a Skype call, I'm good anytime Monday and Tuesday between 9am-9pm Sydney Time (GMT +10:00) @eldios, feel free to jump in on the call too if you'd like. |
Hi, |
Sure, let's jump on irc now. #docpad on freenode, or this time Tuesday? |
looks good to me. |
Cool. So sounds like this will be done pretty soon. A few ideas. What if we were to create a standard architecture for importers, which is then extended by the specific importers. This will be similar to the way plugins work. One benefit of this is that we could introduce a web interface for importing which has descriptive and helpful information for the user about importing their website. Such a setup procedure could go like this:
Created an issue for the web interface discussion here: #62 Created an issue for the standard importer architecture here: #63 |
I'll observe that any import facility is better than none. Also, integration of import into a larger setup process is a major pain when the inevitable bugs or issues are found while importing. For example, I've found that sometimes it's just easiest to do a one-off enhancement of an importer to refactor a site when doing a migration. Small, independent importer scripts make it really obvious where a fix goes when things break, and are generally easy to hack to smooth out those odd edge cases. FWIW, I have an existing site (in Tumblr, as it happens) that I'd consider migrating to docpad, but key features over and above importers are missing. The prime example in my mind is @obazoud's alias plugin in #78. With that in place, I could fire up Jekyll's Tumblr importer and be running in fairly short order. Not perfect, but it's a start. |
@ashnur is working on this at https://github.com/ashnur/docpad-plugin-wphook We should set the requirements to be:
|
What I am doing is not really an importer, rather than a bridge between WP Admin and a docpad installation. So pages and posts are realatively easy, but uploads I just don't even tried. For images I just look in the html source, and scrape/save them, replacing the src in the post's content. As for comments, I don't have any idea, I am planning to use either facebook or disqus on the site I need this WP thingie for. |
To solve the comments stuff, i think that the first step of migration is change the way of how comments works. |
@jaydson yeah, while they can't have comments on static servers, if they host their docpad instance on dynamic servers (node.js servers) then we can handle comments ourselves. I've done up the nativecomments plugin to showcase this. |
I just found this project: https://github.com/thomasf/exitwp |
As per https://discuss.bevry.me/t/deprecating-in-memory-docpad-importers-exporters/591?u=balupton this is outside the scope of DocPad. |
On the page https://discuss.bevry.me/t/deprecating-in-memory-docpad-importers-exporters/591?u=balupton |
Yeah, it works now, thanks. Also, the change and the reasoning seems quite sound. |
As a User, I want the ability to import my wordpress data, so that migration will be a lot easier
See obazoud@e21b10f for reference.
Pull request here: #78
Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: