Restore and modernize resourceRegistries ETag. #65
Conversation
This comment has been minimized.
This comment has been minimized.
|
@jenkins-plone-org please run jobs |
1 similar comment
|
@jenkins-plone-org please run jobs |
|
Jenkins Plone 6 passes, but all Plone 5 jobs have failures. They seem unrelated. Let's try again: @jenkins-plone-org please run jobs |
|
And we are green. |
mauritsvanrees
force-pushed
the
maurits/restore-resource-registries
branch
from
f325791
to
15624e4
Compare
|
I have rebased on master to fix a merge conflict, and force pushed. @jenkins-plone-org please run jobs |
|
@jenkins-plone-org please run jobs |
|
@mauritsvanrees This looks good to me, however it doesn't seem to be wired with Jenkins? do we need to manually run tests? |
|
According to my comment it originally passed on Plone 6 and failed on Plone 5, but that got fixed. |
|
@mauritsvanrees Ouch, sorry for merging before asking :/ feel free to force push it to fit your preference :) |
mauritsvanrees
force-pushed
the
maurits/restore-resource-registries
branch
from
5ad5170
to
bdd8fe5
Compare
That's okay. Thanks for reviewing this PR and getting the ball rolling again! |
|
Some tests fail because they fail on master too. We'll have to wait until that gets sorted out. |
…ries. Fixes warning "Could not find value adapter for ETag component resourceRegistries".
…rceRegistries removed" This partially reverts commit b18dedb. Specifically: - This reintroduces the resourceRegistries ETag in the various caching profiles. - Adds documentation for the ETag. - Adapts the tests to expect content for the ETag. The tests will need changes though. The legacy resource registries (portal_css/kss/javascript) are definitely not supported with this revert. This is only about the "new-style" Plone 5 resource registries in `@@resourceregistry-controlpanel`.
The previous code blindly removed the last etag, assuming it was the time based resourceRegistries ETag. This is true again, after reintroducing the modernized version of this ETag, but it was not true before. Moved the two versions of the _normalize_etag function to normalize_etag in test_utils.py. Fixed it there to only remove the last component when the current year is in it.
Filename needs to be unicode there.
jensens
force-pushed
the
maurits/restore-resource-registries
branch
from
2463875
to
fea0e1a
Compare
In
plone.app.cachingversion 2, for Plone 5.2+, theresourceRegistriesETag was removed, because this ETag handled the old css/kss/js resource registry tools, which are gone now. Good.But there was no upgrade step for this, so for existing sites upgraded from 5.1 to 5.2, you get lots of warnings in the logs: "Could not find value adapter for ETag component resourceRegistries". I reported this in issue #61. In that issue, I propose several solutions.
This PR chooses (I think) the most elegant of the solutions: reintroduce the
resourceRegistriesETag, but make it valid for the new-style Plone 5 resource registries. The ETag returns the timestamp from the production bundle: http://localhost:8080/Plone/portal_resources/resource_overrides/production/timestamp.txt/manage_mainThe ETag is added to the same settings where it was previously, by partially reverting a commit. Where
catalogCounteris, we addresourceRegistries, except in the feeds. Still sounds logical.The assumption is that this ETag is still as useful and needed as it ever was, for the same reasons, and that the existing ETag should have already been updated in Plone 5.0, but this was overlooked. (Not that I blame anyone.)
While I was at it, I fixed a few minor issues in the tests, mostly unclosed files.
I don't think this needs migration:
resourceRegistriesin the ETags, unless an admin removed them manually or with a policy package.