I'm a CafePress shop owner (shameless plug: http://www.cafepress.com/halley_designs), and I have a backlog of new graphics I want to upload to CafePress. Great, WWW::Mechanize should just do the trick, right? Well, there are some issues.
First, the cafepress "shop owners" interface is covered with javascript special handling and multi-stage input. The forms include a few hidden fields that the javascript will compute during the browser session. I can get the image uploaded, but the followup form is to provide a name, keyword tags, and a category choice. After submitting this second screen, everything says it's successful, but the name and tags and category data are not actually committed to their database.
This has been a good chance to try out WWW::Mechanize::Shell, and now I'm going to try HTTP::Recorder (which seems to have a heck of a lot of dependencies I wasn't expecting). Is there a simpler HTTP snooping proxy I should check out, just to see what is in the HTTP requests from my usual browser?
If nobody else already has any code along this path (and I've done all the Googling I can think of), then I'll continue to take this reverse-engineering approach myself. (Even if it takes more effort than just manually updating the images one at a time!)
As of this writing, the CafePress folks are still trying to build a general HTTP "API" for authenticated direct access to these sorts of data elements, but they admit they're really just a team-of-one, and the system is intended for web-to-web customization (where users of *my* website can submit custom designs to *cafepress* on the fly, and then facilitate an order of that custom product indirectly), not the plain home-to-web bulk uploads. I'll be happy to target that API when it's available but in the meantime, anyone else try this approach?
--
[ e d @ h a l l e y . c c ]
In reply to CafePress batch image uploading? by halley
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |