🇳🇱Netherlands @Ruuds

I've updated the fork with the code of #30.

The \Symfony\Component\HttpFoundation\Response instance is already passed to the alter hook. \Drupal\Core\Cache\CacheableResponse is a subclass of this, so you should be able to alter the tags and contexts if applicable.

As an alternative to the hook_jsonapi_response_alter hook, the \Drupal\jsonapi_response_alter\Event\JsonApiResponseAlterEvent event can be used to alter the JSON:API response data.

Please note that this is implemented in 2.x.

Fixed in 2.x.

I've implemented the suggestion of @larowlan and also added a test for it. If the private stream wrapper is not available a warning is shown it is advised to store file uploads for contact forms as private files.

Great suggestion, looks good to me.

Please try updating to 1.1.1 and let me know if that works.

Please try updating to 1.1.1 and let me know if that works.

Thanks for the feedback. The placeholder is fixed, and i've enabled the gitlab-ci pipeline to catch any other errors in the future.

The test failures are not related. The tests are broken anyway.

Ruuds → created an issue.

Well, that's correct as for Drupal 10. Drupal 9 requires Guzzle 6 or 7 (see https://www.drupal.org/node/3268032 → ), and the module still supports ^9 as defined in salesforce.info.yml.

Yes, Drupal 9 is EOL, but I think:
1. This fix should be included to keep supporting ^9
2. The salesforce module's major version number should be increased and drop support for ^9.

Ruuds → created an issue.

Thanks @gapple for clarifying this. I've added it to the README and project summary.

I don't think anything needs to be changed? The mentioned class (Drupal\Core\Render\Element\FormElementBase) by the needs-review-queue-bot does not exist and FormElement is not marked as deprecated?

The patch in #44 allows anonymous users to edit menus (/admin/structure/menu/manage/*), so beware of that!

So as the issue only seems to occur when grouping elements using the field_group module, do we really want to rebuild the logic that field_group uses for grouping elements into a core test? Creating a dependency to the field_group module for a specific core test doe also not feel right.

I've created a MR which contains a test which checks if all FormElement plugins defined by core have a #process callback to processGroup, which solves the problem. Running that test, I discovered additional FormElements which also did not have the #process callback.

Probably work in this MR will be removed again when https://www.drupal.org/project/drupal/issues/2190333 📌 Make #group FAPI / render feature work on all form/render #types out of the box Needs work gets fixed.

Thanks @AstonVictor for reopening. I've added a patch to fix the '@context_user' value in the cell (as i was not able to push to the feature branch).

From a technical point of view I would agree. But it causes confusion from an user's point of view. When managing contact forms, the contact_form list builder is the first screen an user visits. It is not clear that the a@a.com recipient is overridden by a contact_email entity, and a client complained that contact form submissions were not send to a@a.com, so we created this patch.

If we don't want to show the contact_email entity's recipients, we should at least hide the a@a.com e-mail address to solve this confusion.

Sorry...

Ruuds → created an issue.

The second remove button is probaby added by Drupal itself. I've added an afterBuild method which removes the button added by Drupal, so the one added in the widget is left to be used. See the MR.

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

I've changed @BetoAveiga 's patch to make it work with 2.0.0-beta12

I've added a check in address_update_9201 which does not try to add the field again if it already exists. @rymcveigh this will probably fix your error.

That would be the best solution, but as there is already a released version which only updates the tables partially, an additional update hook would be the most appropriate in my opinion. If really needed, I can try to extract a minimal db dump which contains the problem.

I also got this issue when upgrading from 1.x to 2.x. I found there was a field storage definition (field.storage.profile.address) which indeed didn't get the address_line3 field after the updated.

I've created a MR which contains a new update hook which checks which field storage definitions are missing the address_line3 field, and adds it when needed.

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

Thanks!

Thanks, these changes have been made. See https://git.drupalcode.org/project/csp_google/-/commit/408329c10ac5bf8fb...

Thanks for your request. I'm new to the security advisory process, so i've opted in for that. I'll create an covered release when all their findings are solved (if any).

For now i've created an uncovered release.

Ruuds → created an issue.

The dependency on Drupal\facets\Event\UrlCreated still exists in 1.6 so i think the composer requirement should still be changed to "^2 || ^3".

Ruuds → created an issue.

See the attached patch for a version which works with the 2.x branch.

While the batch process in our client's Drupal site is still running great with the provided patch, I think the F5 WAF has it wrong:

- RFC2616 says a Content-Length >= 0 is valid: https://datatracker.ietf.org/doc/html/rfc2616#section-14.13, and t
- The F5 docs states that this behavior differs from what the RFC says: https://my.f5.com/manage/s/article/K10280: "Note: While RFC 2616 section 14.13 states that Content-Length can be equal to or greater than zero, the BIG-IP ASM considers a value of zero to be a violation."

Although adding this patch to drupal core would save me some lines in my composer.json file, in hindsight I think this change should not be added to Drupal core, as it clearly is a 'misinterpretation' of the RFC by the F5 waf, and polluting the drupal core codebase with exceptions for every piece of software out there should not be the way to go.

So I think this issue should be marked as Closed/won't fix.

Thanks, that would do the trick indeed! Creating a new release shortly.

Thanks! Fixed in 2.0.1.

Fixed in 2.0.0.

Fixed in 2.0.0.

This is fixed in the 2.0.0 release.

Thanks!

Thanks for reporting. While this patch fixes the issue for Drupal 10+ with PHP 8.x, would it possibly break the module on Drupal 9, as the definition of getSubscribedEvents() doesn't include a return parameter there?

No, doesn't seem to be applied looking at the source code.

Yes, please close it as a duplicate. Thanks!

When rewriting my patch i noticed the regex was already changed. https://www.drupal.org/project/drupal/issues/3317745 🐛 CSS Aggregation should not rewrite # url Fixed has solved the same issue, so I guess this can be marked as a duplicate?

If only 'checkpoint 1' is shown, it means that the block_button_modal is not enabled for the webform block. As it works correctly in my situation i am wondering if you are using any additional block-related modules? It seems, for example, that the block_class module prevented saving of third party settings (which is used to determine if block_button_modal is enabled or no) in an older version. See https://www.drupal.org/project/block_class/issues/3299925 →

If that's the case, the block_button_modal_block_view_alter or the template_preprocess_block_button_modal_block method probably doesn't get called.

As i cannot reproduce the issue, maybe you can help me out identifying the issue. If you replace the contents of the block_button_modal.module file with https://gist.github.com/ruuds/5163d887431862d83f9f6d4d3a592939 (changed lines are 32, 36 and 56), what output do you get?

The lines

block_button_modal checkpoint 1
block_button_modal checkpoint 2
block_button_modal checkpoint 3

should appear somewhere on your page.

Looking at this, i was thinking... Wouldn't it be enough to just check if \Drupal\jsonapi\Routing::isJsonApiRequest(...) is TRUE?

Jsonapi_menu_items also implements the requirements for isJsonApiRequest to return TRUE. And this would also open up support for other related JSON:API requests.

I had the same issue on 9.5.8. A view had two page displays with different urls:

```
/dashboard-my-applications
/dashboard/my-applications/applications
```

`/dashboard-my-applications` is presented as `/` in the views overview, but seemed to be correctly configured when editing the view. As these page displays were completely identical, removing the first one solved the issue for me.

It seems to work in the project we built this module for. Do you get any specific javascript errors in your browser's inspector console?

Fixed in the 2.x releases.

Thanks!

Updated patch which checks if a grouped block is actually available, which suppresses a php warning

I got here after some googling and didn't find an usable solution. To solve this, I created the Block Button Modal module which shows a button instead of a block, which can be used as a solution for this issue.

See https://www.drupal.org/project/block_button_modal →

Ruuds → created an issue.

Ruuds → created an issue.

Ruuds → created an issue.

Initially, the project had three active languages (Dutch, Flemish and French). Two of these were removed (Flemish and French), but the dropdown language was left in place because another new language will be added instead soon.

The $links variable is only set when if (count($languages) > 1) so when the module is used when only one language is present, count($links) will always result in this warning.

Ruuds → created an issue.

Ruuds → created an issue.

Update: The _triggering_element_name contains extra text when the constraint is validated on a field which is added to a paragraph type. In that case,

if ($triggering_element_name === $field_name . '-' . $index . '-media-library-remove-button') {

can be replaced with

if (stripos($triggering_element_name, $field_name . '-' . $index . '-media-library-remove-button') === 0) {

which will possibly lead to other issues, but works in my case.

I also encountered this issue. Somehow the ConstraintValidator should be aware of which media items are removed. For now I implemented a dirty solution which checks if the remove button of a specific media item is clicked and skips the validation for that media item:

public function validate($value, Constraint $constraint) {
    $field_name = $this->context->getPropertyName();
    $triggering_element_name = $this->requestStack->getCurrentRequest()
      ->get('_triggering_element_name');

    foreach ($value as $index => $item) {
      $media = $item->entity;
      if (!$media instanceof MediaInterface) {
        continue;
      }

      if ($triggering_element_name === $field_name . '-' . $index . '-media-library-remove-button') {
        // Remove button was clicked, so skip validation.
        continue;
      }

      if (!$this->canUse($media, $value->getEntity())) {
        $this->context->addViolation($this->t('This media item is already being used.'));
      }
    }
  }

Ruuds → created an issue.