@mattbloomfield Thanks I confirm that I can now access the Updates report on the back end of the site, and also run cron, without the database becoming corrupted. Thanks for rapid response.
@dineshkumarbollu I have version 2.0.5 installed and the info.yml file reads like this:
core_version_requirement: ^9.3 || ^10
I'm not really sure what is going on but I do not think the problem is coming from the code that is on my site, but from some code or configuration on this (Drupal.org) site.
If I fix the problem in my database, the site runs fine, until next time cron runs, or I visit the Updates report in the back end of the site. At this point it updates the key_value_expire table again with the dodgy ^^ record, which causes the site to break again. (I basically cannot load any /admin* page on the site whilst the problem exists in the database).
If you look at the main project page for the module ( https://www.drupal.org/project/at_tool → ), under the 3.0.0 Releases section it says:
"Works with Drupal: ^^10 || ^11"
I think this is the cause of the problem, although I couldn't say if this is coming from your code, or a misconfiguration on the Drupal site. It seems that when cron runs (or I visit the Updates page) on my site, it is harvesting data on module availability from Drupal.org and storing it in the database, but because there is the ^^ error on the Drupal.org site it is getting transposed to module users.
If you are having this problem here is a temporary fix:
Find the key_value_expire table in your database.
Find the record WHERE the collection field = 'update_available_releases' AND the name field = 'at_tool'
Download the blob data and change "^^" to "^"
Update the blob data in the database.
You should be ok then, until the next time cron runs ..
I have this problem as well with D 9.5.x
@jitendrapurohit Apologies for taking so long to reply. I'm afraid that I still get the same error message after applying the patch:
TypeError: array_filter(): Argument #1 ($array) must be of type array, string given in array_filter() (line 726 of /modules/contrib/webform/src/Plugin/WebformElement/OptionsBase.php)
Although I should mention the patch was applied to a site running version 6.2.3 whereas I originally reported it with module 6.2.2. (Just thought I would mention in case it is relevant.)
Does not solve the problem I'm afraid.
@Megaphonejon, the Value field is empty. Here is the YAML for the field:
civicrm_1_activity_1_activity_activity_type_id:
'#type': civicrm_options
'#title': 'Activity Type'
'#civicrm_live_options': 0
'#options':
58: 'Resident survey'
'#default_value':
- '58'
'#access_create_roles':
- administrator
'#access_update_roles':
- administrator
'#access_view_roles':
- administrator
'#extra':
aslist: 1
multiple: 0
'#form_key': civicrm_1_activity_1_activity_activity_type_id
'#parent': civicrm_1_activity_1_fieldset_fieldset
'#default_option': '58'@Megaphonejon, the w_c patch (829) had no effect. The Civi patch (23305) fixed the second of my issues but not the first.
So a field set to Live Options, but with no default value set, and no submission value works with the second patch applied.
But a field set to Static Options but with only a single option enabled, and a default value submitted still does not work with either patch and gives the following error:
TypeError: array_filter(): Argument #1 ($array) must be of type array, string given in array_filter() (line 726 of ~/httpdocs/web/modules/contrib/webform/src/Plugin/WebformElement/OptionsBase.php)
I don't think it is an issue with Civi. I tested it with module version 6.2.2 and 6.2.1 using the same Civi code and it works with the older version of the module.
roblog → created an issue. See original summary → .