↑ Back to top

  • filter

    jetpack_email_editor_bootstrap

    Filters the data the newsletter email editor needs to start. Returns the editor’s settings, its theme, the resolved canvas template, the available personalization tags and the blog’s saved design. Unfiltered on a site with nothing implementing it, which the endpoint reports as unavailable rather than as an empty design. Internal, and not settled: the editor this serves is still being built, so the shape of what comes back is expected to change. Do not depend on it from outside the plugin.

  • filter

    jetpack_podcast_feed_limit_max

    Filters the ceiling for the podcast feed’s episode limit. Raising it renders that many items in one request, so only where the host can absorb it.

  • action

    jetpack_site_data_fetched

    Fires after the site record was served, whether it was fetched or read from the cache. Consumers that cache anything derived from the record, such as the current plan, can refresh it here. This fires on a cached read too, so a consumer stays in step with every request that serves the record rather than only the ones that reached WordPress.com. The record is passed as an array rather than the object this method returns, so that a listener cannot mutate the instance that becomes the REST response.

  • action

    jetpack_connection_tokens_deleted

    Fires after all connection tokens have been deleted from the local site. `Jetpack_Options::delete_option()` fires no action of its own, so this is the only signal that the tokens backing the connection are gone. Anything holding derived state — a memoized connection status, a cached credential — must recompute from here.

  • filter

    DASHBOARD_PREVIEW_SCOPE_FILTER

    Filters whether the preview exposes a dashboard section. `__return_true` restores the whole dashboard, which is how a development or test site sees every tab.

  • filter

    jetpack_forms_file_field_max_upload_size

    Filters the largest file a file upload field accepts, in bytes. Deliberately not bounded by the site’s own PHP upload limits. The browser sends each file straight to the upload endpoint, so `upload_max_filesize` and `post_max_size` have nothing to do with this transfer — clamping to them would cap the field at whatever a cheap host allows for files that host never receives. The bound that does matter is the endpoint’s own, which rejects anything over FILE_FIELD_MAX_UPLOAD_SIZE. So this filter can only lower the limit, never raise it: a larger value would have the field accept a file, show the visitor a size allowance in the “file is too large” message that nothing can honour, and then fail the upload once they had already waited for it. Raising the ceiling means raising it at the endpoint first. The result reaches the browser as the `maxUploadSize` config value, and the “file is too * large” message is built from the same number, so the two cannot disagree.