Connection: seed jetpack_tos_agreed to avoid per-request reads

[darssen]

Proposed changes

• Terms_Of_Service::get_raw_has_agreed(): when jetpack_tos_agreed is absent, seed it as an autoloaded false (via add_option, using a null sentinel to distinguish "never stored" from a stored false), so it isn't re-queried every time it's read.
• Add a real options-table Terms_Of_Service_Seeding_Test covering absent → seed (autoloaded) and stored → not re-seeded.

Why are these changes being made

On a site without a persistent object cache, WP's per-request option caches (alloptions/notoptions) are discarded each request, so a non-autoloaded option costs a dedicated SELECT … FROM wp_options each time it's read.

jetpack_tos_agreed is read via Terms_Of_Service::has_agreed(), which fires whenever tracking is evaluated — Tracks events, tracking-script enqueues, and Jetpack admin pages (e.g. the dashboard). When the option is absent, each of those requests re-reads a missing option. Seeding an autoloaded default on the first miss moves it into the single bulk alloptions load. It's not synced, and behaviour is unchanged (an unset option already resolved to false; a stored value still wins and is never overwritten).

Open question — is seeding false the right call, or should the tracking gate change?

This is why it's split out from the jetpack_offline_mode change (#50961) and opened for discussion.

jetpack_tos_agreed has exactly one writer: Connection\Manager::try_registration() → Terms_Of_Service::agree() — the plugin-driven site-registration step. A site connected through any other path (platform/host-level provisioning, CLI, partner/pre-provisioned tokens, or connections predating the option) never runs it, so has_agreed() is false even though the site is fully connected. On those sites the option is legitimately absent, which is what makes it re-read.

That exposes an inconsistency between the two tracking gates:

• Tracking::should_enable_tracking() → ! is_offline_mode() && ( has_agreed() || is_user_connected() ) — tolerant: a connected user is enough.
• Jetpack_Tracks_Client::record_event() → strict: if ( ! has_agreed() || opt-out ) return false; — no is_user_connected() fallback.

So on a connected-but-unregistered site, should_enable_tracking() says "track" while record_event() silently drops server-side events.

Questions for reviewers:

1. Should jetpack_tos_agreed even gate these sites, or does an active connection already imply agreement? (i.e. is false the correct value to seed, or is the real issue that it should be true / not consulted?)
2. Should Jetpack_Tracks_Client::record_event() use the same || is_user_connected() fallback as should_enable_tracking(), so the two gates agree?
3. If either of the above changes, this seed may be unnecessary — happy to drop it in favour of the gate fix.

The seed here is the minimal, behaviour-preserving option (it removes the repeat read without changing any tracking outcome), but it papers over the above rather than resolving it.

Related product discussion/links

• JETPACK-1539

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

No. Seeding writes the existing default value (false) to the local options table; has_agreed() returns the same result as before, so no tracking behaviour changes. Not synced to WordPress.com.

Testing instructions

Use a site with no persistent object cache (on jurassic.ninja, create it with "Drop-in Cache Plugins" unchecked; confirm wp eval 'var_dump( wp_using_ext_object_cache() );' is false).

Add a logger mu-plugin (wp-content/mu-plugins/tos-check.php):

<?php
add_filter( 'query', function ( $q ) {
    if ( stripos( $q, 'option_value' ) !== false && strpos( $q, 'jetpack_tos_agreed' ) !== false ) {
        @file_put_contents( WP_CONTENT_DIR . '/tos.log',
            gmdate( 'c' ) . ' ' . trim( preg_replace( '/\s+/', ' ', $q ) ) . "\n", FILE_APPEND | LOCK_EX );
    }
    return $q;
}, 0 );

jetpack_tos_agreed is not read on plain front-end requests — exercise it from wp-admin: log in and reload the Jetpack dashboard (or any wp-admin page) a few times, then cat wp-content/tos.log.

• Before: one SELECT … 'jetpack_tos_agreed' per admin page load.
• After: only on the first load, then gone. Confirm the row is autoloaded: wp db query "SELECT option_name, autoload FROM wp_options WHERE option_name = 'jetpack_tos_agreed'" → autoload = on.

Terms_Of_Service::has_agreed() still reflects stored TOS state; a value set beforehand is never overwritten.

Unit tests: projects/packages/connection — Terms_Of_Service_Seeding_Test.

[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 (Jetpack or WordPress.com Site Helper), and enable the add/jetpack-tos-agreed-autoload branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack add/jetpack-tos-agreed-autoload

bin/jetpack-downloader test jetpack-mu-wpcom-plugin add/jetpack-tos-agreed-autoload

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!

[jp-launch-control]

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/packages/connection/src/class-terms-of-service.php	14/15 (93.33%)	2.42%	0 💚

Full summary · PHP report · JS report