Not supporting old PHP/Drupal versions is fully fine as long as the composer.json clearly defines this limits.
The missing requirements is what made me open this issue.
cweiske → created an issue.
We have the same problem with display_field_copy 2.1.0 on Drupal 9.4.4
We have a paragraph type that has no fields for editors to modify, and this shows up as empty - making it impossible for editors to see what type of element it is.
Patch #5 applies (with a small change) on 7.0.0alpha4 and finally allows me to limit the number of shards to 1, which I require for better scoring (TF-IDF).
I had a hook_views_pre_view function that overrode $view->display_handler options. One of the options I changed did not exist, so the error was indeed helpful that something was wrong with my code.
function mymod_view_pre_view_article_filter(ViewExecutable $view) {
$defaults = [...];
$filters = $view->display_handler->getOption('filters');
$filters['field_tags_target_id']['value'] = $defaults['tags'];
$filters['query']['value'] = $defaults['query']; //this "query" filter did not exist
}
I am indeed using ElasticSearch 7, but the completion type is available in both ES7 and ES8.
A new index field type "completion" would be necessary:
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/search-sugg...
{
"mappings": {
"properties": {
"suggest": {
"type": "completion"
},
[...]It would be nice if:
- A message would be shown e.g. "indexing is running in the background"
- There was an option to wait until the indexing task is finished instead of exiting after the workers have been started
Patch #10 works fine with 8.x-1.25 on drupal 9.4.4.
Patch available.
It took quite some time for me to figure out that "Dynamic local task generation" only generates static tasks, and does not allow to influence the tasks on a request basis. This should be clarified.
If you just need the value of a URL child element in the field group template, access it via
{{ element.field_detail_url[0]['#url'].toString() }}
The "element" variable is available in the templates, even if that is not written down in the field-group-html-element.html.twig comments.
Patch #55 works on paragraphs 8.x-1.15.0 and Drupal 9.4.4.
The error message is gone:
Validation error on collapsed paragraph field_view: This value should not be null.
Unfortunately, module " save_edit → " version 8.x-1.4 does not work anymore with it.
My
patch for honeypot
🐛
homepage field not filled in WebformSubmissionForm::validateFormValues
Closed: works as designed
that sets #default_value when a webform_submission is available was rejected with the justifiction that honeypot uses the Form API correctly, which I understand.
Now there is the problem that webform expects the input in #default_value for programmatic submissions via WebformSubmissionForm::submitFormValues(), but honeypot fields do not provide them.
The only solution I see is that honeypot_webform_submission_form_alter modifies the honeypot fields after they have been added to the form by honeypot and adds the #default_value when necessary.
Is that evaluation correct? Or is there a better way?
Re "homepage" field name: I already gave the field a different name here in my setup, and so I looked up the docs → which said "homepage".
Re default values should not be set: Webform module expects #default_value to contain the value of a submission when it is submitted programmatically, so my patch only set the default value when such a programmatic submission is available.
I understand your point that you're using the Form API correctly. I'll reopen my
webfrom issue #3366746
🐛
Honeypot fields not filled in WebformSubmissionForm::validateFormValues
Active
and request that webform should fill #default_value of honeypot fields for programmatic form submissions.
It seems that it is possible to fetch the input values via $form_state->getFormObject()->getEntity()->data, so honeypot can set the default values itself.
This bug is invalid then.
I found the root cause, see webform issue 3366746 🐛 Honeypot fields not filled in WebformSubmissionForm::validateFormValues Active .
Thank you for providing a solution.
The relevant git commit is https://git.drupalcode.org/project/webform_rest/-/commit/9f0ba9854168960..., and was released with version 4.0.3.
We use webform_config_ignore to not run into problems when deploying code to a test/stage/production system that has changed webform configuration in the database.
Our process is:
- Get a new database dump from live
- Import it locally
- Import the local configuration that is committed into git
- Export the (webform) changes and commit it to git, so that we have the current state in version control
This would break when the export would ignore webforms completely. So I'm on bburg's side, and would like to keep the current behavior.