Make it easier to extend existing plugins

Created on 20 March 2024, 3 months ago
Updated 22 March 2024, 3 months ago

Problem/Motivation

I'd like to extend an existing event plugin. But this can be somewhat challenging, as we see this idiom used repeatedly (from eca_access):

$is_field_event = $this->eventClass() === FieldAccess::class;

As a result, the logic that's wrapped in if ($is_field_event) doesn't get evaluated in a subclass.

Proposed resolution

We could use is_a() and is_subclass_of() instead of a string comparison.

Also, moving this into a method (eg. AccessEvent::isFieldEvent()) would allow us to statically cache it, if we found that repeated calls to those functions added too much overhead.

Remaining tasks

  1. Create an MR
  2. Implement the proposed changes, in `eca_access` initially.
  3. Test that this allows for easier inheritance from existing plugins.
  4. Implement the proposed changes across the rest of ECA.

User interface changes

API changes

Data model changes

📌 Task
Status

Needs work

Version

1.1

Component

Code

Created by

🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @ergonlogic
  • 🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

    ergonlogic changed the visibility of the branch 3432502-extend-existing-plugins to hidden.

  • 🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

    ergonlogic changed the visibility of the branch 3432502-extend-plugins to hidden.

  • Assigned to ergonlogic
  • 🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

    The 2.0.x branch has drifted too far from 1.1.x for me to be able to develop my extension against it without significant refactoring. I need my plugin to work against the current stable release, so I'm going to start a new branch forked from 1.1.x.

  • Pipeline finished with Success
    3 months ago
    Total: 414s
    #124605
  • 🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

    As a starting point, branch 3432502-1.1.x-extend-existing-plugins now allows extension of eca_access plugins using the technique described above.

    I've also attached a patch to make it simpler to incorporate into a `composer.json` file.

  • 🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

    Re-rolled the patch, since it included the fix from 🐛 ECA Access: Incorrect field name in "Determining entity field access" plugin Needs work

  • 🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

    whitespace fix

  • 🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

    Third time's a charm.

  • 🇩🇪Germany jurgenhaas Gottmadingen

    I like this improvement, but we can only make use of it if it gets developed against 2.0.x from where it could then be backported, once completed.

  • Issue was unassigned.
  • Status changed to Needs work 3 months ago
  • 🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

    Right. ECA is becoming a key piece of our Drupal stack, so I'm sure that I'll have a chance (hopefully over the summer) to refactor this against 2.0.x.

    Some notes on possible future improvements to this:

    • Abstract the underlying implementation to pass the class name as a parameter
    • Move that method into a trait (or base class) for easier re-use across the rest of ECA (it currently only applies to eca_access)
    • Add some static caching to minimize performance impact.
    • Add some docs to show how easy it has become to extend existing plugins.
  • 🇨🇦Canada ergonlogic Montréal, Québec 🇨🇦

    Also worth noting here: we could not get our extended access plugin to interact properly with the upstream one.

    For background, the idea was to use the field access plugin (from eca_access) to forbid access to all fields, then use our plugin (that extends the field access one) to allow access during some workflow steps (in combination with other conditions).

    While we could accomplish something similar (minus the workflow bit) with just the upstream plugin, we needed to use our extended one for both parts (forbid then allow), in order for this to work.

    We think this might have something to do with the order that the hook_entity_field_access() are being evaluated or how the Symfony EventDispatcher sorted events. But we haven't yet been able to determine the root cause of this.

  • Pipeline finished with Skipped
    26 days ago
    #191235
  • Pipeline finished with Success
    18 days ago
    Total: 409s
    #197244
Production build 0.69.0 2024