Something useful from WP 5.2 that could be incorporated in ClassicPress:
Have been working on a plugin conflict tester which could integrate this and would like it to support ClassicPress, but if I start integrating some of the new recovery features would like to make them CP compatible at the same time… so for that to happen the new recovery features would need to be merged into CP.
On a similar note there is also the Site Health check info:
I think there was a discussion on Slack regarding this. I will see if I can find it and move it here.
Yeah perhaps including the Site Health check tests and info is premature at this stage, seems from those notes it is still getting some improvements.
The recovery mode however is another story, this is something WordPress has needed for a long time, and maybe something that ClassicPress could adopt fairly easily.
The recovery mode has even more problems; never say never, but I’m not convinced it’ll be fit to include any time soon.
@invisnet, I agree that the WSOD is mostly useless, but do you have any example of it being actually harmful?
Mainly it’s just not fully thought through and still half - baked. One example is the email it sends - nothing in it to prevent phishing (slavco covered that on slack - don’t see him on here).
Slavco (Mihajloski) wrote about the security issue of this feature here. I think it has been patched, but, that’s just a guess. This feature is a nice gesture, but, as @invisnet noted, it just wasn’t completely thought out.
So, reading that article, an unpatched outdated version of WooCommerce with an already compromised Shop Manager user login, combined with the new recovery feature, then allows another user to have privilege escalated to admin? It really does seem a bit of a rare stretch, and don’t see how it is a PoC of anything.
I mean, I haven’t had the chance to delve into the actual recovery code, but from a casual read of what it does, doesn’t it send an email to an admin, that then only disables a plugin for that admin user when logged in with recovery mode on? How would that allow another user to escalate anything by triggering a fatal error? They still wouldn’t have admin access, thus no recovery mode access, thus no plugin would be disabled for them to get around meta cap filters. Am I missing something here?
Anyhow, I feel this is going a bit off topic. It’s guess it’s fine if it points to an improvement in the current recovery process - ie. how could it be done better in ClassicPress…? As I said I have been working on my own conflict / error recovery plugin, so actually a bit more interested that question than the current WP implementation, but there is certainly some overlap. Thoughts?
Not completely sure but on second thought this security PoC post may have been regarding the initial recovery mode behaviour which did not send an email nor then set a user cookie for recovery, which may have led to it being improved… :-?
I have seen it many times in the WP forums now. The site is working and then the Recovery mode shuts it down. What really happens is that there are a few cases where fatal errors are not in plugins or themes, and so the email isn’t sent. There are memory exhaustion and timeout errors that are being caught, and some could be in AJAX or REST or Cron. Some people never knew that they had a problem (error was not really visible) and are now faced with a generic message instead of most of a page.
But it is really difficult to judge because the WP 5.2 release has both the Recovery Mode and the PHP version bump.
Also, it’s not currently set up to handle more than one error at a time. Several people had this, because of changing PHP versions.
This has seen quite a lot of improvement since the question was asked, and it was a Feature plugin first. The Health Check plugin still exists for testing new enhancements and also it has a Troubleshoot mode that the Site Health feature doesn’t have, that is very useful.
There is a ticket to remove the score. (and today another ticket to put the score on the dashboard) There are also tickets for changing the severity of some of the checks and improving them.
I think this depends.
If there is an undefined method in a plugin that causes a fatal error, for example, it provides the URL and the line of affected code with some additional info.
It provides a link to recover your site and the link expires in a day.
But yeah, phishing is always a valid concern.
There are two tabs. One with the failed tests, with options to show the passed tests and one labelled “info”.
The info is a lot more useful than the score.
It provides info about the site, like the db prefix and basics like that.
It also provides info about memory usage and so forth.
Some of the checks replicate checks that are done by other plugins, but obviously not everyone has those installed.
It seems useful for users who have more than a passing interest in the running of their site, but who don’t want / can’t use cPanel.
No, the visitor message is generic. The email always has details. But if you don’t get the email, there was no benefit, and it was a detriment to show less to your visitor.
It started at 1 hour, then 4 hours, then they changed it to a day right before release. Phishing is not unique to this email…
I see you meant something different from what I initially understood.
Yes, the e-mails are not necessarily delivered every time the action occurs.
I’m not sure that I would want details displayed to visitors though…
In fact, I would have very good reasons to be very upset if it were.
But this would of course depend on the nature of your site / what you use it for.
Perhaps detailed notices can be displayed in an admin panel instead in such a design?
That is to say if the error did not impede access to the back-end.
Again, I mean something different than you understand. All I’m saying is that the email has the details. That is well and good. I do not want the visitor to see those details. But the visitor should see as much of your site as it is able to show. By using the shutdown handler, the site is not showing part of the page that it would have before (some people didn’t even know they had errors). All it shows with the handler is a generic message that there are difficulties, instead of the actual site (like the menu or as far as it would actually get before the error). The visitor is left with nothing, which is what it was designed to avoid (WSOD). My point is that there are cases in which it is a detriment, not an enhancement.
Ah, that makes sense to me 
(I was thinking something like an error code that you could quote for support.
Like “Reference: XYZ123 Please provide this reference if you Contact us [link]”, but with the XYZ123 being more descriptive and giving away more details about the error than the site owner might like it to.