Account created on 22 October 2014, over 9 years ago
#

Merge Requests

Recent comments

πŸ‡³πŸ‡±Netherlands Ruuds

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

πŸ‡³πŸ‡±Netherlands Ruuds

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?

πŸ‡³πŸ‡±Netherlands Ruuds

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

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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).

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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

πŸ‡³πŸ‡±Netherlands Ruuds

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

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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".

πŸ‡³πŸ‡±Netherlands Ruuds

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

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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

πŸ‡³πŸ‡±Netherlands Ruuds

This is fixed in the 2.0.0 release.

πŸ‡³πŸ‡±Netherlands Ruuds

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?

πŸ‡³πŸ‡±Netherlands Ruuds

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

πŸ‡³πŸ‡±Netherlands Ruuds

Yes, please close it as a duplicate. Thanks!

πŸ‡³πŸ‡±Netherlands Ruuds

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?

πŸ‡³πŸ‡±Netherlands Ruuds

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 β†’

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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?

πŸ‡³πŸ‡±Netherlands Ruuds

Fixed in the 2.x releases.

πŸ‡³πŸ‡±Netherlands Ruuds

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

πŸ‡³πŸ‡±Netherlands Ruuds

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 β†’

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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.

πŸ‡³πŸ‡±Netherlands Ruuds

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.'));
      }
    }
  }
Production build https://api.contrib.social 0.62.1