IBX-11780: Integrated ContentPublicationStrategyInterface into ContentFormProcessor publish flow - #113
Conversation
…tFormProcessor publish flow, replaced content payload with content_type and covered processPublish with unit tests
| $locationId = $referrerLocation !== null && $data instanceof ContentUpdateData | ||
| ? $referrerLocation->id | ||
| : (int) $this->configResolver->getParameter('content.tree_root.location_id'); | ||
| $contentId = $this->locationService->loadLocation($locationId)->getContentId(); |
There was a problem hiding this comment.
If it has been agreed with Product Team
There was a problem hiding this comment.
This is the only thing changed for user. In async publication mode, when user is creating a new content and clicks publish right away - we don't have any content location to redirect to yet.
It was agreed with @konradoboza and @kmadejski, but unfortunately I don't see any other alternative here.
There was a problem hiding this comment.
I think there is at least one place where we store from where user came in and we redirect him to that afterwards. Not sure if this would apply here or if its even worth the effort if we agreed on that.
There was a problem hiding this comment.
yes, there's option to pass $referrerLocation to event from place where it's triggered. However, it's not always available (the fact if it's given/passed to event or not, is also based on some logic/use-case). If I'd rely on that, I'd need to have information there if we're publishing in sync or async mode (which currently is not available outside of this processor).
With the general rule that we cannot change how sync mode works, I adjusted only async path here as a consequence. Although I also think it could be done more simply, considering some wider refactor.
…tion expectations in ContentFormProcessor test
|
6 participants
Related PRs:
Description:
ContentFormProcessor::processPublish()now publishes throughContentPublicationStrategyInterface(ibexa/core) instead of callingContentService::publishVersion()directly. The strategy chain resolves to the synchronous strategy by default, or to the asynchronous one (ibexa/async-content-publishing) when asynchronous content publishing is enabled.The strategy returns a
ContentPublicationResultwhosepublishedContentisnullon the asynchronous path, therefore:contentevent payload was replaced withcontent_type(derived from the draft) — payload consumers are adjusted in the ibexa/dashboard and ibexa/admin-ui counterpart PRs,The synchronous path behaves exactly as before.
processPublish()is now covered with unit tests (strategy invocation, payload contract, sync/async redirect matrix,redirectUrlAfterPublishoverride).For QA:
Documentation:
Part of the IBX-11780 asynchronous content publishing epic — editor-facing behaviour (non-blocking publish) is documented at the epic level; nothing separate to document for this PR.