Publishing engine now triggers onAfterPublishRecursive instead of onAfterPublish which fixes a lot of problems when dealing with pages which contains a lot of nested models like blocks. This ensures that URL collection starts after all models in the publishRecursive batch are published.
Unit tests are passing but the build is failing due to some QueuedJobs related issue. This is likely some registered shutdown function which is called near the end of the test suite run. I couldn't reproduce this on my local (vanilla install).
I added some logging to see the stack trace of the exception:
Looks like despite my best effort to disable the Symbiote\QueuedJobs\Services\QueuedJobService->onShutdown() it's still being called. The cause for this is that there are some places where QueuedJobService is created via Injector which is not covered by the unit tests customisation. Just having this service is memory is enough to trigger the error as that is the default behaviour.
I was able to resolve this by forced injection approach.
Publishing engine trigger
Publishing engine now triggers
onAfterPublishRecursive
instead ofonAfterPublish
which fixes a lot of problems when dealing with pages which contains a lot of nested models like blocks. This ensures that URL collection starts after all models in the publishRecursive batch are published.Related issues
https://github.com/silverstripe/silverstripe-staticpublishqueue/issues/134
Issues with tests
Unit tests are passing but the build is failing due to some QueuedJobs related issue. This is likely some registered shutdown function which is called near the end of the test suite run. I couldn't reproduce this on my local (vanilla install).
I added some logging to see the stack trace of the exception:
Looks like despite my best effort to disable the
Symbiote\QueuedJobs\Services\QueuedJobService->onShutdown()
it's still being called. The cause for this is that there are some places whereQueuedJobService
is created via Injector which is not covered by the unit tests customisation. Just having this service is memory is enough to trigger the error as that is the default behaviour.I was able to resolve this by forced injection approach.