Updated: Comment #0
Problem/Motivation
Over at #2109769: CKEditor plugin cache entries should have cache tags, I updated one plugin manager's setCacheBackend()
call to also assign a cache tag. I believed this was necessary to be able to clear all cached plugin metadata that gets stored in the DB.
I was very, very wrong.
We already have clearCachedDefinitions()
for that.
The thing is: I've used clearCachedDefinitions()
many, many times. Mostly in tests. I just always thought it was for static cache clearing only. Apparently it's also for persistent cache clearing.
Proposed resolution
CachedDiscoveryInterface::clearCachedDefinitions()
already states:
* Clears static and persistent plugin definition caches.
So it's already documented. But after having talked to berdir, we think it could be more explicit. This is an attempt of doing so.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Related Issues
#2109769: CKEditor plugin cache entries should have cache tags
Comment | File | Size | Author |
---|---|---|---|
#7 | interdiff.txt | 2.52 KB | Wim Leers |
#7 | clearcacheddefinitions_docs-2112045-7.patch | 2.23 KB | Wim Leers |
#4 | interdiff.txt | 1.04 KB | Wim Leers |
#4 | clearcacheddefinitions_docs-2112045-4.patch | 1.83 KB | Wim Leers |
#1 | clearcacheddefinitions_docs-2112045-1.patch | 818 bytes | Wim Leers |
Comments
Comment #1
Wim LeersThis is the best I could think of. I'd understand it if people think this is either slightly silly or completely ridiculous. All I have to say in my defense is: I think this might help some users.
After having talked to berdir and him suggesting I improve the docs, this is the best I could think of. Maybe some of you have a better idea :)
Comment #2
BerdirWorks for me.
I guess what I meant is to document setCacheBackend() better, to state what cache tags should be used for and what not.
Comment #3
Wim Leers#2: you're right, I should do that too.
Comment #3.0
Wim LeersUpdated issue summary.
Comment #4
Wim LeersWhat about this?
Comment #5
BerdirContent works for me, @jhodgdon might have some feedback on the form ;)
Comment #6
jhodgdonI have two nitpick comments:
a)
This is a comma splice. Should be a ; or a . between these two complete sentences.
Please wrap the new text starting at the end of the previous line. Also I thought the word "this" might be slightly ambiguous in the last sentence -- could it say "Only use this parameter..."? ... Actually, this whole @param doc doesn't make a bit of sense to me, like "the cached definitions are tagged and are used to clear the cache."? that says the definitions are used to clear the cache, but I think it is the tags that are used maybe? This whole @param could be rewritten to be clearer. Please. :)
Also, please don't add a tag 'docs' to an issue that is in the documentation component. It just encourages people to add random issue tags. At least in Core, we try to have useful and meaningful tags (and we even have tag guidelines, which are linked below the tag field). Thanks!
Comment #7
Wim LeersRegarding the "docs" tag: I added that tag when this wasn't in the "Documentation" component. And, honestly, I think it's inappropriate to move anything that is not related to the documentation system itself into the "Documentation" component: how are people then supposed to find out what part of the system it's related to? This is a "docs" thing about the "plugin system".
Comment #8
jhodgdonThe reason for moving things into the Documentation component is primarily so that I will see them, because I watch that component and will review and commit issues only from there. So usually what happens is what happened on this issue: the technical and module-maintainer issues are resolved first and the issue is in that component, and then it is moved to Documentation for final wording, grammar, and standards review/commit by myself and/or others who watch Documentation issues and review them.
Also if there are issues in Documentation that have technical questions that are not obvious, I generally move them into that other component and ask for the maintainers of that component to answer them; however, once they are resolved, I will not see the issue in the "OK for Jennifer to commit" queue if it is not in Documentation, because my mandate is only to commit API docs patches (except for emergency fixes of head and rare cases like that).
Anyway, I love your rewrite of that 2nd topic. It is very clear now. Thanks! Setting to RTBC pending perhaps anyone else following this issue having a different opinion.
Comment #9
jhodgdonThanks again! Committed to 8.x.
Comment #10
Wim LeersThanks :)
Why would https://drupal.org/project/issues/search?issue_tags=docs not suffise?
Comment #11
jhodgdonIt's not that it *wouldn't* suffice... But why "docs" in particular? Just start typing "doc" in the Tags box. There are lots of tags:
docs
documentation
d7docs
d8docs
documentation bug
etc.
See, the problem with tags is that they are free form and people are (despite the guidelines links below the tags field, which no one reads) always inventing new ones.
So, we have instead standardized in Drupal Core on using the "documentation" component. There are quite a few people (including myself) that find it quite useful to be able to have one central place to look for API docs issues. The system is working well... why change it?
Comment #12
Wim LeersWhy change it? Because it'd be better.
Because "Documentation" is not a subsystem/module of its own. Documentation must be written and exists for *every* single subsystem/module. Several times already, I've found out much too late that there was an issue related to one of the core modules I'm a maintainer for in the "Documentation" component, which I would've found much sooner if it existed in the module's component.
If we'd apply the reasoning that's being applied here to everything, then e.g. the "CSS" and "JavaScript" components should contain hundreds of additional issues. Imagine how dysfunctional it would be to find a module-specific CSS problem in the "CSS" component — how would component maintainers possibly be expected to find those?
So that's why I'm arguing the "CSS", "JavaScript" and "Documentation" components should only contain "meta" and "standards" issues. Anything that's specific to a subsystem/module should go into that component.
Note that this is already how nod_ (the JavaScript maintainer) tracks JavaScript issues across all of Drupal core: https://drupal.org/project/issues/drupal/search?issue_tags=JavaScript !
I do understand that the current system works well for you. But it inherently works poorly for component maintainers.
Comment #13
xjm@Wim Leers, I think it might make sense to open a separate policy issue for this to discuss it so we don't hijack this issue? :)
Comment #14
jhodgdonI was just going to say the same thing. Definitely if you want to open up a discussion it needs to be a separate issue so that others doing core dev can respond properly.