Where is the remediation information?

Hiya,

The loopback tests use the same mechanic as is used by WordPress core, one of the things it’ll often highlight as potential pitfalls of it not working are things such as WP_Cron (scheduled posts etc), but some hosts implement their own way of running these that do not rely on loopbacks, and as such it may appear to be working until you use features that rely explicitly on it, such as the plugin or theme editors for example.

As for the REST API, that ones interesting, right now it simply tries to fetch a response from the REST API endpoint as an authenticated user, and if it gets a non-valid response, shows as a failed test. This feature doesn’t hold any remediation tasks yet as it was backported to the plugin from ongoing development because of it’s importance in the new editing experience going forward and in detecting potential issues early there.

If the REST API is working as expected for you, I’d love to get some more details here so we can look into why it’s a false positive on your end though!

What would be good to know is if you have any regular posts published, do you have any security plugins or custom .htaccess rules added to your site (the data from the Debug Information tab would be ideal).

An unsatisfactory remediation was to deactivate WordPress Contact Forms by Cimatti which solved both the REST problem and the loopback problem. This plugin has not had an update in quite a while and I’m looking for a replacement, but if you need a project, install the current version. I’m disappointed because it was a forms plugin that didn’t hold back the most useful features I needed as a goad to encourage the user to buy the annually renewable “pro” version. I’ve learned to stay away from plugins that are “lite” version because what we all want is behind the ubiquitous annual paywall.

This seems to be where the latest crop of Gutenberg block providers are going and thank you no, not falling for that clickbait. Atomic Blocks by example has been kicked to the curb but only because enough of the blocks are serially unstable as to make it a PITA. They are too soon in an environment that is sketchy at best. I haven’t verified this yet, but I think the parsing of block boundaries which are HTML structured comments are bewildered by incremental changes. Particularly so with nested blocks. This is a historical problem of relying on PCRE regular expressions that are not properly anchored. I can’t say that is the case here, but that is what it looks like when reviewing the code in the code editor.

I don’t know if the various vendors have their own name space that is centrally managed (think ICAAN) for ad hoc block elements, but if not the case this entire exercise is headed into a realm of chaos. I’m recalling the madness of DLL libraries in early versions of Windows (2.1) and VisualBasic.

Back to the original remediation question – even though the tests fail the processes do not. So for now I’m leaving the Cimatti forms tool in place.

And since I’m on a bit of a rant, well intentioned, I assure you, be very careful of committing to block vendors because if you over-commit and later find you don’t like them or they fold their tent, thanks to Gutenberg’s model you have hell to pay to undo all the content registered to that block vendor. Converting the flagged blocks to HTML is a fool’s errand.

• This reply was modified 5 years, 11 months ago by dpevents.