Skip to content
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

Contact Info & Map widget: Add legacy widget → block transform #21232

Conversation

ivan-ottinger
Copy link
Contributor

@ivan-ottinger ivan-ottinger commented Sep 29, 2021

Changes proposed in this Pull Request:

This PR adds transform for the legacy / classic "Contact Info & Map" widget:

Screen.Capture.on.2021-10-15.at.11-45-05.mp4

The proposed change can help users move the content from their existing widget into the "Contact Info" block, plus several additional blocks:

  • Heading (H2) block storing the Title of the widget
  • Paragraph block storing the Hours field of the widget
  • Map block that extracts the address from the widget Address field, utilizes the changes proposed in Map block: Add address block attribute #21412 and displays the map with the pin pointing to the location

(Please note that the Show map checkbox in the widget settings needs to be selected in order for the Map block to be created)

The Address field of the widget is transformed into the Street Address block field, leaving other block fields (e.g. Country, Postal/Zip Code, State) empty.

Jetpack product discussion

Does this pull request change what data or activity we track or use?

No.

Testing instructions:

  1. Add the "Contact Info & Map" widget (using the Legacy Block) to your testing site.
  2. Select the transform option and choose "Contact Info" block (as can be seen in the screenshot above).
  3. The widget information should be correctly transformed.
  4. If the Show map checkbox is selected and the address is provided, Map block pointing to the correct location should be added during the transform.

@matticbot
Copy link
Contributor

Caution: This PR has changes that must be merged to WordPress.com
Hello ivan-ottinger! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D67571-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

@github-actions github-actions bot added [Block] Contact Info [Plugin] Jetpack Issues about the Jetpack plugin. https://wordpress.org/plugins/jetpack/ [Feature] Extra Sidebar Widgets labels Sep 29, 2021
@github-actions
Copy link
Contributor

github-actions bot commented Sep 29, 2021

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

  • ✅ Include a description of your PR changes.
  • ✅ All commits were linted before commit.
  • ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  • ✅ Add testing instructions.
  • ✅ Specify whether this PR includes any changes to data or privacy.
  • ✅ Add changelog entries to affected projects

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖


The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.


Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.


Jetpack plugin:

  • Next scheduled release: November 2, 2021.
  • Scheduled code freeze: October 25, 2021.

@github-actions github-actions bot added the [Status] Needs Author Reply We would need you to make some changes or provide some more details about your PR. Thank you! label Sep 29, 2021
@ivan-ottinger ivan-ottinger marked this pull request as ready for review September 29, 2021 14:07
@ivan-ottinger
Copy link
Contributor Author

ivan-ottinger commented Sep 30, 2021

There's an issue which is blocking the build process of the WPCOM patch: p1632857344442400-slack-CBG1CP4EN - so we cannot test the patch on WPCOM yet.

→ This has been fixed already. We can now test the patch on WPCOM as well.

Copy link
Contributor

@arcangelini arcangelini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything worked for me, just need to add the hook to hide the widget and possibly the conditionals for the other fields?

@@ -31,6 +31,7 @@ public function __construct() {
'classname' => 'widget_contact_info',
'description' => __( 'Display a map with your location, hours, and contact information.', 'jetpack' ),
'customize_selective_refresh' => true,
'show_instance_in_rest' => true,
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if you left it out on purpose, but the hook to remove it from the Legacy block needs to be added as well. Made testing easier though : )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! :)

Yes, I left it out on purpose - as I wanted to hear your opinions on also leaving the Contact Info & Map widget there for the users to choose (in case they prefer it over Contact Info block).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding was that we were getting rid of the redundancies in the widget area. I think it is a little confusing to users to have two or three options for the same things. This seemed like a 1:1 transform, does it differ greatly between the widget and block option?

I am not completely sure though, it could be best to get @simison and @yansern opinion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is a little confusing to users to have two or three options for the same things.

I see what you mean by looking at this from the perspective of user's confusion.

This seemed like a 1:1 transform, does it differ greatly between the widget and block option?

The main difference I can see is the map solution being used: Google Maps (Contact Info & Map widget) vs MapBox (when the user transforms the widget into blocks).

I personally prefer MapBox, but I can see some users that would like to use Google Maps instead.

If we want to remove the redundancy, then yes, I think it would be best to remove the legacy widget.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that the only way to use Google Maps is through shortcodes.
[googlemaps https://maps/url/here]

  1. Are we able to construct a Google Maps embed URL with long & lat param?
  2. Is it alright if it's a shortcode block?

Reference: https://wordpress.com/support/google-maps/#embedding-a-google-map

How about creating a block for this?

Also, another aspect we can consider, is to create a Contact Info & Maps block as part of our Gutenberg training. Since the widget code lives in Jetpack, why not create the same block in Jetpack?

Then, we can come back to this transformation exercise and have it do a 1:1 transformation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, as a first iteration we could have a block that has the same functionality as the current legacy widget. Then we could build on top of that and add extra features, e.g. Mapbox support.

I agree with starting simple. Showing the same form as what the legacy widget did, and use Google Maps, would be the path to least resistance. I imagine literally extract bits & pieces and put them back using Block's library.

Copy link
Contributor

@yansern yansern Oct 4, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that there's a Contact Info block on Jetpack. It also creates a Google Maps.
Perhaps the work needed is to modify this block and give user the option to embed the Google Maps under.
https://github.com/Automattic/jetpack/tree/master/projects/plugins/jetpack/extensions/blocks/contact-info

2021-10-04_14-47-07

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does that sound? 🙂

Yeah, we could give that a try. I would, however, suggest that you post on a P2 about this as there are some product discussions to be had about this. See p7fD6U-2XB-p2 for some background.

It also creates a Google Maps

It's just a link though, so nothing super fancy. But I agree we should start there with that block, maybe by leveraging the existing map block as a new possible inner block for that block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have just published a P2 post to gather more insights - so we can then decide on the best approach moving forward: p7fD6U-4KX-p2.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussion continues in p7fD6U-4KX-p2

} ),
];

if ( instance.raw.hours ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might need to make all of the innerBlocks conditional. Otherwise, you end up with blanks blocks if it is empty. This is what it transformed to for me with certain fields blank - https://d.pr/i/8UNAOy

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was initially thinking about making all fields conditional, but then decided to leave some of them unconditional. The reasoning here is that if the user is transforming to the Contact Info block, they will see what fields they can fill in (even if they didn't have them filled in the widget previously).

Also, for example, if the widget title is empty, they will see a nice empty header they can fill in. At least this is how I would like it to be (if I were a user). But I get your point!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I totally see your point. Generally speaking, I imagine the transform being used for someone who already has a fully built widget and we are just preserving/transferring the settings to the new format. In that case I imagine it could be unnecessary.

It could go either way I guess haha.

];
}

if ( instance.raw.showmap ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could also refractor this to all be in the array? Something like:

...( instance.raw.phone ? [ createBlock( 'jetpack/phone', { phone: instance.raw.hours } ) ] : [] ),
...( instance.raw.hours ? [ createBlock( 'core/paragraph', { content: instance.raw.hours } ) ] : [] ),
...( instance.raw.showmap ? [ createBlock( 'jetpack/map' ) ] : [] ),

@simison
Copy link
Member

simison commented Oct 7, 2021

Quick feedback, lemme know if I missed anything important:

If we wanted to automatically center the map for the user, we would have to first get the coordinates of the location.

Is it possible to use the same geocoder that Map block uses?

is to create a Contact Info & Maps block

Let's not add new blocks; we already have maps block and contact info block separately. It's confusing to have multiple very similar blocks.

Is it alright if it's a shortcode block?

Please don't output shortcodes; they don't work in new site-editor and are otherwise also just technical debt we don't want.

Overall: these transforms don't need to be pixel perfect 1:1, as long as the "sentiment" of the block gets transformed into blocks. It's fully expected that people need to do manual work after transform, or even return back to widget with "undo" if they aren't happy with the result.

@ivan-ottinger
Copy link
Contributor Author

Thank you for your feedback Mikael.

Is it possible to use the same geocoder that Map block uses?

I think it should be possible and will take a closer look.

Overall: these transforms don't need to be pixel perfect 1:1, as long as the "sentiment" of the block gets transformed into blocks. It's fully expected that people need to do manual work after transform, or even return back to widget with "undo" if they aren't happy with the result.

Makes sense. The first iteration of the block transform could be what was initially suggested in this PR:

Screen Capture on 2021-10-07 at 12-31-15

In other words, the text fields (Heading, Email, Address and Hours) would transfer and the default map gets added (through the Map block / Mapbox). User then needs to add the map pin manually.


The next iteration (once we can get the location coordinates), could add the map pin automatically with something like:

if ( instance.raw.showmap ) {
	innerBlocks = [ ...innerBlocks, createBlock( 'jetpack/map', {
		points: [ {
			title: instance.raw.title,
			placeTitle: instance.raw.title,
			caption: instance.raw.address,
			coordinates: {
				latitude: 48.14472,
				longitude: 17.11278
			}
		} ],
	} ) ];
}

(the example above has hardcoded coordinates - just to illustrate)

This could the look like this (also filling the pin details):
Screen Capture on 2021-10-07 at 12-45-46

Then, once we have the outcome of the following discussion: p7fD6U-4KX-p2, we can make further changes as necessary.


What do you all think? Does that sound reasonable?

@yansern
Copy link
Contributor

yansern commented Oct 11, 2021

What do you all think? Does that sound reasonable?

Yup, as agreed in our convos, let's try and see if we can fetch the coordinates from the address, then insert it as a Mapbox block. :)

@ivan-ottinger ivan-ottinger force-pushed the update/contact-info-and-map-widget-block-compatibility branch from 2c0fd29 to 8e74a8e Compare October 14, 2021 13:58
@ivan-ottinger ivan-ottinger force-pushed the update/contact-info-and-map-widget-block-compatibility branch from c80a87f to 7294532 Compare October 14, 2021 15:41
@ivan-ottinger ivan-ottinger changed the base branch from master to add/map-block-address-attribute October 15, 2021 07:14
@yansern
Copy link
Contributor

yansern commented Oct 15, 2021

What do you all think? Does that sound reasonable?

Yup, as agreed in our convos, let's try and see if we can fetch the coordinates from the address, then insert it as a Mapbox block. :)

As an update to this one, we're now updating the Mapbox block to resolve coordinates from address instead. :) It's been a rollercoaster. :)

Copy link
Member

@alshakero alshakero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested and works as expected!

@ivan-ottinger ivan-ottinger force-pushed the update/contact-info-and-map-widget-block-compatibility branch 2 times, most recently from 500a8ff to e2f820a Compare October 21, 2021 12:19
@matticbot
Copy link
Contributor

Caution: This PR has changes that must be merged to WordPress.com
Hello ivan-ottinger! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D68822-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

This commit adds transformation of the "Contact Info & Maps" widget into "Contact Info" block, plus extra necessary blocks.
This commit removes unnecessary variables and builds `innerBlocks` array directly.
If the `Show map` checkbox is selected, Map block is added during the transform.
Make sure that the extra Paragraph block is added only when the `Hours` field has some content.
This commit reverts the changes made in the previous commit as it makes more sense to introduce Map block changes in a separate branch/PR.
This commit adds the `address` attribute back after I had incorrectly removed it.
@ivan-ottinger ivan-ottinger force-pushed the update/contact-info-and-map-widget-block-compatibility branch from e2f820a to 9dcba56 Compare October 22, 2021 11:21
@samiff samiff added [Status] Ready to Merge Go ahead, you can push that green button! and removed [Status] Needs Author Reply We would need you to make some changes or provide some more details about your PR. Thank you! [Status] In Progress [Status] Needs Team Review labels Oct 22, 2021
@samiff samiff self-requested a review October 22, 2021 22:54
@samiff samiff merged commit 2c6b442 into add/map-block-address-attribute Oct 25, 2021
@samiff samiff deleted the update/contact-info-and-map-widget-block-compatibility branch October 25, 2021 20:27
@github-actions github-actions bot removed the [Status] Ready to Merge Go ahead, you can push that green button! label Oct 25, 2021
samiff added a commit that referenced this pull request Oct 25, 2021
* Add `address` attribute to the Map block

Map block component currently  doesn't provide a way to create a map from provided address.

This commit adds `address` block attribute that can then be geocoded  and used to render the map (as opposed to only using coordinates (lat, long)).

* Add `getCoordinates` function

The `getCoordinates` function will take care of the Mapbox API request.

The function accepts physical address and Mapbox API key as parameters.

The output is the promise / Mapbox API response that contains geo coordinates.

* Fix typo in  the changelog file

* Add `geoCodeAddress` function

`geoCodeAddress` will take care of creating the new map point based on the geo coordinates.

This commit also makes sure that the above function is run when the Map component updates (`componentDidUpdate`).

The function runs after the Mapbox API key is ready.

* Encode `apiKey` in the Mapbox API fetch request

* Remove unnecessary `console.error()` call

* Replace `console.error()` with `this.onError()`

This change will make sure there's  specific error message displayed in the front-end - as opposed to only displaying error in the console.

* Check whether Mapbox API returned any location / coordintes

This commit handles situations where the address provided by the user cannot be properly localized.

If the Mapbox API returns empty array of locations (`result.features`), we will display an error message.

* Make sure `result.features` won't throw if `features` object doesn't exist

* Refactor `newPoint` creation

The commit introduces a new const
`feature` that is then used as a building block for `newPoint` object values.

* Update `jetpack__map.json` structure - add `address` attribute

* Contact Info & Map widget: Add legacy widget → block transform (#21232)

* Remove Contact Info & Map widget from legacy-widget block

* Add changelog file

* Add transform of the legacy widget to  relevant block

This commit adds transformation of the "Contact Info & Maps" widget into "Contact Info" block, plus extra necessary blocks.

* Update changelog file

* Code refactor - construcing `innerBlocks` directly

This commit removes unnecessary variables and builds `innerBlocks` array directly.

* Add Map block to the transform

If the `Show map` checkbox is selected, Map block is added during the transform.

* Add conditional to the `Hours` field

Make sure that the extra Paragraph block is added only when the `Hours` field has some content.

* Remove `address` attribute from the Map block

This commit reverts the changes made in the previous commit as it makes more sense to introduce Map block changes in a separate branch/PR.

* Use the new Map block `address` field

* Add `address` attribute to the Map block

This commit adds the `address` attribute back after I had incorrectly removed it.

Co-authored-by: Samiff <samiff@users.noreply.github.com>
@ivan-ottinger
Copy link
Contributor Author

Just noting here that the changes have been successfully deployed to WPCOM. Related comment on the other PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants