Upgrade from 'as a reference filter' not working with core 10.4.0-rc1

Could be one of two things.

1. Update hook not running on fresh install, maybe we need to call it from hook install, but for now you can run it manually https://drupal.stackexchange.com/a/179811
2. Your version of the patch differs from the update hook. There were so many versions of the patch over the years, contributions are needed to cover more versions (see module homepage) but for now if you check the source code, the test submodule has configuration for one 'as a Reference' version, if your version matches that then (1) should work.

Thanks

Thank you for the quick reply!

I don't think it's #2 because mine fits what I see in the module & test submodule code, for example (looks the same before and after this module):
field_topics_target_id_reference:
id: field_topics_target_id_reference
table: node__field_topics
field: field_topics_target_id_reference
relationship: none
group_type: group
admin_label: ''
plugin_id: entity_reference
operator: or
value: { }
group: 1
exposed: true
expose:
operator_id: field_topics_target_id_reference_op

Looks like this module attempts to remove the '_reference' but that didn't happen for me. I wasn't sure if this line was a factor:
if (
$filter['plugin_id'] !== 'entity_reference'

Either way, I am able to delete the broken exposed filters and add them again, and they work as expected.

Question:
I am able to add the filters by adding 'field_name' but NOT the 'Related field_name..' as illustrated in the change record at https://www.drupal.org/node/3403710 → Is that expected? Maybe because this module successfully opted me in?

Thanks again, appreciate all your efforts

Question:
I am able to add the filters by adding 'field_name' but NOT the 'Related field_name..' as illustrated in the change record at https://www.drupal.org/node/3403710 → Is that expected? Maybe because this module successfully opted me in?

Yeah when I made those screenshots I had actually named the fields 'Related articles' that's all. At the moment in core, there is no option to choose between them other than programmatically (like this module does for you) until ✨ Configurable views filters to allow for different widgets Active .

Looks like this module attempts to remove the '_reference' but that didn't happen for me. I wasn't sure if this line was a factor:
if (
$filter['plugin_id'] !== 'entity_reference'

That condition ends in a continue; as in don't proceed if not entity_reference filter (along with the other criteria). From what I can see from your config, your code should pass that condition so I think it is more that the install hook should trigger the same update.

You said you resolved it manually, so that means you did not try the https://drupal.stackexchange.com/a/179811 - is that correct? I think yes.

Had to fix a gitlab CI deprecation but updated the install process to also trigger the update now.

Thanks Scott! Correct, I did not try the https://drupal.stackexchange.com/a/179811 as I didn't want to add to my own confusion lol. Thanks for the clarifications! I'm almost done manually re-adding my filters & they're working as expected. Thanks again for your help.

Sure no problem at all

And thanks for raising in the first place, always helps make things better for the next person!

This MR introduced the following chunk in views_core_entity_reference.install:

/**
 * Implements hook_install().
 */
function views_core_entity_reference_update_install($is_syncing) {
  _views_core_entity_reference_update_as_a_reference();
}

If I'm not mistaken, the new hook_install() implementation is in fact a hook_update_N implementation (where N = install instead of a number).

Hook install should be called on initial install for new installations (according to the docs at least) whereas hook updates are only called when a module is already installed and is then subsequently updated to a new version.

True. But the function is named like this: views_core_entity_reference_update_install.

The module name is: views_core_entity_reference. Hence, module handler will interpret the remaining _update_install as hook_update_N instead of hook_install.

Aha I see, thank you! Updated hook name, manually tested. Thanks

Thank you!

Automatically closed - issue fixed for 2 weeks with no activity.