Allow pointing alpaca to internal domains

[joecorall]

GitHub Issue: Islandora/documentation#2181

• https://islandora.slack.com/archives/C019U12D44Q/p1761594623294649

What does this Pull Request do?

Allow events emitted from Drupal to point to internal domains instead of the public domain

What's new?

Adds a config option to set search/replace on URIs in the Islandora event to allow rewriting the domain alpaca/scyllaridae should hit Drupal from.

How should this be tested?

Documentation Status

• Does this change existing behaviour that's currently documented?
• Does this change require new pages or sections of documentation?
• Who does this need to be documented for?
• Associated documentation pull request(s): ___ or documentation issue ___

Additional Notes:

Any additional information that you think would be helpful when reviewing this
PR.

Interested parties

@ruebot @rbos

[rbos]

This seems very promising as an approach to solve our reverse proxy derivate generation problem!

We have been using the "lazy" source_uri rewrite approach, maintaining a small patch set for years.

[adam-vessey]

I feel like a more robust implementation pattern would be to introduce some form of a URL resolver to be used by the microservices framework, instead of rewriting URLs away from their canonical forms.

That said, if it was desired to instead introduce an extension point in lieu of directly implementing here, such as dispatching an event before the json_encode() call, such that the event could be subscribed to by another module and whatever done to the event JSON that might be desired, that would be fine? Drupal is modular; there's no need to cram all functionality into one module, especially when the functionality is optional.

[joecorall]

That said, if it was desired to instead introduce an extension point in lieu of directly implementing here, such as dispatching an event before the json_encode() call, such that the event could be subscribed to by another module and whatever done to the event JSON that might be desired, that would be fine? Drupal is modular; there's no need to cram all functionality into one module, especially when the functionality is optional.

@adam-vessey Good call. We probably can just put this in a module and make the event message alterable. Do you have a preference if this optional module is in this repo or create a separate one?

[adam-vessey]

That said, if it was desired to instead introduce an extension point in lieu of directly implementing here, such as dispatching an event before the json_encode() call, such that the event could be subscribed to by another module and whatever done to the event JSON that might be desired, that would be fine? Drupal is modular; there's no need to cram all functionality into one module, especially when the functionality is optional.

@adam-vessey Good call. We probably can just put this in a module and make the event message alterable. Do you have a preference if this optional module is in this repo or create a separate one?

Preference? Not really. Assuming it doesn't introduce any other dependencies, then it should be fine as a submodule. If it was introducing other requirements into composer.json, it might make more sense in a separate package/repo? Given there wasn't anything else introduced here presently, I'm wanting to say that it should be fine as a submodule.