🇻🇳Vietnam @phthlaap

The HOOK_field_widget_form_alter has been deprecated, I think the issue summary needs update.

function hook_field_widget_single_element_form_alter(&$element, \Drupal\Core\Form\FormStateInterface $form_state, $context) {
  $field_definition = $context['items']->getFieldDefinition();
  if ($field_definition->getType() == 'decimal') {
    $element['value']['#step'] = 'any';
  }
}

https://www.drupal.org/node/3180429 →

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

phthlaap → changed the visibility of the branch 3294700-warning-undefined-array-key-type to hidden.

I applied a patch and added a test case for this issue.

This issue happened on my end; this is the view I tested: test_expose_date_filter.yml → or please see my screenshot →

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

phthlaap → changed the visibility of the branch 3357973-grouped-exposed-taxonomy to active.

phthlaap → changed the visibility of the branch 3357973-grouped-exposed-taxonomy to hidden.

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

@alexpott the core.extension configuration is validated in core/lib/Drupal/Core/EventSubscriber/ConfigImportSubscriber.php:93. I think we no need to validate again.

    $config_importer = $event->getConfigImporter();
    if ($config_importer->getStorageComparer()->getSourceStorage()->exists('core.extension')) {
      $this->validateModules($config_importer);
      $this->validateThemes($config_importer);
      $this->validateDependencies($config_importer);
    }
    else {
      $config_importer->logError($this->t('The core.extension configuration does not exist.'));
    }

It also have test cases to cover: core/tests/Drupal/KernelTests/Core/Config/ConfigImporterTest.php::testMissingCoreExtension

But even when it is validated I think we also need fix the core/modules/field/field.module:324 to prevent the TypeError message when access the page /admin/config/development/configuration

As comment #40 I has explained, the variable name $states is no longer a jQuery instance. but, it will be identical to the state variable defined at the top of the file, so I named it element.

@smustgrave

The merge request above are already using same solution once library and also have a tests https://git.drupalcode.org/project/drupal/-/merge_requests/7045/diffs

#27 It will impact the import configuration form when there are no changes in the core extension.

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

I updated the issue summary to the correct format.

I created a merge request and added tests.

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

phthlaap → created an issue.

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

As suggestion of @nod_ , I use Once library to fix the issue. I think it is better.
I also changed the variable name $states because it is no longer a jQuery instance. but, it will be identical to the state variable defined at the top of the file, so I named it element.

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

@smustgrave just remove the file core.extension.yml instead of all .yml files

phthlaap → changed the visibility of the branch 3386191-states-not-working-drupaljs to hidden.

phthlaap → changed the visibility of the branch 3385934-configuration-synchronization-page to hidden.

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

As @alexpott suggestion, I moved code to parent class but I dont know how to fix the test failed.

The approach in patch #26 will affect some tests because I believe Ajax should reattach on form submission once again.

Tested without addBack(tagsSupportDisable), the issue wasn't fixed. This change has been applied since patch #31.

phthlaap → changed the visibility of the branch 3386191-9x-states-not-working to hidden.

phthlaap → changed the visibility of the branch 3386191-states-not-working to active.

phthlaap → changed the visibility of the branch 3386191-states-not-working to hidden.

I think the issue didn't happen on 11.x, but I also converted patch to git branch for 11.x.
\Drupal\Tests\datetime\Kernel\Views\FilterDateTest::testDateOffsets run without the fix actually passes, the test didn't cover the issue.

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

I cannot reproduce the issue.

https://youtu.be/sXFTgSwb-Gg

Can you please help provide sample code in any module?
Thanks.

Resolved and added more tests to cover form with ajax.

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

I resolved all items in comment #23. Please help to review.

Can someone suggest the steps to remove it?

Tests already there. Can you help to suggest what is the upgrade path?

This issue happen with submit button

$form['actions']['submit'] = [ 
  '#type' => 'submit',
  '#value' => $this->t('Submit'),
  '#states' => [
    'disabled' => [':input[name="allow_overwrite"]' => ['checked' => FALSE]],
  ],  
];

phthlaap → changed the visibility of the branch 3354998-states-disable-elements to hidden.

I've created a merge request for version 11.x and added test coverage.

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

Added tests and fix some issues of config.

As I mentioned in comment #23, the Json API module has a test to ensure that a file with zero bytes can be uploaded successfully. That test conflicts with this feature request, and I am unsure about what steps to take next.

\Drupal\Tests\jsonapi\Functional\FileUploadTest::testFileUploadZeroByteFile

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

Hi @Wim Leers, Thanks for your help to review.

If the arguments has a array item inside it will show the notice.

$variables['arguments'] = ['foo_bar', ['sample']];
var_dump(preg_replace('/[^a-zA-Z0-9]/', '_', $variables['arguments']));

It seems to conflict with a test in the JSONAPI module. They expected the zero-byte file to upload successfully.

\Drupal\Tests\jsonapi\Functional\FileUploadTest::testFileUploadZeroByteFile

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

Fixed the issue on 11x branch and create merge request. Added a tests.