Fetch all support articles from the same endpoint

[gravityrail]

This change is intended to support moving all help content, even default content, into a back-end vector database. This includes consolidating "Sibyl" and regular help center articles, plus so-called "default links" that used to be baked into the front-end, and potentially more in the future.

It also adds a bunch of tracking and convenience features, thumbs up/down on GPT generated response, etc.

The back-end changes have already been merged in this change: D110161-code

This will allow much easier and more consistent instrumentation and optimization of our whole help-search workflow since everything will be going through a single endpoint with a single ranking algorithm and set of events.

Issues I Encountered

This patch has slowly grown as I hit a few issues with the help center. Here's just a few:

• First and foremost: We have tons of different ways of fetching relevant help. We should have one. Help is help is help.
• Inconsistent tracking
• No indication on fetched links whether they're internal or external
• Deep linking from search results to help docs didn't work
• Email subject/body is not populated from search query, forcing user to enter the same info twice, and email subject was ignored when generating the response
• There's no way to cancel/skip the GPT response and it can take a long time
• No way for user to indicate if they were happy with the GPT result
• No detection of an empty "Oops!" result or an error (I haven't fixed all these cases yet since they require changes on the back-end)

Proposed Changes

• Move hard-coded per-section articles and Sibyl searches behind a single API, /wpcom/v2/help/search/wpcom (which already exists)
• Handle empty help queries by trying to provide original default content
• Include section with the help query to guide the response
• Turn HelpLink into a real component so we can use
• Refetch default content on mount
• Fetch content even if search is empty
• Automatically scroll to the anchor location within a loaded inline article
• Automatically populate the subject and message of a support email with the user's query
• Populate GPT query with both subject and message if they are sufficiently different (first 50 chars not identical)
• Allow users to give GPT generated response a thumbs up/down, sending this data to Tracks
• Add a "Cancel" button for generating response, a shortcut to emailing
• Remove Sybil results from help-center-contact-page.tsx
• Add a "Close" button if we have generated a GPT response that the user can click to close the widget instead of continuing to email.
• Tracking (see below)

New tracking events:

• calypso_inlinehelp_article_no_postid_redirect
• calypso_inlinehelp_article_select
• calypso_inlinehelp_contact_gpt_close
• calypso_inlinehelp_contact_gpt_cancel
• calypso_helpcenter_gpt_response_thumbs_up
• calypso_helpcenter_gpt_response_thumbs_down
• calypso_inlinehelp_article_click_external_link

Other Changes

• Remove the site picker when it's not enabled because it's just confusing and takes up vertical space. Same with "You're sending an email!" type titles.
• Show a right-chevron when viewing article inline, external-link icon when clicking to an external link
• Fixed a few places where classes and constants had the same name in the same file, e.g.

// this line redefines interface ArticleFetchingContent as function ArticleFetchingContent - bad
const ArticleFetchingContent = ( { postId, blogId, articleUrl }: ArticleFetchingContent ) => {
  // ...
}

• Simplify implementation of help-center-footer.tsx

Known Issues

• Canceling a GPT response puts the UI in a weird state where the user has to click one more time to show the email form

TODO next time

• Remove class-wp-rest-help-center-sibyl.php

Testing Instructions

• Everything should more-or-less work the same as before, except that it will do a request on mount for the the relevant content.

Side-by-side comparisons

Old doc list	New doc list

Old search theme	New search theme

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-67170

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-67170&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 goldsounds/vectorized-help-search 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 (~191 bytes removed 📉 [gzipped])

name                   parsed_size           gzip_size
entry-stepper               -342 B  (-0.0%)     -123 B  (-0.0%)
entry-main                  -342 B  (-0.0%)     -118 B  (-0.0%)
entry-subscriptions         -126 B  (-0.0%)      -50 B  (-0.0%)
entry-login                 -126 B  (-0.0%)      -50 B  (-0.0%)
entry-domains-landing       -126 B  (-0.0%)      -50 B  (-0.0%)
entry-browsehappy           -126 B  (-0.1%)      -50 B  (-0.1%)

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

Sections (~8137 bytes removed 📉 [gzipped])

name   parsed_size           gzip_size
home      -37478 B  (-2.5%)    -7666 B  (-1.9%)
plans        +32 B  (+0.0%)      +31 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 (~777 bytes removed 📉 [gzipped])

name                                           parsed_size           gzip_size
async-load-calypso-blocks-inline-help-popover     -37462 B  (-4.8%)    -7649 B  (-3.4%)
async-load-automattic-help-center                 -36979 B  (-4.9%)    -7527 B  (-3.4%)
async-load-calypso-blocks-inline-help               -216 B  (-1.7%)      -32 B  (-0.9%)

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.

[gravityrail]

I can't replicate these test failures locally - help!

[worldomonation]

I merged my changes to the Support specs in #76960.
Tried rebasing your changes on top of fresh trunk and ran the Support popover spec locally with great results.

 PASS  specs/support/support__popover.ts (11.42 s)
  Support: Popover/Invalid Keywords
    ✓ Open support popover (115 ms)
    Search for terms
      ✓ Search for "theme" returns articles and show me where links  (1950 ms)
      ✓ Search for blank string returns only articles (1371 ms)
      ✓ Search for gibberish string returns only articles (1897 ms)
    Search for a valid term and open the supporting article
      ✓ Search for "domains" (2817 ms)
      ✓ Click on the article with matching title (64 ms)

Test Suites: 1 passed, 1 total
Tests:       6 passed, 6 total
Snapshots:   0 total
Time:        11.593 s
Ran all test suites matching /test\/e2e\/specs\/support\/support__popover.ts/i.

[gravityrail]

@klimeryk and others - main things that need cleaning up:

• battle-test the patch for regressions
• canceling an in-progress GPT completion should go straight to the "send an email" form, or maybe the button should say "Skip and send the email", but regardless this is a bit clumsy right now
• clicking "close" when a GPT completion is displayed should close the widget, but right now it returns to the starting screen
• when a GPT completion comes back with the was_empty_response field set to true then it should treat the response as an error, or empty, and just go ahead and send the email instead (automatically, I suppose)
• identify and delete any code that is no longer needed (though this can wait until later if necessary)

I think if we can make those changes then this is good to go. I think they'll be much quicker to make for someone familiar with the help center.

[alshakero]

Wow, what a PR! Can't believe I couldn't find any issues. Went through it twice.

I reviewed and tested in Calypso and the editor. In the Editor there are no GPT results as expected.

I tested searching, suggestions, giving feedback to GPT results, all works as expected. I didn't test in Atomic, but I didn't find any changes that would need testing in Atomic (eg changing endpoints).

The only thing I wasn't able to see is this:

Add a "Cancel" button for generating response, a shortcut to emailing

[gravityrail]

Merged from trunk. I plan to merge this as soon as tests pass.

[alshakero]

@klimeryk is also working on a big PR and one of you will suffer mildly significant conflicts. Luckily, this PR doesn't touch a lot on chat logic.

[a8ci18n]

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

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

[klimeryk]

@klimeryk is also working on a big PR and one of you will suffer mildly significant conflicts. Luckily, this PR doesn't touch a lot on chat logic.

Thankfully, the merge conflicts were indeed quite limited 😌

[noahtallen]

I was working on #77046, which (unfortunately) means fixing "new" type issues (well, it fixes bugs which caused some issues to not get reported) -- dropped a couple questions to make sure any fixes I do work correctly

[noahtallen]

Was this meant to be post_id or blog_id? (or is postId also available? -- the types only encode the underscore variant)

[noahtallen]

Does searchResult do anything here? The type info for navigate here doesn't share any properties with searchResult

[a8ci18n]

Translation for this Pull Request has now been finished.