How to add custom settings?

Hi @kevinquillen - there are a couple ways to do this:

1) A hook_form_alter() for the settings form and then using the Charts API for rendering: https://git.drupalcode.org/project/charts/-/blob/5.0.x/charts.api.php

2) Creating a plugin that extends one of the Charts plugins; for example, extending ChartsPluginStyleChart.php (https://git.drupalcode.org/project/charts/-/blob/5.0.x/src/Plugin/views/...). I like extending the plugin more personally.

For both, check out the charts_api_example module, paying particular attention to the raw_options:
https://git.drupalcode.org/project/charts/-/blob/5.0.x/modules/charts_ap...

Does this help?

In this case it is a field on nodes, not a View, so I can't do the view plugin. So if I form alter it and add whatever fields into that form, its ingested into the config that is stored in the field value? I'll try that out.

@kevinquillen - please let me know if/how this worked. I'll try to use that as motivation for better documentation!

Hook form alter wasn't giving me much for altering the settings form. I suppose that is because processSettings is called after hook_form_alter, which is where the form items for the element come from.

Instead, I had to use hook_element_info_alter and supply my own build callback:

use Drupal\Core\Form\FormStateInterface;

<?php
/**
 * Implements hook_element_info_alter().
 */
function mymodule_element_info_alter(array &$info) {
  if (isset($info["charts_settings"])) {
    $info["charts_settings"]["#process"][] = [
      \Drupal\mymodule\MyModuleChartsElementSettings::class,
      'processSettings',
    ];
  }
}

Once that was registered, I could have a generic class that is called:

class MyModuleChartsElementSettings {

  /**
   * Processes the settings element.
   *
   * @param array $element
   *   The form element.
   * @param \Drupal\Core\Form\FormStateInterface $form_state
   *   The form state.
   * @param array $complete_form
   *   The complete form.
   *
   * @return array
   *   The element.
   *
   * @throws \Drupal\Component\Plugin\Exception\PluginException
   */
  public static function processSettings(array &$element, FormStateInterface $form_state, array &$complete_form = []) {
    $values = $element["#value"];

    $element["display"]['my_custom_field'] = [
      '#type' => 'textfield',
      '#title' => t('Custom field name'),
      '#description' => t('This is a custom field.'),
      '#default_value' => $values["display"]["my_custom_field"],
    ];

    return $element;
  }

}

At that point, I can see that field in the form:

If I save the form, it is captured into the config settings.

This seems right? After that, it will be a matter of using it for display. The idea here is I want a few additional settings authors can use to point at values, these values construct an API request to a remote database, and that database supplies the data to power the chart (vs using the other parts of the form).

@kevinquillen you could also do a form alter and add an #after_build callback. Then in the after build you can add your custom element. If your approach above is working as you would like then I think it should be fine. If you are interested in the #after_build callback approach there is an example at https://git.drupalcode.org/project/charts_highcharts_maps/-/blob/1.0.x/s... where the callback is added and https://git.drupalcode.org/project/charts_highcharts_maps/-/blob/1.0.x/s... for the callback implementation.

Automatically closed - issue fixed for 2 weeks with no activity.

@kevinquillen Did you find out how to use the value "some value here" for the display of the chart?
I managed to make the extra variable fields, but havo no idea at all how to import the values when making the chart output...

I wound up working with the client to design their data API (HTTP) to return data in Highcharts.js object form (ready to plug into Highcharts init()). That allowed me to write a small plugin and Storage entity (contrib module) that held enough data to make the HTTP call. The response was formatted with a field formatter that called Highcharts. This meant we did not need the Charts module at all, because we had no requirement to edit the data or other interface features of Charts module (settings were controlled remotely, colors axis etc).

Some of that is described here:

https://www.velir.com/ideas/2024/02/02/providing-enhanced-drupal-authori...