Wpcomsh fatal-error: pass site_url as a property; drop unused /logstash siteurl

[taipeicoder]

Fixes #

Proposed changes

• Drop the unused top-level siteurl field from /logstash payloads. The wpcom /logstash receiver doesn't consume siteurl (the convention on that endpoint is blog_id / atomic_site_id), so stamping it on every drained logstash payload from WPCOMSH_Log::send_to_api() was dead weight — the field was simply ignored on the receiver side. The drain loop now JSON-encodes the queue entry as-is.
• Pass site_url as a property instead. wpcomsh_fatal_log_signature() now adds 'site_url' => get_site_url() to its $properties array, so the field surfaces at top-level properties.site_url in Kibana alongside properties.signature / properties.kind / properties.slug / properties.extension_version / properties.wp_version / properties.php_version. Dashboards can now filter / sort / aggregate on it directly with the same query shape as the other extension-conflict fields.
• $this->siteurl is still used by the /automated-transfers/log envelope (existing unsafe_direct_log() callers) at the top-level siteurl field there — that endpoint does consume it. Only the unused /logstash stamping was dropped.

Related product discussion/links

• Follow-up to Wpcomsh fatal-error: route signature records to /logstash under atomic_extension_conflict #48399 (which itself is a follow-up to Wpcomsh fatal-error: emit a transportable plugin/version/core/php signature #48369).

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

Yes, but in a strictly subtractive + reshuffling way. The site URL was already being sent (and ignored by the receiver) at top-level siteurl on /logstash payloads via #48399. This PR moves it to properties.site_url on the fatal-error record only — same value (get_site_url()), same site, the only change is that it now lands in a field the receiver actually indexes. No new data is collected; no field is added that wasn't already in the wire payload before.

Testing instructions

1. On an Atomic test site, trigger a fatal from a directory-based plugin or mu-plugin (e.g. drop wp-content/mu-plugins/boom/boom.php containing trigger_error( 'boom', E_USER_ERROR ) on init).
2. In Kibana (log2logstash index, feature:atomic_extension_conflict), open the resulting record and confirm:
   • properties.site_url is present, holds the site's URL, and is filterable / sortable directly (e.g. you can build a "top sites by extension fatals" terms aggregation on it).
   • Top-level siteurl is absent on /logstash records (it'd be ignored anyway, but it's no longer occupying the wire payload).
3. Verify the other properties.* fields from Wpcomsh fatal-error: route signature records to /logstash under atomic_extension_conflict #48399 (signature, kind, slug, extension_version, wp_version, php_version) are unchanged and still indexed at the same paths.
4. Verify no regression for /automated-transfers/log callers: do something that triggers an existing WPCOMSH_Log::unsafe_direct_log() caller (e.g. an Atomic Storage error, a marketplace install error, a WoA setup log line). Confirm their records still arrive in feature:automated_transfer with the standard top-level siteurl field intact (that endpoint still consumes it).

[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 update/wpcomsh-fatal-error-site-url-property 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 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/class-wpcomsh-log.php	13/44 (29.55%)	1.28%	-2 💚

Full summary · PHP report