Plugin conflict with WP Retina 2x Pro, Error “Sorry, we’ve experienced some e..”

Wow, thanks for some great troubleshooting, @stuartmorrisau.

I’d like to try and replicate this situation myself to see if I can figure out what is causing it. Do you know if it reproduces with the non-pro version of the WP Retina 2x plugin?

I’m thinking I should also add some more helpful diagnostic info to that error message.

Hi @mlwilkerson,

Sorry I forgot to check that! Yes, the free version produces the same error.

Also, neither plugin triggered an error in the PHP error log, either upon plugin activation or when visiting the F/A settings page with both plugins enabled.

Hi @mlwilkerson,

I’ve done a bit more testing with this… I spun up a test WordPress install (5.2.1), FontAwesome and WP Retina 2x (free) plugins, and the Twenty Nineteen theme. I didn’t get any error message when I opened the FontAwesome settings page, so it looks like there’s something quirky with my WP install.

On my main site where I’m having this issue, the browser dev tools show the following with both plugins enabled when I open the F/A settings. I don’t get any such error on the test site.

JQMIGRATE: Migrate is installed, version 1.4.1????? load-scripts.php:8:542

TypeError: "t.options is undefined"???????????????? react-dom.production.min.js:3744
??? value?????? FontAwesomeAdminView.js:121
??? Yi????? [10]??? React
??????? Yi
??????? Qi
??????? eo
??????? No
??????? zo
??????? sa
??????? fa
??????? Ro
??????? enqueueSetState
??????? setState
??? value?????? App.js:39
??? j?????????? wp-polyfill.min.js:2
??? j?????????? wp-polyfill.min.js:2
??? f?????????? wp-polyfill.min.js:1

??? oo????? [10]??? React
??????? oo
??????? callback
??????? ii
??????? ri
??????? pa
??????? sa
??????? fa
??????? Ro
??????? enqueueSetState
??????? setState
??? value?????? App.js:39
??? j?????????? wp-polyfill.min.js:2
??? j?????????? wp-polyfill.min.js:2
??? f?????????? wp-polyfill.min.js:1

The WP Retina 2x dev advised this is due to Font Awesome using an ajax request to trigger the retina process that’s used by WP Retina 2x.

OK, thanks for the updates. That ajax request explanation doesn’t yet make sense to me, but it does give me a clue as to where to dig in with debugging. The requests we make from the plugin are just normal API calls to the WordPress REST API. If they are having an unintended side effect for WP Retina 2x, I’d think that points to a problem in the design of their code, rather than a problem with the ajax call we’re making. In other words, we can’t avoid making ajax calls–that’s just the normal way for client apps to talk to the WordPress server. But I’ll take a closer look.

I’ve not been able to reproduce this in my dev environment, using WP 5.2, PHP 7.2.18, and WP Retina 2x 5.5.5.

But here’s what I suspect may be happening, given the clues we have so far–just an educated guess:

– When the WP Retina 2x plugin is in some state, and
– When our REST Controller executes get_item to get the Font Awesome config data, then
– Some WP Retina 2x plugin code runs, such as in the wp_head action. Our plugin runs that as part of our detection of “unregistered clients”
– Suppose that WP Retina 2x code results in some unexpected error that our controller doesn’t handle quite right

If so, then the reason I’m not able to reproduce it in my dev environment, and the reason you see different behavior in one of your environments vs. another might be due to that WP Retina 2x state (different options, or whatever else that plugin does) that varies across these different environments.

Can you take another look at what differences in state there might be, and what situations result in this error?

For some reason all my comments on a similar conflict (as well as the author’s replies) were removed along with author’s replies. So here’s a brief recap.

I get the same conflict not only with Retina 2x, but also with Webcraftic Clearfy.
The error in console is different from what @stuartmorrisau posted:

react-dom.production.min.js:3744 TypeError: Cannot read property 'lockedLoadSpec' of undefined
    at t.value (FontAwesomeAdminView.js:121)
    at Yi (react-dom.production.min.js:3357)
    at Qi (react-dom.production.min.js:3348)
    at eo (react-dom.production.min.js:3507)
    at No (react-dom.production.min.js:4486)
    at zo (react-dom.production.min.js:4505)
    at sa (react-dom.production.min.js:4826)
    at fa (react-dom.production.min.js:4800)
    at Ro (react-dom.production.min.js:4681)
    at Object.enqueueSetState (react-dom.production.min.js:2796)

The response to the REST config call on the Font Awesome plugin settings page changes when either Retina 2x or Clearfy are activated.
With both offending plugins disabled I get this: https://pastebin.com/T20pfviM
With either Retina 2x or Clearfy (or both) enabled I get this: https://pastebin.com/D0w0MTk8

@finomeno Strange. I’ve never seen forum comments disappear like that. Thanks for re-posting for reference. The network request responses are eye-opening and give me some great clues for how to fix this.

@finomeno @stuartmorrisau

At least part of the problem here is that some unintended HTML output is being emitted in the response, in addition to the JSON response that our config REST controller is trying to return. That controller uses PHP output buffering to throw away the HTML that would otherwise be emitted by firing the wp_head action. We’re doing that to detect those “unregistered clients” (other themes or plugins that try to load their own conflicting versions of Font Awesome).

In my dev environment, that all works as expected. But I have seen unexpected behavior before when using PHP output buffers to try and capture and silence output. The output buffering features are at least partially controlled by the way PHP is configured (php.ini).

I’m curious if perhaps the output buffering settings in your PHP environment are different from mine. Could you let me know what settings are active for these settings:
output_buffering
output_handler
implicit_flush

Also, it would help to know the version of PHP you’re running.

If you don’t have another easy way to get that information, you could drop this into a theme’s functions.php to display those values in the footer of the page template:

add_action('wp_footer', function() {
	phpinfo();
	?>
	<p>PHP VERSION: <?php phpversion(); ?></p>
	<p>PHP ini output_buffering: <?php echo esc_html(ini_get('output_buffering')); ?></p>
	<p>PHP ini implicit_flush: <?php echo esc_html(ini_get('implicit_flush')); ?></p>
	<p>PHP ini output_handler: <?php echo ini_get('output_handler') ? "output handler present" : "no output handler" ?></p>
<?php
});

But probably don’t do that on a production site ??

Regardless, I’m making a change that I think will solve this problem. But still, I’d like to better understand if there might be PHP environment differences with output buffering that account for why I’m not able to reproduce the error condition.

PHP Version - 7.3.5
output_buffering - 4096
output_handler - no value
implicit_flush - Off
This is a shared hosting environment, so I can only change the PHP version and a limited amount of PHP options. None of the three options above are available in cPanel’s PHP Slector Options section.

OK, that’s yet another confirming clue. My environment has output_buffering = 0. Unfortunately, I still can’t reproduce it, even with changing that setting. But I think I have enough clues to make a change that I hope will fix this. I’m wrapping up the release now and hope you’ll try it soon to let me know if it solves the problem.

OK @finomeno I’ve just released a new version of this plugin: 4.0.0-rc10.

Could you upgrade to that one and let me know if it resolves the problem?

Thank you @mlwilkerson for such quick action.
Problem solved for me now.
I can get to the settings page now with both Retina 2x and Clearfy enabled.

On a side note, there’s a setting in Clearfy to load Font Awesome asynchronously. It puts the loading into a footer script like so:

<script type='text/javascript'>
/* <![CDATA[ */
var wbcr_clearfy_async_links = {"wbcr_clearfy-font-awesome":"https:\/\/use.fontawesome.com\/releases\/v5.9.0\/css\/all.css","wbcr_clearfy-google-fonts":"https:\/\/fonts.googleapis.com\/css?family=Montserrat:100,100italic,200,200italic,300,300italic,regular,italic,500,500italic,600,600italic,700,700italic,800,800italic,900,900italic,400,400italic|Playfair+Display:100,100italic,200,200italic,300,300italic,400,400italic,500,500italic,600,600italic,700,700italic,800,800italic,900,900italic"};
/* ]]> */
</script>

When that’s enabled, FA styles get messed up somehow, and only .fa icons appear, but .fas ones, like Instagram, don’t. I guess I should report it to Clearfy developers. Or is there something you can do to mitigate this?