Hi @telovitz can you provide any information from the web server logs when this occurs?
I have also done a clean set up using the current wordpress “latest” docker image with apache, running WordPress 5.2.3 and PHP 7.3.10 and I have not yet reproduced the problem.
-mike
While working on a new feature, I was reminded that when some plugin or theme emits output during wp_enqueue_scripts, it may cause this plugin to throw an error like this.
It’s a side effect of the way that I initially coded this plugin to detect conflicts. I’ve determined that the current method for doing that is unreliable, in large part due to this class of problems. In my understanding, themes and plugins should not be emitting output during wp_enqueue_scripts, and even if they do, my code should be capturing and handling it. However, in any case, this plugin shouldn’t experience such a failure in that situation.
So, I’m working on a change that will make this plugin no longer susceptible to that whole class of problems.
I’m curious, if that happens to be the same problem you’ve encountered.
The way we could confirm that is by using something like the network tab in Google Chrome’s developer tools. After loading the settings page for this plugin (and seeing the “whoops” failure message, inspect the server request whose URL ends with this:
font-awesome/v1/config
For example, it might be:
index.php?rest_route=/font-awesome/v1/config
Look at the response on that request. It should be JSON data. If it’s anything else, then we’ve found our smoking gun.
I suspect that you’ll find some kind of output from another plugin, possibly mixed in with the intended JSON response from this plugin’s REST controller.
Another benefit of inspecting that diagnostic information may very well be that you learn which theme or plugin is causing the problem, which could help you decide on a possible workaround (such as disabling that plugin, if you determine that it’s not essential for you).
Glad to hear it’s working so far.
As for potential conflicts:
I wonder if you drilled down as far in those docs as the section on setting up conflict resolution within your WordPress custom installation?
That section can guide you in adding code that will surgically remove each conflict, after you’ve run the detector and discovered the hash codes for them.
Admittedly, it’s even more technical, though I’ve tried to make it easier with code that can be copied and pasted from those docs. If you do see any conflicts, this approach is very likely to resolve them. It’s more powerful than the mechanism for resolving conflicts that’s currently available in the plugin (and is also on its way into the plugin).
