Support chat using Zendesk Messaging - attempt 2

[klimeryk]

Reverts #77016

Second attempt at #76777

We're switching from Happy Chat to Zendesk Messaging for live chat support. This PR is big, but it's also the smallest I could get given the scope of the project. Any cleanup of Happy Chat code, old contact forms, etc. will be done as a follow-up. I want to keep this PR as easy to revert as possible if needed.

Proposed Changes

• Disable Happy Chat feature flag and any availability checks that trigger connections to the websocket.
• Load the Zendesk Messaging script instead.
• Authenticate using already established endpoint (just with type=zendesk).
• Check availability using the /help/messaging/is-available endpoint.
• Pass the initial chat data using Zendesk user fields.
• Use the support history to figure out if the user has ongoing conversations or not (thankfully, a Messaging conversation is a "ticket"!).
• Additionally, make sure the Zendesk launcher is visible if any unread messages are reported by Zendesk's APIs directly. This is a good safeguard and makes it more dynamic.
• After a refresh, if there's an active Messaging conversation, the Zendesk launcher should automatically appear.
• If the browser is blocking requests to Zendesk, show a notice and link to relevant support doc.
• New: support activity is fetched from data stored on the WPCOM user. No external APIs (like Zendesk's) are contacted. That will allow us to provide the best UX, without running into throttling issues.

Testing Instructions

The live chat support flow should feel the same up to the point where you click the chat CTA (Chat with us/Still chat with us). At that point, the Help Center should get hidden, while the Zendesk launch and widget should become visible.

Trying to show the Help Center should automatically minimize the Zendesk widget, to avoid clutter and confusing UI. The Zendesk launcher remains visible, so the user can come back to the conversation at any time.

If you have Enhanced Tracking Protection (or similar strict privacy settings and/or ad-blockers), you will see this notice when choosing the Live Chat support option:

Other support options should not show this notice, of course.

Verify that the Zendesk widget follows you on different paths in Calypso. Where Help Center is, the widget should also be there.

If you have an active, ongoing conversation, it should be detected and on refreshes the launcher should appear. If new messages arrive, it will be reflected with a count/notification on the launcher as well.

Verify these behaviors in different environments that Help Center has to work in:

• Simple sites
• Atomic sites
• Editor

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-ajp-p2)?

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-67253

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-67253&env=jetpack

[matticbot]

This PR modifies the release build for editing-toolkit

To test your changes on WordPress.com, run install-plugin.sh editing-toolkit revert-77016-revert-76777-update/zendesk-chat-feature on your sandbox.

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

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~61 bytes added 📈 [gzipped])

name           parsed_size           gzip_size
entry-stepper       +355 B  (+0.0%)      +85 B  (+0.0%)
entry-main          +355 B  (+0.0%)      +79 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~4621 bytes removed 📉 [gzipped])

name                   parsed_size           gzip_size
happychat                 -16151 B  (-2.3%)    -4681 B  (-2.4%)
checkout                     +53 B  (+0.0%)      +26 B  (+0.0%)
plans                        +52 B  (+0.0%)      +34 B  (+0.0%)
jetpack-connect              +52 B  (+0.0%)      +34 B  (+0.0%)
jetpack-cloud-pricing        +52 B  (+0.0%)      +34 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~21861 bytes removed 📉 [gzipped])

name                                              parsed_size            gzip_size
async-load-automattic-help-center                    -76513 B  (-10.6%)   -21849 B  (-10.2%)
async-load-calypso-components-happychat               -2532 B  (-13.8%)     -300 B   (-5.4%)
async-load-calypso-layout-masterbar-checkout-tsx       +485 B   (+0.4%)     +107 B   (+0.2%)
async-load-calypso-blocks-inline-help-popover          +485 B   (+0.1%)     +104 B   (+0.0%)
async-load-calypso-my-sites-checkout-modal              +53 B   (+0.0%)      +24 B   (+0.0%)
async-load-calypso-blocks-editor-checkout-modal         +53 B   (+0.0%)      +26 B   (+0.0%)
async-load-calypso-components-jetpack-portal-nav        +52 B   (+0.1%)      +27 B   (+0.2%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[arcangelini]

Suggested change

	$body = Client::wpcom_json_api_request_as_user( 'help/messaging/is-available?' . http_build_query( $query_parameters ) );
	$body = Client::wpcom_json_api_request_as_user( '/help/messaging/is-available?' . http_build_query( $query_parameters ) );

I could be wrong but I think you need the starting slash here.

[arcangelini]

I guess not, I can see an instance of it without. Forgive me : )

[klimeryk]

I'd assume so too, but looking at the other calls in this file and some others, it seems both versions work? 🤔

[klimeryk]

With a slash:

wp-calypso/apps/editing-toolkit/editing-toolkit-plugin/help-center/class-wp-rest-help-center-ticket.php

Line 78 in 6f2928a

'/help/ticket/new',

Without:

wp-calypso/apps/editing-toolkit/editing-toolkit-plugin/help-center/class-wp-rest-help-center-authenticate.php

Line 44 in 6f2928a

'help/authenticate/chat',

Those are existing calls that I assume are working. We could definitely update them to be consistent (probably the starting slash is the best way to go).

[klimeryk]

No worries, I appreciate the attention to detail! Those missing starting slashes in most cases are problematic. So probably good to fix this in a follow-up patch.

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/7996269

Thank you @klimeryk for including a screenshot in the description! This is really helpful for our translators.

[a8ci18n]

Translation for this Pull Request has now been finished.