feat: let core's copy of a presence function or class win when it already exists - #805

🛝 WordPress Playgrounds

Built from d34395c

	Post locks	RTC	Synced patterns	Settings
Single site
Multisite

Codecov Report

❌ Patch coverage is 99.74843% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.12%. Comparing base (e89901e) to head (d34395c).

@@             Coverage Diff              @@
##               main     #805      +/-   ##
============================================
+ Coverage     97.09%   97.12%   +0.02%     
  Complexity      271      271              
============================================
  Files            30       30              
  Lines          4370     4375       +5     
============================================
+ Hits           4243     4249       +6     
+ Misses          127      126       -1     

Dropped the defined() guards on WP_PRESENCE_MAX_KEY_LENGTH and WP_PRESENCE_RESERVED_PREFIX that I proposed on #733: a guard lets a site set them in wp-config.php, and a key length above the column's 191 would bring back the silent truncation it prevents, while core redefining one is only a warning.

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props huzaifaalmesbah, rejaulalomkhan, joefusco.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Wrapping public functions and classes in \unction_exists()\ / \class_exists()\ is the clean canonical Gutenberg/feature-plugin approach for incremental Core adoption.

Regarding Codecov's note (\Patch coverage is 99.74555% with 2 lines in your changes missing coverage): the uncovered lines are the fallback branches where a function/class already exists before inclusion. Adding a test in \ est-core-guards.php\ that declares a mock presence function/class before running the guard check will exercise those fallback branches and restore 100% patch coverage.

#733 now has answers to Deepak's scope questions, which change this PR in two places:

• Drop the guard in includes/cli/, since that code goes to WP-CLI rather than core.
• Wrap the functions in cron.php, privacy.php, lifecycle.php, heartbeat.php, site-health.php and rest-api.php the same way, since Core-bound code can't be lifted out of the plugin one ticket at a time #554 sends those to core in different tickets.

Guarding every function in presence.php, private helpers included, and the REST controllers stays as it is.

Merged main to clear the conflicts with #815. I rebuilt both files from main's copy with the same wrapping rather than resolving each hunk, so wp_presence_session_hash() is guarded too.