'breadcrumb' metatags do not point the frontend

The test-failure fails in the wrong way. Something about getFrontendBaseUrl() returning an empty string?

No biggie -- but interesting, because I hadn't discovered while writing the test for 🐛 'alternate' link metatags do not point the frontend Fixed . Testing once more just to be sure, b.efore I actually push a fixed test (and a fix shortly after).

Patch file for use by other system

This seems to need more changes. Will specify later.

Menu items changed. Patch for test uploaded here; will update MR after test.

Previous one worked.

Trying to do some test runs on an alternative, though.

Updated my current changes in the summary.

The proposed resolution
> If they don't have a 'entity' option, then change them to the 'default' front end base URL.
sounds good.

But, I don't think we should touch that part:

if ($absolute || $request->getRequestFormat() != 'custom_elements') {

Generally, I think this check is correct and should not be changed. Yes, maybe there are special-cases when we don't want it to happen, but then we should work them out individually, without touching that general check/logic. That's quite foundational and I don't think we should alter this check now - we want to stabilize and release.

if ($absolute || !$request->attributes->get('lupus_ce_renderer', FALSE)) {
Well, the code tries to determine API-responses, but it might be not 100% right in doing that.

https://git.drupalcode.org/project/lupus_decoupled/-/blob/1.x/modules/lu... is checking for both, what seems correct. Maybe just checking $request->attributes->get('lupus_ce_renderer', FALSE) would be enough, but I'm not sure about that, so that would have to be validated first.

> (I'm trying to write a phpunit test to include here, to enforce that links handled by the Redirect module will stay relative. However I'm having some issues with that at the moment.)

That would be a good improvement, but when hard it might better done as follow-up or added as acceptance-test. The other test-coverage improvemetns seem great already!

But the NULL format is also necessary if we want to prevent redirects specifically implemented through the Redirect module in API output, to be changed from relative to absolute unnecessarily. (Because the redirect module intercepts the REQUEST event, before the lupus_ce_renderer module sets the request format.)

I see. Could we make lupus_ce_renderer module to come earlier? Else, I guess we could simply check for both, to also catch those edge-cases, and call it a day.

Testing. Proper reply will come later.

Thanks for the review and code pointer. I think I can boil it down by just responding to the last sentence:

I see. Could we make lupus_ce_renderer module to come earlier? Else, I guess we could simply check for both, to also catch those edge-cases, and call it a day.

For completeness: Making lupus_ce_renderer module to come earlier wouldn't solve the issue of the "relative" menu links in the menu API output being turned absolute. (They are requestformat "json" not ''custom_elements''.)

I think checking for both is good, and given your pointer to other code that already does this... this 'unifies' our code, which makes me feel safer. (I abstracted it into a protected function isApiResponse() too, for some added clarity. I now also see some other custom code exactly the same check.)

So, changes since your last comment:

• add
  

    protected function isApiResponse(Request $request): bool {
      return $request->attributes->get('lupus_ce_renderer') || $request->getRequestFormat() == 'custom_elements';
    }
  

• fix: add $options['entity'] to URLs used for the responsive iframe -- to fix cases where custom code overrides the base URL based on $options['entity']

Oh also:

Noted behavior change in the issue summary.

thank you, that looks great! I've slightly improved the comments in the service yml config and merged it.

Could this have introduced an issue with the View API Output links? At this point anytime we review the API we are redirected to the Nuxt app. Probably a small case missed perhaps?

Confirmed as soon as we revert to beta4 the urls for the API are corrected.

ouch, yes I can reproduce the problem with gitpod. The API output points to the frontend, e.g. https://3000-drunomics-lupusdecouple-c470nu6nvfj.ws-eu108.gitpod.io/node... .. -> let's open a dedicated bug for this please!

Done, added as a new bug.

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