Site Editor Tracking: Add events for selecting content items in the navigation sidebar

[david-szabo97]

Changes proposed in this Pull Request

• Track selecting content item in the navigation sidebar
  • Event name: wpcom_block_editor_nav_sidebar_item_edit
  • Event properties:
    • item_type - type of the selected item (page, post, category, etc.)
    • item_slug - slug of the selected item

Note setPageis called twice due to a bug in Gutenberg: WordPress/gutenberg#33286

Testing instructions

• Open Site Editor
• Open navigation sidebar
• Change to a content item
• Make sure event is tracked

Make sure E2E tests are passing.

Related to #

[matticbot]

Link to Calypso live: https://calypso.live?image=registry.a8c.com/calypso/app:build-10118
Link to Jetpack Cloud live: https://calypso.live?image=registry.a8c.com/calypso/app:build-10118&env=jetpack

[matticbot]

This PR modifies the release build for wpcom-block-editor

To test your changes on WordPress.com, run install-plugin.sh wpcom-block-editor add/site-editor-track-navigation-content on your sandbox.

To deploy your changes after merging, see the documentation: PCYsg-l4k-p2

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[Addison-Stavlo]

This is looking good so far and tests are working well. just a couple comments.

[Addison-Stavlo]

It seems when we select a 'category' page we just get item_slug with the category name and no item_type.

[david-szabo97]

We don't have that information from the args. 😢 Used a selector to check the active menu. Type is determined based on that in this case.

[Addison-Stavlo]

Another idea might be to debounce the function that sends the event with a very small time window so only 1 event sends. Although, this double-dispatch should definitely be fixed anyways and will solve this problem.

[mattwiebe]

Debouncing!

[david-szabo97]

Anyone planning to run e2e tests, make sure to comment this line:

wp-calypso/test/e2e/lib/components/site-editor-component.js

Line 250 in 580ee06

await driverHelper.clickWhenClickable( this.driver, () => notice );

Latest Gutenberg version introduced a regression, showing the snackbar below the inserter, which prevents us from clicking on the notice to dismiss it.

[matticbot]

This PR modifies the release build for notifications

To test your changes on WordPress.com, run install-plugin.sh notifications add/site-editor-track-navigation-content on your sandbox.

To deploy your changes after merging, see the documentation: PCYsg-elI-p2

[matticbot]

This PR modifies the release build for editing-toolkit

To test your changes on WordPress.com, run install-plugin.sh editing-toolkit add/site-editor-track-navigation-content on your sandbox.

To deploy your changes after merging, see the documentation: PCYsg-mMA-p2

[mattwiebe]

Is it expected that wpcom_block_editor_nav_sidebar_item_edit would be called upon the Site Editor upon first load?

{
  "editor_type": "site",
  "item_type": "template",
  "item_id": "pub/tt1-blocks//index",
  "blog_id": 34321322,
  "site_type": "simple",
  "user_locale": "en"
}

---

The rest of this may be totally expected but I haven't been following the stats work so I had some questions about expected behaviour. Since I was debugging on wpcom-block-editor:analytics:tracks, I noticed that after I clicked on a page to edit within the Site Editor ( wpcom_block_editor_nav_sidebar_item_edit 👍 ) that I got some other events that may or may not be expected?

Basically what happens is that, after the page is selected, Gutenberg repaints its editor canvas with the blocks of the selected page. This winds up callind wpcom_block_inserted even though these aren't being inserted explicitly by the user, so that could muddy our stats a bit.

[david-szabo97]

Is it expected that wpcom_block_editor_nav_sidebar_item_edit would be called upon the Site Editor upon first load?

Nope! Fixed it. Though it's quite hacky 😬

The rest of this may be totally expected but I haven't been following the stats work so I had some questions about expected behaviour. Since I was debugging on wpcom-block-editor:analytics:tracks, I noticed that after I clicked on a page to edit within the Site Editor ( wpcom_block_editor_nav_sidebar_item_edit 👍 ) that I got some other events that may or may not be expected?

This is a known issue 😞 We have a workaround for reusable blocks and template parts. But we found out this problem comes up with many other blocks that includes/loads inner blocks.

[mattwiebe]

Thanks for the fixes, this looks good and tests properly 🚢