↑ Back to top

  • filter

    jetpack_my_jetpack_feature_visibility

    Filters which items appear on the My Jetpack Features page. Keys are product or module slugs, and a Features grid entry also answers to its own slug. ‘hidden’ keeps the item off the page, search included; anything else lists it. The whole map is passed so that two mu-plugins setting different keys merge.

  • filter

    jetpack_action_bar_enabled

    Filters whether the Action Bar loads on this request. WordPress.com hooks this to keep the bar off its internal sites and off sites marked deleted, spam, archived, or parked.

  • filter

    DASHBOARD_DEFAULT_LAYOUT_FILTER

    Filters a dashboard section’s default widget layout. Each entry matches the dashboard’s widget instance shape: `uuid`, `type`, optional `attributes`, optional `placement`. Runs for every section, so a callback adding an instance to one switches on `$section_id`.

  • action

    self::REGISTER_ACTION

    Fires when the dashboard section registry hydrates, on its first read after `init`. Register sections here rather than on `init`: the registry is read from wp-admin and from REST, and each path loads it at a different moment. A registrant that may run twice guards with `is_registered()`.

  • filter

    self::SANDBOX_PARTNER_ATTRIBUTION_FILTER

    Filters the PayPal partner attribution ID (BN code) while the site is connected to the PayPal sandbox. PayPal issues a sandbox account its own BN code, which the production one does not match. The production BN code is not filterable.

  • filter

    jetpack_feature_policy

    Filters how Jetpack treats each feature on this site. Keys are module slugs for `activation`. For `visibility`, keys are anything the My Jetpack Features page answers to: product, module, or feature slugs. Each value is an array with either or both of: – `activation`: ‘forced-on’ or ‘forced-off’ pin the module on every request, the same as `jetpack_active_modules`. ‘default-on’ or ‘default-off’ change what Jetpack turns on when it activates its default modules, which happens at connection and upgrade, not on an existing site. ‘default’ leaves it alone. A ‘forced-on’ slug this site has no module for still reads as active, but calls `_doing_it_wrong()` since nothing will load it. – `visibility`: ‘hidden’ keeps the item off the My Jetpack Features page and out of the wp-admin sidebar, ‘visible’ shows it in both. A sidebar entry matches on its item key or on the product or module gate it declares. The policy runs last, so ‘visible’ overrides a ‘hidden’ another callback set. Standalone plugin products (Akismet, Boost, CRM, Protect) take `visibility` only: WordPress decides which plugins load before Jetpack runs, so forcing one needs `option_active_plugins` in an mu-plugin. Register the policy before `after_setup_theme`, from an mu-plugin, plugin, or theme: `Jetpack::load_modules()` runs there at priority -2, so a later policy (on `init`, say) misses module loading while My Jetpack still honors it — the module runs on a page saying it is off.