Drupal CMS

Problem/Motivation

Upon installation of this module on Drupal 10, I get the following error:

PHP Fatal error:  Declaration of Drupal\request_logger\Logger\RequestLogger::log($level, $message, array $context = []) must be compatible with Drupal\dblog\Logger\DbLog::log($level, Stringable|string $message, array $context = []): void in /app/web/modules/contrib/request_logger/src/Logger/RequestLogger.php on line 42

Steps to reproduce

* Install module on a Drupal 10 installation.

Proposed resolution

* Implement changes as documented in [#3284415]

Remaining tasks

* Implement changes as documented in [#3284415]

Add support for Drupal Gitlab CI.

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Fix warnings as reported by PHPCS.

The fix looks good at first glance, but please leave issues in needs review until the maintainer has actually committed the changes. I'll try to do this ASAP.

The consent mode issue was fixed in 2.0.5, so the latest patch stopped working. Original patch by @emanaton works fine.

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Fix CSPELL errors as reported in Gitlab pipeline.

Problem/Motivation

Currently in code, only image styles from the 'default' view mode are discovered:

$plugin = $this->entityTypeManager
  ->getStorage('entity_view_display')
  ->load($entity->getEntityTypeId() . '.' . $entity->bundle() . '.default')
  ->getRenderer($this->fieldDefinition->getName());

Proposed resolution

Discover image styles across all available view modes.

Remaining tasks

I'll create a merge request, please review.

RandalV created an issue. See original summary.

The module does not seem to use the hook_schema, but instead define the schema within hook_install. It would be best to convert this to a hook_schema to comply with Drupal best practices, and to allow Drupal to always have the most up to date schema definition via hook_schema.

Problem/Motivation

Upon installation, I'm getting the following error:

In Schema.php line 701:
The 'user_session_id' field specification does not define 'not null' as TRUE.

Still on Drupal 9.5.11 + MySQL version 5.7 + PHP 8.1, for what it's worth.

Steps to reproduce

Install scorm_field module.

Proposed resolution

Check if https://www.drupal.org/project/drupal/issues/2841291 is related.

Setting "user_session_id" property to 'not null' => TRUE, in scorm_field_install fixes it for me locally. Not sure if that's desired behaviour.

Remaining tasks

Investigate if changing 'not null' from FALSE to TRUE is ok or not, or find another solution.

Problem/Motivation

When trying to enable the scorm_field module on my existing site, I'm getting the folllowing error:

Configuration objects provided by <em class="placeholder">scorm_field</em> have unmet dependencies: <em class="placeholder">views.view.scorm_report_per_node (comment)</em>

This is probably caused by the fact that we do not have the comment module enabled on the site, at first glance.

Steps to reproduce

Install scorm_field module on a Drupal installation without comment module enabled.

Proposed resolution

Either move the default views config to config/optional, which will only nstall it if dependencies are met, or update the views config to remove the dependency on the comment module.

Fix issues as reported by Gitlab CI jobs

Merge request added.

Problem/Motivation

It's possible for the $settings['responsive_image_style'] value to be an empty string, meaning this check:

    if (isset($settings['responsive_image_style'])) {
      // Try to determine image style based on responsive image style.
      /** @var \Drupal\responsive_image\Entity\ResponsiveImageStyle $responsive_image_style */
      $responsive_image_style = ResponsiveImageStyle::load($settings['responsive_image_style']);

Doesn't work, and it tries to load an empty string as a ResponsiveImageStyle, throwing the following error:

Error: Call to a member function getImageStyleMappings() on null in Drupal\contextual_image_widget_crop\Plugin\Field\FieldWidget\ContextualImageCropMediaLibraryWidget->getImageStyles() (line 160 of ~/web/modules/contrib/contextual_image_widget_crop/src/Plugin/Field/FieldWidget/ContextualImageCropMediaLibraryWidget.php).

Steps to reproduce

Not entirely sure, I messed with the display settings a bit but couldn't find a stable way to reproduce. It does happen sometimes..

Proposed resolution

Change `isset` to `!empty`, which will cover all cases (null, empty string, non-existent, ..)

Remaining tasks

I'll create a MR that applies the fix.

RandalV created an issue. See original summary.

As a followup to #3441018: Add Gitlab CI support, fix the PHPCS en PHPStan issues, reported by Gitlab CI.

The problem seems to be that in file core/modules/field_ui/field_ui.module, The $form['field_storage']['subform'] doesn't seem to exist, in the function below. I don't know what the correct solution would be.. I'd say the form still needs to be alterable, and we still need to trigger the alter hooks on the bottom.

/**
 * Implements hook_form_FORM_ID_alter() for field_config_edit_form.
 */
function field_ui_form_field_config_edit_form_alter(&$form, FormStateInterface $form_state) {
  $field_config = $form_state->getFormObject()->getEntity();
  assert($field_config instanceof FieldConfigInterface);

  $form_id = 'field_storage_config_edit_form';
  $hook = 'form_' . $form_id;

  $field_storage_form = \Drupal::entityTypeManager()->getFormObject('field_storage_config', $form_state->getFormObject()->getOperation());
  $field_storage_form->setEntity($field_config->getFieldStorageDefinition());
  $subform_state = SubformState::createForSubform($form['field_storage']['subform'], $form, $form_state, $field_storage_form);

  \Drupal::moduleHandler()->alterDeprecated('Use hook_form_field_config_edit_form_alter() instead. See https://www.drupal.org/node/3386675.', $hook, $form['field_storage']['subform'], $subform_state, $form_id);
  \Drupal::theme()->alter($hook, $form['field_storage']['subform'], $subform_state, $form_id);
}

Hi frederiko_,

Certainly! Editing the "body"-field will lead you to a URL like: /admin/structure/types/manage/page/fields/node.page.body

Replace the last part (the field's machine name, in this case 'body'), with the locked field's machine name, for example: /admin/structure/types/manage/page/fields/node.page.layout_builder__layout

And it'll give you the WSOD.

Problem/Motivation

Trying to edit a locked field in the field UI throws a WSOD page. This shouldn't be the case, in my opinion at least a 403 should be thrown, or a page showing a clear message that this action is not permissible.

TypeError: Drupal\Core\Form\SubformState::createForSubform(): Argument #1 ($subform) must be of type array, null given, called in /var/web/vd17831/vib-conferences/release/web/core/modules/field_ui/field_ui.module on line 299 in Drupal\Core\Form\SubformState::createForSubform() (line 60 of core/lib/Drupal/Core/Form/SubformState.php).
field_ui_form_field_config_edit_form_alter(Array, Object, 'field_config_edit_form') (Line: 545)
Drupal\Core\Extension\ModuleHandler->alter('form', Array, Object, 'field_config_edit_form') (Line: 841)
Drupal\Core\Form\FormBuilder->prepareForm('field_config_edit_form', Array, Object) (Line: 284)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)

Steps to reproduce

• Start with a clean D10 and enable layout builder on a node type
• Edit the body field, and replace `body` in the URL with the layout field name: `layout_builder__layout`
• See the WSOD thrown

Proposed resolution

I have not had the time to look into a proper fix, but if I can I will create a MR.

Remaining tasks

Create MR.

User interface changes

Throw a 403, or show a clear message that this action is not permissible.

RandalV created an issue. See original summary.

Thanks to #9 and #16, I can confirm that adding the "wrap"-item even as the last item on the bar is a solid workaround until a permanent fix can be provided. It wraps the excessive items neatly on a second row (as was the behaviour in CKEditor4 if I'm not mistaken).

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Use Gitlab CI for automated testing on Drupal.org. See https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr...