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.
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...
seutje → created an issue.
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 :(
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.
Fix typo.
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.
seutje → created an issue.
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.
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.
Attached patch provides simple matcher called "External" that does a str_starts_with($string, 'www') check and suggests adding "https://"
seutje → created an issue.
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.
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.
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.
Patch in #7 still applies cleanly and does the trick.
I think you are correct and I misinterpreted how tags work. I'll look into it as soon as I find some time.
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.
Any news on this?
Fixes the issue for me.
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.
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.
Sure.
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
seutje → created an issue.
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.