Skip to content

IBX-8074: Made SiteAccessService react to CONFIG_SCOPE_CHANGE/RESTORE - #805

Open
Steveb-p wants to merge 3 commits into
5.0from
IBX-12204-siteaccessservice-scope-stack-5.0
Open

IBX-8074: Made SiteAccessService react to CONFIG_SCOPE_CHANGE/RESTORE#805
Steveb-p wants to merge 3 commits into
5.0from
IBX-12204-siteaccessservice-scope-stack-5.0

Conversation

@Steveb-p

@Steveb-p Steveb-p commented Aug 12, 2026

Copy link
Copy Markdown
Contributor
🎫 Issue IBX-8074

Related PRs:

Description:

SiteAccessService::getCurrent() only ever returned whatever was set once via the (shared, singleton) SiteAccessAware::setSiteAccess() call. ContentPreviewHelper::changeConfigScope()/restoreConfigScope() and ConsoleCommandListener::onConsoleCommand() build a new SiteAccess and only dispatch it as a ScopeChangeEvent under MVCEvents::CONFIG_SCOPE_CHANGE/CONFIG_SCOPE_RESTORE — they never touch that shared object. So during content preview or a --siteaccess CLI run, getCurrent() kept returning the outer/main siteaccess instead of the one that's actually active.

SiteAccessService now implements EventSubscriberInterface and reacts to those two events directly, keeping a small stack: push on CONFIG_SCOPE_CHANGE, pop on CONFIG_SCOPE_RESTORE (never below the base entry, so an unbalanced restore can't null out the current siteaccess). setSiteAccess() still seeds the base of that stack, so the existing DI wiring in routing.yml and the SiteAccessAware contract are untouched.

This is deliberately not the full IBX-12204/#798 rework — no changeSiteAccess()/restoreSiteAccess() API, no SiteAccessAware deprecation, no migrating ContentPreviewHelper/ConsoleCommandListener/etc. off it, no MVCEvents::SITEACCESS/FINISH_REQUEST sub-request handling. Just the reactive fix, since ContentPreviewHelper and ConsoleCommandListener already dispatch the events we need — zero changes required on their end.

For QA:

Unit coverage is in SiteAccessServiceTest (change/restore, the never-drop-base guard, nested change/restore round-tripping). To see it manually:

  1. Publish some content, then open it in Preview for a siteaccess other than the one you're currently browsing.
  2. In the preview sub-request, dump $container->get(SiteAccessServiceInterface::class)->getCurrent()->name (e.g. from a debug template block, or a breakpoint in ContentPreviewHelper::changeConfigScope() right after the call) — it should be the previewed siteaccess, not the one you started from.
  3. Leave preview — getCurrent() should be back to the original siteaccess.

Same idea for CLI: run any command with --siteaccess=<other> and confirm SiteAccessServiceInterface::getCurrent()->name reflects it instead of the default.

getCurrent() only ever reflected the value set once via the shared
SiteAccessAware::setSiteAccess() singleton, so it never picked up a scope
change dispatched by ContentPreviewHelper or ConsoleCommandListener. It now
keeps a small stack, pushing on CONFIG_SCOPE_CHANGE and popping on
CONFIG_SCOPE_RESTORE.
@Steveb-p

Copy link
Copy Markdown
Contributor Author

Backported this to 4.6 too: #806

@sonarqubecloud

Copy link
Copy Markdown

@bnowak

bnowak commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

If that's backported to 4.6 - do we need that PR at all now? Could it be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bug Something isn't working Ready for review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants