I have the weird situation that my Plone 6.0.0a6 installation (build from scratch as part of a migration project generates @@confirm-action redirect (from plone.protect). This happens with GET requests on the default view of content objects. Pasting an URL like http://localhost:42080/eteaching/technik/produkte/phpnukesteckbrief/view into the browser address bar regenerates the redirect in a reproducible way over and over again. A restart and reload usually solves the problem.
Broader context: I came across the error with my zopyx.typesense search engine plugin which generated the result page of a search using JS on the fly. The links to related Plone objects all end view /view...so their default view. Clicking on such a link (in some cases) causes the plone.protect redirection and then when copy & paste the related URL manually...and there is nothing in the implementation that would modify the related content-object during a GET request.
I think, this is right direction based on my observation:
content objects of one particular type without images do not cause the error
content object with images cause the error. Clicking on confirm resolves the issue for this particular content object and the view renders from this time on correctly
Since the content is migrated/imported using collective.exportimport, there might be another step necessary for recreating the image scales programatically? Any idea @pbauer ?
Shouldn't touch the context though, unless it is the first time an annotation is set.
That's why I figured that the content of the btree might be useful data - if there's only the image stuff that might be it.
Another observation: when I edit an object through the Plone UI before actually viewing it, the problem disappears. I assume, I need to recreate all image scales manually as part of the content migration import.
@mauritsvanrees do you have any idea how trigger the automatic regeneration of all scales for all objects with image fields programmatically?
Since this plone.namedfile PR the IDisableCSRFProtection marker interface is no longer set on the request.
That should be okay because plone.scale has code to mark the relevant classes as safe for write on read.
It can be that something is still missing there, that more such write-on-read allowing is needed for scales.
(I don't see a proof above that this is the actual problem, but it could be.)
Get all objects (via catalog or ZopeFindAndApply)
For each object iterate over all fields.
For each field that is a NamedBlobImage, use code similar to what is in plone.namedfile.adapters to iterate over all available scales and generate them. But be sure to set pre=False in this line. That will trigger really generating that scale again with Pillow.
I think that the issue is resolved (for now). The original migration import happened against Plone 6.0.0a4 with the upgrade to a6 using the Plone migration steps. Then the problem appeared.
A fresh import into a new a6 site does not show the issue
For me: problem resolved so far...but I don't know if there is anything to be done or fixed on the Plone migration side?!