feat(preferences): site-aware, opinion-free block preferences#35
feat(preferences): site-aware, opinion-free block preferences#35zackkatz wants to merge 3 commits into
Conversation
The shipped preference table hardcoded a GravityKit-flavored opinion: a fixed namespace score list (filter/gravityforms preferred, stackable/ugb/jetpack branded legacy) plus a built-in Stackable/UGB replacement map. That contradicted sites not running those plugins and quietly imposed migrations no admin chose. Preferences are now derived from the site itself. - Ship opinion-free defaults: only `core` is preferred (90); every other namespace resolves to a neutral 50, and the replacement map ships empty. - Stop deep-merging `replacement_map`; it is the admin's authoritative list, taken verbatim, so a removed mapping stays removed. - Build the score table from a site-aware row universe: families registered by active plugins/themes, families the admin scored, and families found in published content. Store `namespace_scores` overrides-only so Reset reverts to default and storage never accumulates the neutral defaults. - Flag orphaned blocks in read responses (`preference.orphaned`) and in the score table when a namespace appears in content but has no registered provider. - Migrate existing sites on activation and lazily on `plugins_loaded`: bump the schema to 1.5.0, preserve saved preferences verbatim, and raise a one-time, dismissible notice explaining the new model for sites that had saved prefs. - Drop em-dashes from the settings copy.
…ocks - Add PreferencesMigrationTest for the 1.5.0 migration: schema stamping, idempotency, and the one-time notice flag for sites with saved preferences. - Rework SettingsPagePreferencesTest and PreferencesTest for the overrides-only store, verbatim replacement map, and site-aware row universe (Reset control, default marker, orphaned flag); drop the old "layer over shipped defaults" contracts. - Cover `preference.orphaned` for unregistered namespaces in BlockCrudTest. - Seed legacy/avoid namespaces explicitly in the shared bases now that the shipped defaults brand nothing legacy (BlockApiTestCase, PostManagerTest, RestSummaryTest).
Add the = develop = entry describing the site-aware, opinion-free preference model, preserved upgrade settings, the orphaned-block flag, and the new `preference.orphaned` developer field.
|
Warning Review limit reached
More reviews will be available in 2 hours, 11 minutes, and 15 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (13)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Summary
Reworks block preferences to be site-aware and opinion-free, so the score table reflects the block families actually on the site rather than a fixed built-in list, and no third-party block is treated as legacy unless the admin chooses to score it down.
preference.orphaned: truefor any block whose namespace has no registered provider, so integrations can detect orphaned blocks.Changes
gk-block-mcp.php,class-preferences.php,class-block-reader.php,class-settings-page.php,uninstall.php— site-aware/opinion-free model, migration, orphaned detection, settings UI + reset notice.readme.txt—= develop =changelog entry.PreferencesMigrationTest.php; updated coverage across Preferences, Settings page, Block CRUD, Post, REST summary, and API test case for the site-aware model, migration, and orphaned blocks.Test plan
https://claude.ai/code/session_011ywjjoe3j6XLMsTNammUU6