Closed (fixed)
Project:
Monitoring
Version:
8.x-1.x-dev
Component:
Sensors
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
2 Sep 2022 at 10:57 UTC
Updated:
22 Mar 2024 at 15:49 UTC
Jump to comment: Most recent
Comments
Comment #3
useernamee commentedComment #4
useernamee commentedI've implemented one of the MR comments. Thanks @jjchinquist for review.
Comment #5
fagoCode looks pretty good, I only add a minor casing remark.
Not 100% sure about the naming, I probably would have called a summary, but I think "recap" also cuts it.
I also tested it, it generally seems to work fine, but I noted the detailed description contains HTML-encode chars, e.g. as in this example:
> 6 warnings in status report, exceeds 1, Configuration files: Protection disabled, Deprecated modules enabled: Deprecated modules found: <em class="placeholder"><a href="https://www.drupal.org/node/3223395#s-ckeditor">CKEditor 4 (contrib)</a></em>., Drupal core update status: No update data available, Field Group: jQuery UI Accordion not enabled, GD library FreeType support: Not installed, Media
I'd assume that's not displayed / supposed to be HTML, thus it should do html-decoding.
Comment #6
useernamee commentedI've added html decoding. Thanks for review and testing, @fago.
Comment #7
useernamee commentedComment #8
fagothx, works great - but this should use https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Util...
Comment #9
useernamee commented@fago Thank you for your comment. I've implemented it.
Comment #10
useernamee commentedComment #11
fagoComment #12
fagogreat, works well now and code is all good
Comment #13
fagodiscussed with berdir that it would be good to add the possibility to ignore certain requirements from this checking via plugin configuration. as I understood there is some prior-art of this pre-existing in monitoring.
Comment #14
useernamee commentedI've implemented plugin selection in configuration form. It requires some not so nice detour for storing plugins so I am setting this issue state as needs review again.
The problem was that some plugin ids have dot in their id and that is invalid character to store in configuration so I've replaced dots with double underscore
and then convert underscore back to dot again:
Does anyone have a better idea/solution?
Comment #15
fagothanks. That underscore-workaround seems reasonable.
While the feature works fine, I don't think it's very practical to store a list of requirements-to-cover in config since it must be maintained and updated for every module with requirements being added. Instead I think we should only configure and store an ignore list, e.g. make the setting
"Requirements to ignore"
so when kept empty it would just use all. Makes sense?
Comment #16
useernamee commented@fago Thanks for your response! I've implemented the code you suggest.
Comment #17
useernamee commentedComment #18
ciprian.stavovei commentedEverything looks good now.
Comment #19
useernamee commentedI have to add some error checking in the code:
Comment #20
useernamee commentedComment #21
useernamee commentedError won't happen again.
Comment #22
Marko Cvetkovic commentedI have just tested this successfully!
I've created 2 requirements recap sensors - one for warnings and one for errors.
Comment #23
fagoI checked the PR and code + approach seems all good now. Also tested ignoring a requirement, works fine.
Comment #24
berdirThanks for working on this, this is interesting.
Didn't do a full code review, but some thoughts and questions:
* initialize_requirements_sensors() has a special case for update module because we have dedicated sensors for that and don't want to duplicate it. should probably be added to ignored sensors by default here?
* Similarly we have a special case for system cron requirements check because that too has a dedicated sensor
* the exclude settings on the existing sensor uses a textfield and a link on the verbose output to quickly add them. this uses options. I'm generally fine with that, but I could imagine a problem with dynamically define keys that are not always there. editing a sensor while that is not defined will lose that exclude.
* requirements checks can be quite slow and because you split be level, if you have error and warning sensors, you'll run them all twice. maybe add a static cache?
Comment #25
useernamee commented@berdir, thank you for code review.
I've implemented caching, improved disabled sensor config and added update and cron to default values (and tested that everything still works).
Comment #26
useernamee commentedI've improved caching and "improved" status message output as well.
I've tried to have html in the status messages in monitoring report, but this was simply to hard to achieve, because html is escaped in sensor list. Html still shows up in detailed view.
Comment #27
useernamee commentedComment #28
useernamee commented@berdir would you care to check my implementation of your comments? I'm not sure about the caching part.
Comment #29
useernamee commentedComment #30
useernamee commentedHello.
Any chance of getting this ticket reviewed?
Comment #31
fagocode changes look all good to me despite that small phpcs warning:
>src/Plugin/monitoring/SensorPlugin/RequirementsRecapSensorPlugin.php ✗ 1 more
>line 196 Description for the @return value is missing
also, we are using this for a while now and works all good. let's fix the phpcs issue, then I think this is ready
Comment #32
useernamee commentedI've fixed this phpcs issue.
Comment #33
petar_basic commentedThis now seems all good. As mentioned in #31 we are using this for a while now and works all good.
Comment #35
berdirSorry for the slight delay :)
Merged.