Allow separate API key, pull zone and base url per purger instance

This should already be (mostly) possible with the Purger module → integration:

1. Follow the Getting started instructions in the project description →
2. Visit /admin/config/development/performance/purge and add two Bunny CDN purgers, one for the frontend and one for the backend.

Currently, the API key is taken from the BUNNY_API_KEY env variable and the pull zone ID is taken from the BUNNY_PULL_ZONE_ID env variable. We should make these part of the purger configuration.

About the extra button on the Performance screen: this would be a good candidate for a more abstract module (not specific to Bunny CDN) that adds buttons for every configured purger that has the ability to do full invalidations.

I added purger settings with API key, pull zone & base URL properties. Can you test if this works for you? Until the Performance screen button is implemented, you can use add a Drush p:invalidate processor and run drush p:invalidate everything.

Hello @DieterHolvoet
Thank you for your nice contribution first.
I was doing some testing and it works quite good, except one thing which is maybe(?) my environment issue I'm not sure: when I want to purge the pull zone with ddev drush p:invalidate everything -y (parameters are already added via the config form of course) I'm getting an error which relates to Guzzle I guess Bunny purge request failed. Status code 400: Client error: `POST https://api.bunny.net/pullzone//purgeCache` resulted in a `400 Bad Request` response: {"Message":"The request is invalid."}.
However I can complete the request with a Postman call. Looks like Guzzle wants to send the request "twice" for some reason, I've attached the log (AccessKey was sanitised because of privacy)
I've found a ticket which relates to this error: https://github.com/guzzle/guzzle/issues/1432
As far as I understand when the response code is 204 and the content body is empty it throws and exception.
Could you please check it on your side as well? I'm using a strandard drupal install with Drupal core 10.2 in ddev.

Thanks!

Ignore the error above, it was a configuration issue (used the same zone id twice).
The module does its jobb very well. Regarding the "Purge bunnyCDN" button I agree it's more abstract and there is already a working patch for that in Purge module: https://www.drupal.org/project/purge/issues/2853613 ✨ Invalidate a purger's cache from UI Needs review

I've discovered only two things that should be added/changes I guess:
- add purge module as a dependency to module.info.yml
- "BunnyPurger" class should implement "PurgerInterface"

Looking forward you feedback.

Adding these changes in patch format, you can quickly apply if you agree of course.

add purge module as a dependency to module.info.yml

I decided not to do that since it's not strictly necessary. The 'setting the CDN-Tag header required by Bunny CDN for tag based purging' part of the module doesn't need the Purge module, so I though I'd keep it optional. The project description already instructs to install the Purge module if necessary.

"BunnyPurger" class should implement "PurgerInterface"

The BunnyPurger class extends PurgerBase and that class already implements PurgerInterface.

I see, okay. Good to go from my side

@DieterHolvoet thanks a lot for your very fast feedback and code!

I guess we had our steps for implementing functionality, backward: "first do a simple purge-all button, then check more refined purger module integration later" -- while in fact the purger module can also facilitate the former :-)

You're welcome! I still had this as a TODO in the back of my head anyway :)

Addendum: (So far just a stream of consciousness, thoughts not crystallized...)

About the extra button on the Performance screen: this would be a good candidate for a more abstract module (not specific to Bunny CDN) that adds buttons for every configured purger that has the ability to do full invalidations.

I see your point. We may just do a quick internal glue module, kick its tires, and release later if fit.

Currently, the API key is taken from the BUNNY_API_KEY env variable and the pull zone ID is taken from the BUNNY_PULL_ZONE_ID env variable. We should make these part of the purger configuration.

The irony is that env variables are quite nice for multi environment hosting... and I'm not really seeing a good way to marry these with config entities.

Combined with 🐛 Exception when enabling 1.1.0 (dependency on purge) Active ... is there maybe a case to be made to store the configs in 'common' configuration that is overridable by a settings(.local).php which can define local bunnycdn purger config (that may be fed in by $_ENV['whatever-local-key']?

Maybe even one setting named 'bunny_cdn.purger_settings' or somesuch, keyed by the purger id?

• makes loading/saving possibly more involved, but not that much I think.
• just needs a config schema file with a mapping.
• the purger ID is still random-ish (I think), but that shouldn't matter because it should stay consistent across environments.
• We can assume that even when multiple configs are stored in the same value, it won't get huge. (Also, purger.settings are stored in one single config item, not in several items or entities.)

Note it's possible that I'm talking nonsense and am completely unaware of the fact that it's possible to define config entities in settings.php.... But I don't... think so?

Maybe I'm talking nonsense though.

I'm essentially making a case against the existence of PurgerSettingsBase... It's "not your fault" that that's implemented as a config entity...

(Yes, this is just live thoughts coming into my head...)

You can easily override config values with .env variables in settings.php. You do have to create and configure the purger through the UI first, but afterwards you can remove any sensitive values from config and override them in your settings.php. Example:

$config['bunny_cdn.settings.1f2806c26a']['api_key'] = $_ENV['BUNNY_CDN_API_KEY'] ?? '';
$config['bunny_cdn.settings.1f2806c26a']['pull_zone'] = $_ENV['BUNNY_CDN_PULL_ZONE'] ?? '';
$config['bunny_cdn.settings.1f2806c26a']['base_url'] = $_ENV['APP_URI'] ?? '';

Thank you. I'm still amazed by how much common knowledge I lack.

(I had tried web searchds, and to trace loadMultiple() for a point where config entities were overridden by settings.php contents, but couldn't find this fact.)

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