May I request what's in the title, so that certain sites with special configuration needs can keep using your module more easily by extending your plugin with a child class/plugin?

MR coming soon.

(It's a slow drip of communication from our side... because sprint work / coordination / still finding out how our own pieces fit together. I believe this is the last.)

CommentFileSizeAuthor
#4 3418411.patch2.97 KBroderik

Issue fork bunny_cdn-3418411

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

roderik created an issue. See original summary.

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
commented
Issue summary: View changes

roderik opened merge request !5

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
commented
Status: Active » Needs review
StatusFileSize
new 3418411.patch2.97 KB

The patch is just for our build system.

Given the second tagged-on functionality, maybe you want to change the commit message completely -- but that's up to you.

dieterholvoet’s picture

dieterholvoet commented

Just out of curiosity: why do you want to override the config this way? You know you can override config in settings.php, right?

dieterholvoet’s picture

dieterholvoet commented
Status: Needs review » Fixed

Merged!

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
commented

Thanks for the new release!

The answer is, its' just less confusing to override things in a child purger, at the moment:

  • We now have a custom button to purge the whole zone (because the purge module likely will support this, but we can't wait for it). The configuration (zone, key) for that is already in a 'global' config screen that stores a 'regular' settings object, and it's easier to inject those settings directly than duplicate a 'fake config entity' in settings.php
  • Our hosting product (the custom part that is based on Lupus Decoupled Drupal but not open sourced at the moment) has a concept of various "front ends" populated with content from a single Drupal instance. Each front end has their own domain / Bunny zone. I really haven't figured out how to do tag based purging perfectly (or whether it is even desirable to 'route' some tags to a single front end only) so for now I'm just purging all the zones -> I need all the zone IDs -> that's customized stuff.
  • (And I want to turn off path/URL based purging for now, on our own 'child class' purger, so I don't need to deal with figuring out what's the zone + base URL for specific paths.)

...so on point 2, I'm now iterating through zones calling parent::invalidateTags() / parent::invalidateAll() while making sure that getPurgerSettings() returns a different zone ID in each iteration. It's slightly wonky code, but at this point still better than just copying this module's code into our setup. I think.

Status: Fixed » Closed (fixed)

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