-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Module breaks on Silverstripe 4.12 #76
Comments
I can't reproduce this failure with a fresh installation of Silverstripe CMS 4.12. Can you please provide the following:
|
I can confirm the above fix works on 4.12 so it would be good to PR this @SanderHamaka. Noticed it with User Defined Form exports failing in production after 4.12 upgrade. Thanks @SanderHamaka |
@wilr Given you're able to confirm the fix works, I assume that means you were able to reproduce the issue - can you please provide steps to reproduce the issue? |
@GuySartorelli I don't have 'steps' per-se. I can give you access to the affected project if you need to see if in action yourself.
After applying the patch it now works again I have yet to try on Silverstripe 5. Result of
|
Ahh, okay, I've reproduced this now - it doesn't fail if you run the job through the jobs admin section in your browser - but it does fail if you process jobs via the CLI. The problem does ultimately stem from the new |
So, as a way to allow serialising a If it was only breaking in CLI I'd recommend that the fix is to add a I'm a little hesitant to change the response code for this special response without knowing why I'm gonna do a little more thinking about this but if I can't find an obvious reason why its problematic I'll open a PR that implements something similar to the suggestion in the description. |
I've raised a PR for this. |
Situation:
Clean Silverstripe 4.12 install. ModelAdmin with GridField Queued Export button.
Problem:
Job queues fine but always breaks immediately when the task starts to process the queue.
When the project is downgraded tot Silverstripe 4.11 all is fine.
Cause:
LeftAndMain now has afterHandleRequest that checks for $this->response->isError()
If an error is found, the current response (a GridFieldQueuedExportButtonResponse) is replaced by a new HTTPResponse representing an error state.
This is problematic because in the constructor of GridFieldQueuedExportButtonResponse a status of 500 is assigned to the response. As far as I can see this status is never altered after that and triggers the new afterHandleRequest functionality.
Fix:
This could be a fix. Perhaps someone can suggest someting more elaborate to detect the correct setting of the body on the response:
Edit:
The specific error I'm seeing when I try to run the job via the CLI is:
PR
The text was updated successfully, but these errors were encountered: