Daryl L. L. Houston (dllh)

Yep, that should work.

You can download the plugin I had created for Paul here. Just put it in your plugins directory, do the import, and then you can deactivate or delete the plugin, as it’s used only during the import itself to rewrite post content.

This isn’t in the plugin repo because it’s pretty specific to this use case, by the way. Happy to make it available, though — it just didn’t seem a candidate for the official repo.

As always, make sure you try this with a test import before wrecking production data. ??

Thanks for that, Paul. The Jetpack plugin definitely shouldn’t slow your site down that much (if at all)! If you’re still having load issues, look up WP Super Cache in the plugin directory. It’ll cache your site for users who aren’t logged in, making it run much faster. (There are other caching plugins as well, but Super Cache is fairly simple by comparison and is authored by another Automattic employee, so I have a degree of trust in it.)

Oh, one more thing: It’s always good to test beta things on beta blogs if possible.

Deborah, the version I had Paul testing can be downloaded from a development branch here. It uses a newer version of the Posterous service that’s better than the older version. It also does a better job of handling some error conditions than the released plugin.

I had also worked with Paul to do some stuff with e.g. video, which the Posterous importer can’t natively handle (because it can’t make assumptions about what video plugins people may have, etc.). If you have mostly (or only) images, the beta importer will hopefully be a step up.

We deferred releasing it because we wanted to test it out on WordPress.com for a while first. Some more instances of testing on .org sites will boost confidence as well.

As for other export/import issues from WordPress.com, it’ll be best to open support tickets at https://support.wordpress.com/. There’s a pretty good chance those’ll filter down to me, but it’s best to go through proper channels in case I get hit by a bus, so that somebody else can pick up the work. ??

Did you also empty the trash? If they’re still in the trash, they won’t reimport.

Try deleting the blogger-importer directory from under your plugins folder using your file manager or FTP program. Don’t remove the whole plugins folder, just the blogger-importer folder. That should restore access to your blog.

I’d guess maybe you need to add the enctype="multipart/form-data" to your form attributes.

Can you be a little more specific?

That’s not really what the plugin is designed for. It’s designed to transplant content from Tumblr to WordPress so that you can begin blogging with WordPress. It’s possible there’s an RSS plugin you could use to consume your Tumblr RSS feed and do an ongoing sync (though I don’t know of one myself).

We’re using v1 of the API because that’s what was used in the original plugin and we wanted to iterate quickly on that to land some fixes rather than reimplementing using the v2 API. Patches welcome. ??

It’s possible that you could resolve this by increasing the value in the usleep command to something > 1 second. Right now, it’s one and one one-millionth of a second, and maybe that’s not quite long enough to keep the Posterous api from throttling. I’d be curious to learn whether bumping the initial digit on that value to 2 fixes the issue for you. If your workaround does the trick, that’s fine too.

Sure, if you’re willing to do that, I’ll give it a try. You can email me account details at daryl at automattic.com.

justinkelly, maybe the sleep command isn’t long enough. If you’re feeling brave, edit the plugin in a text editor. Look for references to “usleep” and change the number inside parentheses so that the first digit is a 2 or even a 3 (don’t go much higher than that). Usually Posterous wants you to wait a second between requests, but I suppose it’s possible that in some cases it wants you to wait longer or that the timing currently built into the plugin is too close to 1 second to satisfy Posterous’s limit.

Thanks for confirming the curl setup. The only thing I can figure out right now, based on this article, is that in some cases, the signature appended to requests for assets that redirect to amazon includes encoded strings (like %2F, which is a slash, and %3D, which is an equal sign) that are fouling with the download because the modified value doesn’t match what amazon’s expecting when it validates the signature. I’m trying to sort out a good way to handle this case but am so far having trouble debugging (it’s made harder by the fact that it’s inconsistent — ie, if I include one of your problem files in a Posterous post of my own, it imports ok because I’ve so far gotten lucky with the signatures).