I agree with #18 and #23, and I greatly appreciate the patch#24 !
Hi, @niharika.s, I don't know why you would get that error. With Drupal 10.1.8 you could use View Mode Page v4.0.2 but not any later version (view_mode_page.info.yml line 4 is core_version_requirement: ^9.3 || ^10.0 for version 4.0.2). Later versions require at least Drupal 10.3. I wouldn't try to get around that by changing view_mode_page.info.yml - it won't work!
This could be some kind of cache-related issue, where a reference to the setContainer method persists after the updated module is uploaded, so that this error is thrown when update.php is run. I was able to do the update, apparently successfully, by temporarily patching line 278 of /core/lib/Drupal/Component/DependencyInjection/Container.php to ignore an attempt to invoke the removed method - adding a condition like the following before call_user_func_array:
if (!($method === 'setContainer' && str_contains(get_class($service),'\DynamicPathProcessor'))) call_user_func_array([$service, $method], $arguments);
With that patch, the update completed successfully. After the update, I removed the patch and so far everything seems to be working normally.
I suppose this is related to the deprecation of EntityTypeManager::setContainer. It is removed from view_mode_page.services.yml in v.4.0.3. But apparently something still is looking for that method.
peter pulsifer → created an issue.
peter pulsifer → created an issue.
Hey, @jcl324 - that works. Very clever! Now we just need to figure out what's going on... Thanks!
Yes, @megachriz, you're right, it's a duplicate. Sorry I missed that related issue. Looking forward to the update!
peter pulsifer → created an issue.
peter pulsifer → created an issue.
I struggled with this same issue. I installed EBT but could not install the EBT Starterkit because it requires Drush 12+. So I never added any EBT content. The EBT Core Remove Helper had no effect - it reported correctly that there was no EBT content to delete, and "Remove EBT Settings Field Storage" resulted in no change.
Looking at EbtRemoveHelperForm.php, I see that in my case at least,
$field_storage = \Drupal::entityTypeManager()->getStorage('field_storage_config')->load('field_ebt_settings');
gives no results ($field_storage is null).
What did work is
$field_storages = \Drupal::entityTypeManager()->getStorage('field_storage_config')->loadByProperties(['module' => 'ebt_core']);
foreach ($field_storages as $field_storage) $field_storage->delete();
So loading the field storage by module instead of by name was the way to go for me.
Drush is probably the best option, if you can do it, but I am on a shared server with no shell access!
I was unable to clear the cache with the UI because of the error. What I did was remove keep the 4.0.0 code in place but reference to the CsvSubscriber class in csv_serialization.services.yml, then clear the cache. After doing that I could upgrade to the full 4.0.1 version without a problem. It was very helpful to know where this problem came from. Thanks for the quick response!
peter pulsifer → created an issue.
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.