How to extend core block class SystemBrandingBlock

Please advice how we can extend the core block class Drupal\system\Plugin\Block\SystemBrandingBlock to add custom method.

In my case, I want to include function buildToArray() to get the block data in array format rather than rendered array.

Existing build() method:

public function build() {
    $build = [];
    $site_config = $this->configFactory->get('system.site');

    $build['site_logo'] = [
      '#theme' => 'image',
      '#uri' => theme_get_setting('logo.url'),
      '#alt' => $this->t('Home'),
      '#access' => $this->configuration['use_site_logo'],
    ];

    $build['site_name'] = [
      '#markup' => $site_config->get('name'),
      '#access' => $this->configuration['use_site_name'],
    ];

    $build['site_slogan'] = [
      '#markup' => $site_config->get('slogan'),
      '#access' => $this->configuration['use_site_slogan'],
    ];

    return $build;
}

Required method to add:

public function buildToArray() {
    $site_config = $this->configFactory->get('system.site');

    return [
      'site_logo' => theme_get_setting('logo.url'),
      'site_name' => $site_config->get('name'),
      'site_slogan' => $this->configuration['use_site_slogan'],
    ];
}

Extending a Block

To extend the block, you'll define a new block, as described in the following tutorial, except that you would extend the class Drupal\system\Plugin\Block\SystemBrandingBlock, instead of the class Drupal\Core\Block\BlockBase. You can then add your custom method to the newly defined block.

https://www.valuebound.com/resources/blog/drupal-8-how-to-create-a-custom-block-programatically

Alternative consideration

If what you need from SystemBrandingBlock is just the data, and not necessarily an actual block, I would advise to instead define a service that provides the data from your buildToArray() method.

Comment Responses

It is true that this will create a new block type, in addition to the SystemBrandingBlock. Blocks are managed, organized and retrieved by the Block Plugin Manager. You could write a decorator for this service and override the getDefinitions() method in order to prevent the original SystemBrandingBlock from being available as a plugin definition, achieving the effect of replacing the original SystemBrandingBlock with your new block.

It still sounds to me like a service is what you need. By examining the code in the original SystemBrandingBlock class definition, we see that SystemBrandingBlock only relies on one service, config.factory. So your service only needs to inject the config.factory service in order to retrieve the information that you need for the buildToArray() method (which might be better renamed as something like getBrandingInfo()). Defining a service in this way means that you won't need to worry about implementing or deploying a block (which doesn't seem to be what you need, anyway), or needing to write a service decorator.

Bear in mind, also, that the SystemBrandingBlock is not the original source of the data, but rather a plugin for displaying those data in a rendered format. The block is completely irrelevant if all you want are the data.

Finally, speaking in broader terms, Drupal is organized largely around plugins, services and dependency injection, and becoming familiar with these concepts will give you the tools to systematically solve many problems in Drupal.