Many poorly-built plugins return HTML from the JSON endpoints, which we obviously can't parse. There's no good way for us to deal with this, but we can have an application-layer error that indicates that the server is returning nonsense. It should contain the raw response so that the host app can log the error (and potentially provide a debug screen where users can see the HTML page their site is printing).
It would also be helpful to have a field for suggestions about what might be going on – for instance, this plugin is trivially detectable with a simple string search, and we could tell the user that it's interfering with API traffic.
Some other issues we could auto-detect with a signatures list:
- You're trying to connect the app to a WordPress site that's not set up yet (we can detect that the installer page is visible)
wp_die cases – it prints a pretty recognizable page, so we could say something like "Your site encountered an error" and show the error
Many poorly-built plugins return HTML from the JSON endpoints, which we obviously can't parse. There's no good way for us to deal with this, but we can have an application-layer error that indicates that the server is returning nonsense. It should contain the raw response so that the host app can log the error (and potentially provide a debug screen where users can see the HTML page their site is printing).
It would also be helpful to have a field for suggestions about what might be going on – for instance, this plugin is trivially detectable with a simple string search, and we could tell the user that it's interfering with API traffic.
Some other issues we could auto-detect with a signatures list:
wp_diecases – it prints a pretty recognizable page, so we could say something like "Your site encountered an error" and show the error