Opened 5 years ago
Last modified 3 years ago
#49923 new defect (bug)
Change "Critical Issue" to "Recommendation"
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | critical | Version: | 5.4 |
Component: | Site Health | Keywords: | close |
Focuses: | Cc: |
Description
Why do you call this a critical Issue? (see screenshot please) I know, this is not new, but since 5.4 and the site health dashboard widget my clients get panic.
Someone who knows how to write and set the WP_AUTO_UPDATE_CORE constant usually also knows, what this does. And it's a very conscious decision to disable the automatic updates and do the manual updates instead.
And if this would be really critical, why all these constants and filters do exist?
This should be changed to a hint = "Background updates are disabled" or a recommendation = "To receive background updates, enable ..."
But never ever this should be a critical issue.
Attachments (1)
Change History (11)
#2
in reply to:
↑ 1
@
5 years ago
Replying to Clorith:
Hmm, although I would argue that you could filter out the tests if you're familiar with what you are doing... I do have a different thought here though.
Sure, for upcoming client websites. But past client websites where you don't have any access anymore ... most of my clients want to update and manage their websites themselves ¯\_(ツ)_/¯ but get panic with this new site health widget.
We could check if minor updates are still allowed to run automatically, if they can, the severity could be lowered to a recommendation, but having automatic security updates completely disabled should still give a critical error in my opinion, as unknowing users might have changed values based on recommendations without knowing what they do, while those that do know what they do and are aware may ignore the output of this check (or use one of the plugins that filters it away).
Thoughts?
If minor updates are allowed, you don't need any hint at all (or do I mistunderstand?)
A recommendation, when automatic updates are filtered out, is enough (imo). The hint text should be changed and explain more.
And it is no error. The filters and constants are valid.
#5
@
4 years ago
but having automatic security updates completely disabled should still give a critical error in my opinion, as unknowing users might have changed values based on recommendations without knowing what they do, while those that do know what they do and are aware may ignore the output of this check (or use one of the plugins that filters it away).
@Clorith
Mostly Updates with security patches also include normal bug fixes, which could cause some unexpected behavior on websites.
Yes, check if minor updates are allowed, and if not AND if it is a security update, then call it a critical issue with the hint, that the update x.x.x is a security update. In all other cases make it a recommendation.
#6
@
4 years ago
- Keywords close added
With the change made in WordPress 5.5.1 that reads both a true
and 'minor'
value for this constant as accepted, this should not longer be a problem, could you confirm this is the case for your as well?
The only thing to note is that if you are using a development version (for example a beta release), then any other value than true
is considered a failure, this is because things change rapidly during development, and there's no guarantee that changes during development have gone through the same rigorous security checks yet.
For example, using define( 'WP_AUTO_UPDATE_CORE', 'minor' );
, and if all other checks passed, it ends up in the success group, not being considered as a potential issue, or a recommendation that needs ot be addressed.
#8
@
4 years ago
Ahh, let me dive in a bit deeper then :)
The WP_AUTO_UPDATE_CORE
constant can have 3 values: true
, false
and minor
.
Depending on your install type, these values can have different behaviors, which I suspect is what led to this ticket. It should be noted that they will also change the descriptive text depending on that scenario
On a normal site (not using an early access version like beta or trunk), these are the statuses:
true
- Status is consideredGood
minor
- Status is consideredGood
false
- Status is consideredCritical
Critical text:
WordPress security and maintenance releases are blocked by
define( 'WP_AUTO_UPDATE_CORE', false );
.
So on a normal site, having it set to allow minor updates, or all updates, is perfectly fine.
On an early access site, such as beta or trunk, these are the statuses:
true
- Status is consideredGood
minor
- Status is consideredCritical
false
- Status is consideredCritical
Critical text:
WordPress development updates are blocked by the
WP_AUTO_UPDATE_CORE
constant.
The same rings true for the filters that can be used to block updates, they also have specific texts to identify if it's blocking minor updates.
#9
@
4 years ago
Hello @Clorith
thank you, I knew this :)
But my question remains the same:
Someone who knows how to write and set the WP_AUTO_UPDATE_CORE constant usually also knows, what this does. And it's a very conscious decision to disable the automatic updates and do the manual updates instead.
And if this would be really critical, why all these constants and filters do exist?
This should be changed to a hint = "Background updates are disabled" or a recommendation = "To receive background updates, enable ..."
But never ever this should be a critical issue.
Hmm, although I would argue that you could filter out the tests if you're familiar with what you are doing... I do have a different thought here though.
We could check if minor updates are still allowed to run automatically, if they can, the severity could be lowered to a recommendation, but having automatic security updates completely disabled should still give a critical error in my opinion, as unknowing users might have changed values based on recommendations without knowing what they do, while those that do know what they do and are aware may ignore the output of this check (or use one of the plugins that filters it away).
Thoughts?