Connection: protected owner class

[bindlegirl]

Related to: VULCAN-86
P2: pghT6q-3V-p2

Proposed changes:

• Created a class for errors related to missing protected owner i.e., the WP.com plan owners
• Class checks for the existence of an error option (created remotely) and based on it assembles the error array for displaying error in Jetpack dashboard and My Jetpack.
• Error is deleted when required user is created.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

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

Testing instructions:

• This needs to be tested with Connection: protected owner errors manual fix #43593, which handles the frontend part.
• Use Beta tester plugin to load this PR for the wpcomsh plugin and load the other PR for Jetpack plugin.
• When you have both PRs loaded in Beta, use cli to create an error for an account that doesn't exist wp option update jetpack_connection_protected_owner_error --format=json '{"error_type":"missing_owner","email":"[email protected]","timestamp":1747835900}'
• Check dashboard and My Jetpack, make sure error is there
• Create the missing account. Make sure the error is gone.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (WordPress.com Site Helper), and enable the add/protected_owner_error_wpcomsh branch.

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

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.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  
• ✅ 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 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

---

Wpcomsh plugin:

• Next scheduled release: Atomic deploys happen twice daily on weekdays (p9o2xV-2EN-p2)

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jp-launch-control]

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/plugins/wpcomsh/wpcomsh.php	110/321 (34.27%)	-0.11%	1 ❤️‍🩹

Full summary · PHP report

[fgiannar]

Quick question to determine if we can simplify the overall approach:
Given the jetpack_connection_get_verified_errors filter introduced in the connection package counterpart PR and assuming we modify the error handler here to handle the error code accordingly would we still need all these filters?

Example:

add_filter( 'jetpack_connection_get_verified_errors', array( $this, 'handle_error' ) );

public function handle_error( $verified_errors ) {
	// Check if option is populated
    // Check if user exists
    // If yes, delete the option
    // If not, proceed with adding the error in the $verified_errors array
}

[bindlegirl]

@fgiannar Thanks for checking it out. I have simplified the class a bit (single message, some logic for MyJetpack & Dashboard differences, e.t.c).
However, I did keep a separate filter for the React dashboard, as the Error_Handler class will only work for errors listed in handle_verified_errors(). I could have added the protected_owner_missing there, but I preferred to keep everything I can outside the Jetpack files. Given the plans for the old dashboard, I don't think this is a significant problem.

While working on this, I also realized that the delete method is not clearing jetpack_connection_xmlrpc_verified_errors while it should, so I had to add some logic for that part.

The class may not be much smaller now, but I think it is less bloated and contains fewer unnecessary lines of code.

[bindlegirl]

I refactored the Error_Handler class in the other PR so we can move most of the code out of this class. No filters, React dashboard... everything but the bare necessities (and that delete method 😊) is out.