Skip to content
CoverKit CoverKit v0.1.13

Custom use cases (developers)

Site owners use built-in use cases from the template editor. Developers can add new output types by registering a slug with CoverKit’s registry—optionally backed by a PHP subclass when you need custom behavior.

This page is a checklist; architecture and APIs are documented in Use cases and output profiles. Built-in variants are summarized in the Use cases overview.

Checklist

Section titled “Checklist”

  1. Register on coverkit_init (priority before 10 if you need to load before built-ins):

    add_action( 'coverkit_init', function () {
        coverkit_register_use_case(
            'my_output',
            array(
                'label' => __( 'My output', 'my-plugin' ),
            )
        );
    } );

    When you omit class, CoverKit uses base Use_Case behavior (shared image settings, default mapping catalog, no custom front-end hooks).

  2. Subclass CoverKit\Use_Case only when you need custom dimensions, settings, mappings, or runtime hooks—and pass 'class' => My_Output_Use_Case::class in the registration array.

  3. Implement protected function init(): void in your subclass — register only hooks/filters; keep it cheap.

  4. Define optional settings schema, recommended dimensions/formats, and mapping sources on the class.

  5. Document required mappings for editors (labels, required vs. recommended).

  6. Test enablement on a template, save assignments, and confirm render + cache behavior.

Mandatory registration data: slug and label. class is optional.

Variants vs. filters

Section titled “Variants vs. filters”
ApproachWhen
Filter on mapping sources or labelsSmall tweak to an existing use case
New slug + subclassA distinct option in the UI (for example opengraph_product extending Open Graph behavior)
New class extending Use_Case directlySubstantially different behavior

Do not mutate a built-in registration globally to fork behavior—register a new slug instead.

What editors will see

Section titled “What editors will see”

After registration, your use case appears in the template editor Use cases sidebar like built-ins: enable, settings (if any), and field-to-layer mapping.

The optional single flag at registration marks install-wide singletons: at most one template site-wide may have the use case enabled (for example a dashboard widget). Default is false — one assignment per template with no cross-template conflict. Multiple outputs use separate registered slugs (variants), not multiple instances on one slug. Editors see guidance when single: true and another template already holds the active slot.

Built-in reference

Section titled “Built-in reference”

Study these implementations in the plugin:

  • CoverKit\Use_Cases\Sandbox_Use_Case
  • CoverKit\Use_Cases\Open_Graph_Image_Use_Case
  • CoverKit\Use_Cases\Featured_Image_Use_Case

Registration: includes/use-cases/bootstrap.php.

Section titled “Related”