🇿🇦South Africa @rudolfbyker

With which Drupal core version did you get that error?

Responded at https://www.drupal.org/project/schema_based_config_forms/issues/3518654#... 🌱 Compare with Automatic Configuration Form module Active

I'd be willing to contribute. Your approach makes sense. If implemented properly, it could form the API underlying both the `schema_based_config_forms` and `auto_config_form` modules, thereby reducing code duplication as much as possible.

@murz should be made aware of this issue, since he has been developing new features for auto_config_form recently.

Very good idea, once again.

• Note the failing validations at https://git.drupalcode.org/issue/auto_config_form-3519202/-/jobs/4967535
• Tests, please :) See https://www.drupal.org/project/auto_config_form/issues/3515438#comment-1... ✨ Adding descriptions to the form fields from schema Active . I don't think that functional tests (a.k.a. browser tests) will be necessary, since we can trust the Drupal Form API to be well tested already. Unless we want to test our usage of the Drupal Form API, then it would be good to actually check in the browser that the client-side validation is working. I'm in two minds about this, because Drupal does not warn us if we include unused stuff in the form definition, which might lead to a situation where we think we are implementing client-side validation, but in fact are not.

I did not know about #config_target. Thanks for the improvement!

Before I merge, we will need unit tests for this, as described here: https://www.drupal.org/project/auto_config_form/issues/3515438#comment-1... ✨ Adding descriptions to the form fields from schema Active

I like this. Just two comments:

• See failing code sniffer validations at https://git.drupalcode.org/issue/auto_config_form-3519037/-/jobs/4967568
• We need unit tests or kernel tests, as described here https://www.drupal.org/project/auto_config_form/issues/3515438#comment-1... ✨ Adding descriptions to the form fields from schema Active

OK, I can see how using "label" for the title was not ideal. We could make "title" and "description" required in the next major version of this module.

We should add tests before merging this. Would you be able to do that? If not, I'll do it, but I can't guarantee a time frame. Luckily, I already set up CI for this module earlier this month!

It's probably best to use unit tests with a mocked ContainerInterface, or a kernel test. Then create a class like TestAutoConfigFormBase, instantiate it, and call buildForm. Do this with various combinations of config schemas, and assert that the form looks as expected. We should include a test that ensures backward compatibility with the old way of doing things, where "label" is used instead of "title". We should clearly mark those tests, saying that we'll remove them in the next major version.

If this issue is left open (status of Active, Needs review, Needs work or Reviewed and tested by the community) and the "ProjectUpdateBotD10" tag is left on this issue, new patches will be posted periodically if new deprecation fixes are needed.

By changing this to Closed, you prevent the bot from posting future fixes.

If this issue is left open (status of Active, Needs review, Needs work or Reviewed and tested by the community) and the "ProjectUpdateBotD10" tag is left on this issue, new patches will be posted periodically if new deprecation fixes are needed.

Very good idea. Thanks for the contribution. I will try to review this next week, if your MR is ready.

Thanks for the MR. I will try to review it next week.

In the mean time, you still have to answer my question from #4:

Currently, this module uses 'title' for the short title of the form element, and 'label' as the longer description below it. Why does that not suffice?

I'm not sure if I should answer at https://www.drupal.org/project/auto_config_form/issues/3518655 🌱 Compare with Schema Based Config Forms module Active or at https://www.drupal.org/project/schema_based_config_forms/issues/3518654 🌱 Compare with Automatic Configuration Form module Active , so I'll do both. :)

I'm more than happy to collaborate. Mine is older, but his looks more feature-rich. I think my module's name (Automatic Configuration Form) is more discoverable, and his module's name (Schema Based Config Forms) is more technically correct (although it should be Schema-based Config Forms to be grammatically correct). So if we merge, I'm not sure under which name we should continue.

Comparison of usage:

• https://www.drupal.org/project/usage/auto_config_form →
• https://www.drupal.org/project/usage/schema_based_config_forms →

I'm not sure if I should answer at https://www.drupal.org/project/auto_config_form/issues/3518655 🌱 Compare with Schema Based Config Forms module Active or at https://www.drupal.org/project/schema_based_config_forms/issues/3518654 🌱 Compare with Automatic Configuration Form module Active , so I'll do both. :)

I'm more than happy to collaborate. Mine is older, but his looks more feature-rich. I think my module's name (Automatic Configuration Form) is more discoverable, and his module's name (Schema Based Config Forms) is more technically correct (although it should be Schema-based Config Forms to be grammatically correct). So if we merge, I'm not sure under which name we should continue.

Comparison of usage:

• https://www.drupal.org/project/usage/auto_config_form →
• https://www.drupal.org/project/usage/schema_based_config_forms →

A few more thoughts:

• I just noticed that "title" is also not part of the schema, at least not according to my IDE. Yet, it works. So in theory, I guess we could add more properties.
• Currently, this module uses 'title' for the short title of the form element, and 'label' as the longer description below it. Why does that not suffice?
• In your class that extends AutoConfigFormBase, you can override any of the protected or public methods you wish, and either replace them with your own implementation, or call the parent implementation and modify the result before returning. One that might be of special interest to you is protected function getCommonElementAttributes.

I'm not sure if this is possible without changing Drupal core. If you would add custom properties not listed in https://www.drupal.org/docs/drupal-apis/configuration-api/configuration-... → to your schema, it will not be valid according to Drupal core.

A related thing that pathauto does, which may or may not be a separate issue from this one: It allows you to specify a list of stopwords, like 'a', 'the', etc. to skip when generating the ID.

Another use case is when I have "soft hyphens" https://symbl.cc/en/00AD/ in my headings. I would like them to be skipped instead of turned into real hyphens. Soft hyphens are nice for supporting long words on small screens, especially in headings, which tend to have big fonts.

rudolfbyker → created an issue.

I also need this. Alternate solution: Use an ID like `node-x-footnote-y` where x is the node ID and y is the footnote's ordinal or value.

rudolfbyker → created an issue.

rudolfbyker → created an issue.

Point to new docs about GitLab CI, because the instructions on this page are not possible to follow since the changes from https://www.drupal.org/project/project_issue_file_test/issues/3415931 📌 Remove “Automated testing” tab when a project has no DrupalCI testing Active were implemented.

Even with this patch applied, I still get this error after upgrading to version 2.0.15 when visiting admin/structure/taxonomy_manager/voc/foo

Warning: file_get_contents(libraries/jquery.fancytree/dist/jquery.fancytree.min.js): Failed to open stream: No such file or directory in Drupal\Core\Asset\JsCollectionOptimizerLazy->optimizeGroup() (line 175 of core/lib/Drupal/Core/Asset/JsCollectionOptimizerLazy.php).

My knowledge of the search_api code base is VERY limited. I simply stumbled upon line 221 of FieldsHelper::extractFieldValues while stepping through the code with xdebug to where my field values are getting lost. I'm not in a position to make good suggestions on the way forward with the code. I just wanted to show a sensible use case that would be solved by this issue.

@Lendude those issues look similar, indeed, but they are marked as fixed, while I can still reproduce this issue by importing the attached `views.view.test.yml` file into a fresh Drupal 10.3.2 instance.

@akhil babu you are correct. With the latest Drupal version, the "Date format" is respected, but the whole thing is still wrapped in HTML. I'll update the title and description of this issue.

Partial workaround: Enable "Strip HTML tags" and "Remove whitespace" under "Rewrite results" when configuring the views field. The only problem is that it's still a string instead of an int when using "U" as the "Date format".

Looking for co-maintainer or sponsorship.

Looking for co-maintainer or sponsorship.

Here is an example from my use case: I have a custom Drupal FieldType with a few different properties, say xmin, xmax, ymin, ymax. None of these are the "main" property. They work together to describe a bounding box. I want to create a custom BBox or RPT data type (See https://solr.apache.org/guide/solr/latest/query-guide/spatial-search.html ). This is how far I got:

Set up the data type:

namespace Drupal\vv\Plugin\search_api\data_type;

use Drupal\search_api\Plugin\search_api\data_type\StringDataType;

/**
 * Provides a BBox / RPT data type.
 *
 * @SearchApiDataType(
 *   id = "vv_solr_bbox",
 *   label = @Translation("BBox"),
 *   description = @Translation("A bounding box field. Useful for finding overlapping ranges in 2 dimensions."),
 *   fallback_type = "string",
 *   prefix = "bbox"
 * )
 */
class BBoxDataType extends StringDataType {

  /**
   * {@inheritdoc}
   */
  public function getValue($value) {
    // @todo I would expect to get the entire field item here.
    // $xmin = (int) $value->get("xmin")->value;
    // etc...
    return "ENVELOPE({$xmin}, {$xmax}, {$ymax}, {$ymin})"
  }

}

Set up the data type mapping:

namespace Drupal\vv\EventSubscriber;

use Drupal\search_api\Event\MappingFieldTypesEvent;
use Drupal\search_api\Event\SearchApiEvents;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

/**
 * Subscribe to events from the `search_api` module.
 */
class SearchApiEventSubscriber implements EventSubscriberInterface {

  /**
   * {@inheritDoc}
   */
  public static function getSubscribedEvents(): array {
    return [SearchApiEvents::MAPPING_FIELD_TYPES => 'onMappingFieldTypes'];
  }

  /**
   * Handle the `search_api.mapping_field_types` event.
   */
  public function onMappingFieldTypes(MappingFieldTypesEvent $event) {
    $mapping = &$event->getFieldTypeMapping();
    $mapping['field_item:my_bbox_field_type'] = 'vv_solr_bbox';
  }

}

Search API config at search_api.index.commentary_comments.yml:

field_settings:
  my_bbox:
    label: BBox example
    datasource_id: 'entity:node'
    property_path: field_my_bbox
    type: vv_solr_bbox
    dependencies:
      config:
        - field.storage.node.my_bbox_field_type

Solr config in schema_extra_types.xml:

<fieldType name="bbox" class="solr.SpatialRecursivePrefixTreeFieldType" geo="false" distanceUnits="kilometers" worldBounds="ENVELOPE(0,4800,1,0)" />

Solr config in schema_extra_fields.xml:

<dynamicField name="bboxs_*" type="bbox" indexed="true" stored="true" multiValued="false" />
<dynamicField name="bboxm_*" type="bbox" indexed="true" stored="true" multiValued="true" />

But the problem is that, in FieldsHelper::extractFieldValues on line 221, it returns an empty array when there is no main property:

    // Process complex data types.
    if ($definition instanceof ComplexDataDefinitionInterface) {
      $main_property_name = $definition->getMainPropertyName();
      $data_properties = $data->getProperties(TRUE);
      if (isset($data_properties[$main_property_name])) {
        return $this->extractFieldValues($data_properties[$main_property_name]);
      }
      return []; // line 221
    }

Here are some examples and resources:

• An example from this module's test cases: https://git.drupalcode.org/project/search_api/-/tree/8.x-1.x/tests/modul...
• Tutorial about hooks and events: https://www.specbee.com/blogs/hooks-vs-events-in-drupal-making-informed-...
• Replacing a hook with an event: https://www.drupal.org/docs/8/modules/search-api-solr/search-api-solr-ho... →

rudolfbyker → made their first commit to this issue’s fork.

rudolfbyker → made their first commit to this issue’s fork.

rudolfbyker → made their first commit to this issue’s fork.

rudolfbyker → made their first commit to this issue’s fork.

rudolfbyker → created an issue.

Duplicate of https://www.drupal.org/project/bulksms/issues/3016603 →

I ended up doing something completely different, and standalone: https://www.drupal.org/project/oai_pmh_harvester →

Due to lack of documentation, I ended up writing https://www.drupal.org/project/oai_pmh_harvester → without depending on this module.

@fishfree I'm willing to work on this if you can find a sponsor for it. I think it will take 3 work days. Alternatively, you may submit a merge request, and I'll review it.

I think this patch needs to be re-rolled for version 3.5.

v3 clearly states that it is supposed to be compatible with Drupal 10: https://www.drupal.org/project/geolocation/releases/8.x-3.12 →

v4 is still in alpha, so I can't use that on some projects.

Thanks. I merged your patch, with one small fix to the punctuation.

Thanks!

If you think this module needs a help hook, feel free to write one and submit a merge request. Otherwise, please use the "Closed" status instead of "Postponed".

Thanks for your time! I hope this module is helpful.

Done!

I'm also running into this issue. Thanks for the patches.

I think two more things are needed here:

1. Unit tests, so that this does not regress again.
2. A way to clear the secret in the UI when editing the consumer. Currently, if you leave the field empty, it just means "don't update".

rudolfbyker → created an issue.

rudolfbyker → created an issue.

This is not possible yet. It will take considerable development and design to get this working. I don't have the time, sorry.

Is this working for you @tikaszvince ?

Thanks for the reproduction. That saved me a lot of time.

I think since the used "caseyamcl/phpoaipmh" packages requires guzzlehttp/guzzle you do not need to lock this requirement at all.

Almost correct, but not quite. If oai_pmh_harvester used guzzle directly, we would need to keep it, even if it's provided by caseyamcl/phpoaipmh. But it looks like we are not using guzzle directly, so your patch is good.

Hi, please provide steps to reproduce the problem, rather than simply pasting an error message. I need more context to be able to help you with this.

Ah, I see it has nothing to do with the PHP version. I will release version 2.0.2 with your fix.

Thanks for the patch. Which PHP version are / were you using?