🇧🇪Belgium @seutje

Antwerp
Account created on 23 March 2008, almost 17 years ago
#

Recent comments

🇧🇪Belgium seutje Antwerp

I'm having the same issue: updating past RC10 makes submit buttons on node edit forms disappear. Upon closer inspection, I noticed that at the end of GinContentFormHelper->formAlter(), $form['actions] is still populated, but in node-edit-form.html.twig, form.actions is NULL.
I didn't experience this issue with other projects I updated to this version, so I'm fairly certain it's some weird interaction with another module.
I'm just going to pin it to RC10 for this project for now, I'll try to find some more time to look into what's going on.

🇧🇪Belgium seutje Antwerp

Turns out this was caused by having Shield enabled on the environment and not excluding the webhook path from being password protected... derp!

Still kinda weird it didn't just have an empty value in the database, but there just wasn't a row for the value at all...

🇧🇪Belgium seutje Antwerp

Sorry, I really need to learn how to make merge requests... But this isn't meant as a permanent solution, it just massages the data in the viewElements method as a temporary workaround. Ideally, we should change the data structure in the display formatter settings, but I just don't know how to create a update hook to load & update all current instances of the display formatter.
I've been looking for a good example of such an update hook for the past couple hours, but I can't find any :(

🇧🇪Belgium seutje Antwerp

It suddenly dawned on me that I had done a "git add ." after putting the first patch in the same folder, adding the entire first patch to the second...

Remember kids, don't write patches until you've had your coffee, or at least manually review the contents of what you're uploading.

Attached patch should be correct, also moves the "use strict" inside the closure/IIFE/whatever we're calling it nowadays.

🇧🇪Belgium seutje Antwerp

Attached patch moves everything within the closure, declares window as a passed variable and then attached the variables to the window object that way for both gtag.js and gtm.js. It also adds "use strict" at the top of both and removes the exclusion from preprocessing.
If there is a different reason they are excluded from preprocessing, let me know and I'll remove that part from the patch.

🇧🇪Belgium seutje Antwerp

Oh yeah, I didn't mean it as a blocker, I was just trying to justify my arguably poor implementation 😅
This is already a great improvement and I don't see anything that would warrant blocking it.

🇧🇪Belgium seutje Antwerp

I first looked into using filter_var, but the main reason I used a simple str_starts_with is because I couldn't get filter_var to ignore the protocol, but I guess slapping the protocol in front and then matching is a much better approach.
The current approach does however fail with unicode TLDs like Brahmic, Cyrillic, Arabic, Hebrew, Chinese, Greek, etc. (see https://onlinephp.io/c/7d21f extracted from https://en.wikipedia.org/wiki/Internationalized_domain_name), but I guess those URLs are unlikely to start with "www" anyway.

🇧🇪Belgium seutje Antwerp

Attached patch provides simple matcher called "External" that does a str_starts_with($string, 'www') check and suggests adding "https://"

🇧🇪Belgium seutje Antwerp

I also ran into this issue. The MR linked above fixed it for 9.x, but failed to apply when I upgraded to 10.x, so I rerolled it, but I changed it to fall back on $this->options['content']

Unfortunately, I have no clue what the cause is, so I cannot provide any more information... I have a strong suspicion it's being caused by a control module, as I only experience this issue with 1 specific project.

🇧🇪Belgium seutje Antwerp

Attached patch does what is suggested in #15 and reverts the code from issue 3015323.

Obviously this is not a permanent solution, but it allows our editors to do their work. I'm not knowledgable on the inner working of entity handling to know what other effects this could have.

🇧🇪Belgium seutje Antwerp

Patch in #5 doesn't apply as it was created within a project instead of from the module root (references a/modules/contrib/node_keep/node_keep.module instead of a/node_keep.module).

Attached patch fixes that and also removes the use Drupal\node\NodeTypeInterface; statement.

It basically just reverts commit a41352e3, so it's not meant to be a permanent solution, just a stop-gap until this issue can be resolved.

🇧🇪Belgium seutje Antwerp

Patch in #7 still applies cleanly and does the trick.

🇧🇪Belgium seutje Antwerp

I think you are correct and I misinterpreted how tags work. I'll look into it as soon as I find some time.

🇧🇪Belgium seutje Antwerp

When I try to set the Word Document engine to Word Docx and submit the settings form, I am greeted with the following error on Drupal 9.5.4 on PHP 8.0.27:

TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() (line 297 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).
Drupal\Core\Entity\EntityStorageBase->load(Array) (Line: 262)
Drupal\entity_print\Form\SettingsForm->loadConfigEntity(Array) (Line: 214)
Drupal\entity_print\Form\SettingsForm->validateForm(Array, Object)
call_user_func_array(Array, Array) (Line: 82)
Drupal\Core\Form\FormValidator->executeValidateHandlers(Array, Object) (Line: 275)
Drupal\Core\Form\FormValidator->doValidateForm(Array, Object, 'entity_print_admin_settings_form') (Line: 118)
Drupal\Core\Form\FormValidator->validateForm('entity_print_admin_settings_form', Array, Object) (Line: 591)
Drupal\Core\Form\FormBuilder->processForm('entity_print_admin_settings_form', Array, Object) (Line: 323)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 169)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 81)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 718)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I assume there's something missing in entity_print.schema.yml.

🇧🇪Belgium seutje Antwerp

I second this.
We had /user/reset/* in the list of paths (reversing the condition), but after updating from 3.0.2 => 3.0.4, the config was changed and that path was removed somehow, while retaining other paths.
Having this in the list of protected routes would have prevented that altogether.

🇧🇪Belgium seutje Antwerp

Yes, you are correct.

I noticed the issue when using a views_simple_math_field to multiply a price per piece with an amount and then create a sum of this multiplication. The user can create products, which have a price per piece and they can then reference these products in an order, adding an amount. I created an overview table to see the total price per order.
The issue occurs in views_aggregator/src/Plugin/views/style/Table.php on line 653, where !in_array($field_handler->getProvider(), ['views', 'webform_views']) evaluates to TRUE. So it seems like it assumes that any field not provided by Views or Webform Views should be rendered before being passed to vap_num, even when the $rendered parameter is set to FALSE, which would seem like a bit of a wild assumption.

🇧🇪Belgium seutje Antwerp

Created an issue for the problem I raised in my previous comment about field values being ignored when they use a pattern based conditional on a multi-select. See https://www.drupal.org/project/webform/issues/3337966 🐛 When multiple fields have a conditional pattern on a multi select, only the last is considered valid Closed: cannot reproduce

🇧🇪Belgium seutje Antwerp

Using pattern as the condition instead of value seems to work for me, but when using "Clear value(s) when hidden" and having multiple elements' visibility depend on different value, only the last one will be included in the submission result. When disabling "Clear value(s) when hidden", it is included in the submission result, but still not included in the [webform_submission:values] token.

Production build 0.71.5 2024