0

I would like to add a feature to the core string contextual filter, implemented in core/modules/views/src/Plugin/views/argument/StringArgument.php.

If I use hook_views_query_alter(), I would have to undo everything the core function did first, then roll out my changes.

Is there a way to just completely override the core function instead of only altering the results?

The contextual range filter accomplishes this by presenting the site admin with a configuration page to select which instances of an existing filter should be replaced by the new object. I could follow this route, but I would prefer to update all cases site-wide.

5
  • as you can see the StringArgument is a plugin, so you can simply alter the plugin registry and point to your own class.
    – user21641
    Dec 31, 2017 at 23:01
  • Would this be a global change or have to be done for each view after it is created? Ideally I would like to extend the core StringArgument and just change the couple methods that need to be changed, and use it instead of the core Plugin. Dec 31, 2017 at 23:18
  • This depends, you have to look which plugin classes are the ones really used by Views. For example the node module extends NumericArgument and StringArgument to Nid and Type. So if you want to override contextual filters for content globally, you have to override these plugins and replace them in hook_views_data_alter().
    – 4uk4
    Jan 1, 2018 at 10:16
  • So if i want this new version of the StringArgument to be used site-wide and I name it @ViewsArgument("string_operator"), I imagine I would have to have an install script run hook_views_data_alter to do something like $current = $data[$table_name][$field_name]['argument']['id']; if ($current == 'string') $data[$table_name][$field_name]['argument']['id'] = 'string_operator';. Then how do I let drupal know that my new argument is the default to use for all future string fields? Jan 4, 2018 at 12:49
  • Alternatively, should I name my plugin 'string' and use some hook to change whatever translates Drupal\views\Plugin\views\argument\StringArgument.php = @ViewsArgument("string") to Drupal\views\Plugin\views\argument\StringArgument.php = @ViewsArgument("string_old") Jan 4, 2018 at 14:33

1 Answer 1

0

Personally I would make an inheritance from this core plugin, extend it in my own class (classes), and change in the views to use my custom plugin.

2
  • I have reverted the core StringArgument back to the original version, created a module, moved my file here, and made it extend StringArgument. I see two routes forward. I can either name it @ViewsArgument("string"), and somehow tell drupal to ignore the core StringArgument, or I can name it @ViewsArgument("string_operator") and somehow tell Drupal that all existing and future fields of type string need to use the string_operator plugin. Any suggestions on which to do and how? As a test, I renamed the core file to "string_old" and my new one to "string" and it works. Jan 4, 2018 at 14:38
  • Am sorry I don't have that much knowledge about views and this argument stuff. So I won't able to help you with that. The test COULD be a working solution, if you for example rename the core file with a patch (and put the patch into the composer.json). But definitely a dirty solution.
    – ssibal
    Jan 5, 2018 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.