Exporter: WP.com API integration

[jordwest]

This PR is being split into smaller PRs:

• Export: Fetch available settings for customizing export content #2652 - Fetch available advanced settings
• Export: Automatically fetch advanced settings when switching to exporter #3158 - Automatically fetch available advanced settings when switching site
• Populate advanced settings
• Export: Add Redux actions and API calls for starting an export #2911 - Export All
• Export: Check status of export while in progress #3241 - Retrieve status of export while export is in progress
• Export Selected Content

---

Awaiting #500 => #1126

This change completes the exporter, adding the API calls to communicate with wp.com

How to test

Export All

1. Go to http://calypso.localhost:3000/settings/export and select a site.
2. Click the Export All button.
3. A notice should appear with a link to download the export file. You should also receive an email with a link.

Export Specific Content

1. Go to http://calypso.localhost:3000/settings/export and select a site.
2. Click the gear icon.
3. Select Posts, Pages, or Feedback and change some of the settings under that section.
4. Click the Export Selected Content button.
5. A notice should appear with a link to download the export file. You should also receive an email with a link.

Jetpack sites
Jetpack sites still display the export interface, but should instead show a message with a button link to wp-admin. Since export is still behind a feature flag, this will be covered in #77 under a separate PR.

Mobile
If you are set up with a local dev proxy, please try it out on mobile. It would be good to get an idea of the flow on Android. I've tested on iOS 9:

Todo

• Rebase (various changes to Redux and prior PRs)
• Use the site ID from the Redux store instead of passing the site prop to the Exporter component
• Now that we only allow a single post type to be selected (Post, Page, or Feedback), the API calls need to be constructed from the state differently (modify prepareExportRequest( ... ) in state/site-settings/exporter/selectors.js)
• Be more specific with the start and end dates passed to the API. Instead of sending '2011-05' for the end date, send '2011-05-31'
• Display loading placeholders instead of the dropdowns while the available advanced settings are being fetched:
  

[dllh]

These should be translated.

[jordwest]

Oops, I missed that in a past refactor. Fixed

[jordwest]

Thanks for the review @dllh - I've fixed up those issues and rebased to fix the merge conflict

[dllh]

It's possible to navigate to /settings/export/:site and see the export form for Jetpack sites, when really we should probably do something more like what's done for import. Might want to just open an issue for that to handle once this lands to prevent bloating this PR.

Update: To clarify re Jetpack, it's possible to manually specify a url and get a form that doesn't work. For import, if you do that, you get a slightly different view that directs you over to wp-admin for the site to do the export.

[dmsnell]

if you return these calls, then your code can take advantage of that by inspecting the request object.

additionally, if you return them and don't use a callback, the wpcom.js library will return a Promise that resolves on the successful response from the API and rejects on error

Undocumented.prototype.getExportSettings = function( siteId ) {
    return this.wpcom.req.get( {
        apiVersion: '1.1',
        path: `/sites/${ siteId }/exports/settings`
    } );
}

//~~~ another file ~~~~
wpcom.getExportSettings( siteId )
    .then( receiveExportSettings )
    .catch( apiFailure );

[dmsnell]

@jordwest this is a pretty big PR. Since this isn't public yet, I suppose it's not too bad, but it would be really cool if it were split up into smaller functional blocks for testing purposes.

In general, there's a lot of use of passing the entire global state around. I'm not sure this is really needed or beneficial. That exposes many of the smaller functions to a wider range of possible issues. If instead of sending the state object around, we only passed the data that they need, it would be more clear what they are doing. When thinking about testing too, it involves less setup for the test since we can mock up some related object without having to know the entire state structure to make sure we build the appropriate container for that mock object.

I left many comments and would be happy to review this again after you respond!

[jordwest]

Thanks for the in-depth (as always!) review @dmsnell. I've made some changes based on your feedback, but I'm now working on splitting this up into smaller PRs so the modifications will all be incorporated in those