Perhaps a more direct answer is at
https://drupal.stackexchange.com/questions/229422/how-to-make-a-form-fie...
It seems to depend on the type of field, and the only way I could track it down was to make the field required in the UI and then dump the $form_state array in my hook_form_alter function. For a taxonomy term entity reference field, all I needed was to set
$form['fieldname']['widget']['#required'] = true;
But for a text field, I needed
$form['fieldname']['widget'][0]['value']['#required'] = true;
Just to be careful I set
$form[fieldname']['widget']['#required'] = $form[fieldname']['widget'][0]['#required'] = $form[fieldname']['widget'][0]['value']['#required'] = true;
That's the way it comes in when I make the field required in the content type.
Just keep shooting in the dark until you hit something!
I had the same error as @ovanes, #30.
TypeError: Cannot assign null to property Drupal\views\Plugin\views\argument\ArgumentPluginBase::$operator of type string in Drupal\views\Plugin\views\argument\ArgumentPluginBase->unpackArgumentValue() (line 1303 of core/modules/views/src/Plugin/views/argument/ArgumentPluginBase.php).
This came from a view that takes a node id as a contextual argument, and it was being passed a random argument. When that argument included a non-numeric character, the error was triggered.
The cause of all this is the function breakString($str) in HandlerBase.php, which returns $operator as a string ('or' or 'and') when $str is alphanumeric and returns it as null when $str contains a non-alphanumeric character. I don't see the null return behavior documented anywhere; is it important to retain it? If not, the fix would be to change breakString() so it always returned a string for $operator - either 'and', which seems to be the default, or simply a null string, which would at least not cause TyeError issues.
I solved my problem by adding numeric validation to the contextual argument, but it seems like this should be cleaned up.
Yes, it appears to be fixed. Thanks!
I have exposed filters displayed in a block form, and am using AJAX. I can change the filter values using hook_views_pre_build() or hook_views_pre_view() and $view->setExposedInput($newfilters) but I cannot change the filter values displayed by the exposed filter block. Apparently the displayed values are taken from the defaults and are not the actual filter values used for the query.
This might be a different situation from exposed filters that are set up programmatically.
With hook_views_pre_view(), I find $view->filter is an empty array; with hook_views_pre_build(), $view->filter is set to the filter values.
Using $view->setArguments() sets the contextual arguments for the view, not the exposed filter values.
I have tried using a form hook to change the displayed filter values, but that also has no effect. With the form hooks you can change the way the values are displayed (or hide the filter entirely) but you don't seem to be able to alter the displayed values.
I'm investigating whether I can fake a query string to change the exposed filter form; or I might have to resort to changing the values with JS. It's good to be able to customize the filters, but it's bad to have the results not match the filter display.
Hi, @adityarawat_ln,
That worked for me! Thanks for your assistance.
I seem to have the same issue. When I set a non-default date format, then when I edit the node the date changes to what seems like a random value. For example, (using the format "m/d/Y H:i K") a date of 18 December 2023 appears on the edit form as 03 August 2024 - time 00:00. If I save the edited form, the incorrect date is saved, which can be a real problem because it's unexpected. If I edit the date using the widget, the correct date (the one I selected) is saved. So the problem is where the widget is receiving the saved value, not where it sets the selected value.
With a little experimenting, it seems that it works with the Y format code in the first position. Trying the code "F j, Y H:i K" the date becomes "2023-12-18 18:30:00 America/New_York" which of course makes no sense.
It's good that it seems to work with the default format, but it would be great to be able to use a different format.
Here's a suggested patch.
Peter Pulsifer → created an issue.
I use overrides to set a contextual argument for a placed block - for example, to select a media gallery or filter content by a particular year. The argument could be a media gallery ID or a taxonomy term name.
Peter Pulsifer → created an issue.
Peter Pulsifer → created an issue.