Same here, but I've noticed this pattern (in case it helps):
- When I edit the node from /admin/content, I'm redirected back to /admin/content (with the message about a successful update), and everything works as expected - no issues.
- However, when I edit the node from the Translations UI (e.g., /node/85825/translations), I'm redirected back to the node page itself, and in this case, I encounter the error/issue mentioned above.
- Similarly, when I edit the node using the quick 'Edit' link (local tasks) from the node page itself, I also encounter the error.
drupal/layout_paragraphs issue maybe?
https://www.drupal.org/project/layout_paragraphs/issues/3401176
🐛
Allow to drag and drop nested paragraphs
Active
and here's the patch for 6.0.x
yes, exactly, can be reproduced when the range is in use.
Please find a patch attached
please find the patch attached
dejan0 → created an issue.
I had the same issue today, please find the patch attached
BEF = Better exposed filters (drupal/better_exposed_filters)
Links type = Links widget (outputs exposed filter values as HTML links)
This seems related, but I'm not entirely sure. Let me know if it would be better to open a new issue.
When I attempt to enable the Range Slider processor/widget on facets_exposed_filter, I encounter this error:
```
TypeError: Cannot access offset of type string on string in Drupal\facets\Entity\Facet->getWidgetInstance() (line 395 of modules/contrib/facets/src/Entity/Facet.php).
Drupal\facets_range_widget\Plugin\facets\processor\SliderProcessor->postQuery(Object) (Line: 144)
Drupal\facets_exposed_filters\Plugin\views\filter\FacetsFilter->valueForm(Array, Object) (Line: 969)
Drupal\views\Plugin\views\filter\FilterPluginBase->buildExposedForm(Array, Object) (Line: 103)
Drupal\views\Form\ViewsExposedForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 536)
Drupal\Core\Form\FormBuilder->retrieveForm('views_exposed_form', Object) (Line: 283)
Drupal\Core\Form\FormBuilder->buildForm('\Drupal\views\Form\ViewsExposedForm', Object) (Line: 134)
Drupal\views\Plugin\views\exposed_form\ExposedFormPluginBase->renderExposedForm() (Line: 115)
facets_exposed_filters_views_post_execute(Object)
call_user_func_array(Object, Array) (Line: 409)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}(Object, 'facets_exposed_filters') (Line: 388)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('views_post_execute', Object) (Line: 416)
Drupal\Core\Extension\ModuleHandler->invokeAll('views_post_execute', Array) (Line: 1450)
Drupal\views\ViewExecutable->execute(NULL) (Line: 1469)
Drupal\views\ViewExecutable->render() (Line: 131)
Drupal\views\Plugin\views\display\Block->execute() (Line: 1645)
Drupal\views\ViewExecutable->executeDisplay('block_2', Array) (Line: 81)
Drupal\views\Element\View::preRenderViewElement(Array) (Line: 61)
Drupal\views\Plugin\Block\ViewsBlock->build() (Line: 240)
Drupal\block_field\Plugin\Field\FieldFormatter\BlockFieldFormatter->preRender(Array)
...
```
I also noticed that everything in $_GET is also available in $view->getExposedInput(), at least in my cases. Could we simply replace $_GET with $view->getExposedInput()?
Please find an attached patch.
dejan0 → created an issue.
dejan0 → created an issue.
jjchinquist → credited dejan0 → .
please find the patch attached.
dejan0 → created an issue.
dejan0 → created an issue.
please find the patch attached
dejan0 → created an issue.
ah sorry, something was missing in the previous patch. Please find attached a fixed one
please find the patch attached
dejan0 → created an issue.
That solution doesn't work for us (Drupal 10.2) because all taxonomy terms on the website are showing a 404 Not Found page now.
Here's a new (temporary) solution
re-roll the patch against older drupal/sidekick version
please find the patch that removes most of those API calls
dejan0 → created an issue.
The small patch is available here. However, upon further consideration, I'm unsure if it's a good idea to allow this to be changed. Modules typically use it in hook_mail() to filter out their messages. Allowing other modules to change it in between might not be ideal. Let's see what others think.
dejan0 → created an issue.
Temporarily patch is here, it disables #limit_validation_errors. Not ideal, as validation errors now might be triggered during AJAX call (Sidekick button), and visible on the next page. And that might be just confusing for editors... But yes, at least Sidekick now works, and no more errors. Let's see if we can find a better solution here
dejan0 → created an issue.
@grienauer this is done now, 2.0.x branch is created and the 2.0.0-alpha1 version is released.
Feel free to mark old versions/branches as unsupported.
So, patch #9 worked correctly only for the first level of collection fields. But collection fields can be nested, so field_collection fields themselves can have another field_collection field as a child, and so on.
Please find attached an improved version of the previous patch, so it recursively lists all nested collection fields/values.
Again, you have to apply the https://www.drupal.org/node/1881670#comment-10473816 → patch before.
sorry, wrong patch file :( Please find the correct one attached.
please find the patch attached.
dejan0 → created an issue.
dejan0 → created an issue.
dejan0 → created an issue.
dejan0 → created an issue.
As said in the task description, If we add field storage definitions into thunder_update_8322.yml, the error is gone and new fields are created on the Basic page content type. Please find the patch attached