Simple Payments: pre-populate attributes when converting from classic block

[retrofox]

Changes proposed in this Pull Request:

It populates rightly the product properties gotten from the data/response when it comes from a shortcode transformation.

Fixes Automattic/wp-calypso#29870

Testing instructions:

1. Get a post with a "Simple Payment Button". If it doesn't exist just create it:
   a. Get the product ID (inspect the dom tree trying to find the ID, or inspect the XHR request from the network tab)
   b. Once you get the product ID, create a new Classic block with the Simple Payments shortcode:

[simple-payment id="<product-id"]

2. Convert to Blocks
   

3. Once it's converted it should populate the fields with the right data.
   

Proposed changelog entry for your changes:

Simple Payments Button: Convert classic Blocks (shortcode) rightly.

[jetpackbot]

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

Scheduled Jetpack release: April 29, 2019.
Scheduled code freeze: April 22, 2019

Generated by 🚫 dangerJS against 341f90c

[mmtr]

Nice fix! It worked as expected when I converted to blocks a existing post created in the classic editor that was containing a payment button.

[simison]

@kraftbj FYI I've added this to 7.2 milestone as it's a bugfix, in case it makes it in before we ship blocks. Lemme know if you'd prefer to punt it for 7.3

[kraftbj]

Since it isn't a regression caused by 7.2, I would prefer to punt to 7.3 if it isn't critical. We've been burnt before by sliding in fixes late that caused new issues (I've done plenty of that burning).

One advantage of waiting too is don't need to worry about cherry-picking cross-repo :)

[simison]

Sure, works for me!

…

On Fri, 29 Mar 2019, 00:38 Brandon Kraft, ***@***.***> wrote: Since it isn't a regression caused by 7.2, I would prefer to punt to 7.3 if it isn't critical. We've been burnt before by sliding in fixes late that caused new issues (I've done plenty of that burning). One advantage of waiting too is don't need to worry about cherry-picking cross-repo :) — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#11731 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFUgPNioteOnJdOF-XhuFMUSpQJD6OIks5vbURZgaJpZM4cOvIG> .

[rodrigoi]

🚀 🌕 !

[roccotripaldi]

I think punting to 7.3 should be fine, but I'd like to get this on master ASAP so that we can fix the problem for wpcom sites.

[jeherve]

This works well in my tests. 👍

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello retrofox! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer, review, and approve D26365-code before merging this PR. Thank you!

[obenland]

@roccotripaldi Damian is on leave, would you be available to bring this over the finish line?
/cc @vindl

[roccotripaldi]

would you be available to bring this over the finish line?

@obenland
Yeah, no problem. I'll see that it's merged here, and on wpcom!

[kraftbj]

Works as advertised.