Plugin settings page is empty

Thanks for the report. Would you be able to install a debugging version of the plugin to help us get better diagnostic information? That stack trace is not very descriptive, since it’s a production build, but I could provide a version that would be more descriptive.

Also, can you let me know if there are any network errors in the network control panel?

Also, if you willing to allow me to investigate on this site, or a staging site with the same configuration, we could coordinate that. Please don’t post any login information here in this forum. But you could contact Font Awesome support and ask for me, Mike: hello at fontawesome dot com.

Also, can you say whether it was working in your case for any of the recent Font Awesome plugin versions 4.0.2, 4.0.1, or 4.0.0?

If you’re able to install a development version of the plugin to try and getting some more descriptive diagnostic output, here’s the pre-release zip to try. Please note that this zip file is a bit larger than usual, a little over 2MB. So your php.ini settings might complain that this is too big to install by uploading. If so, you would need to increase your PHP configuration’s upload_max_filesize, or try to install by uploading directly to the appropriate place on your web server (such as via FTP), and unzip it there.

Hi @mlwilkerson

I went ahead to check for errors in the network control panel directly from the settings page (/wp-admin/options-general.php?page=font-awesome) and opened the lighthouse tab to generate a report, but during lighthouse’s tests the settings page content appeared/showed (the page reloads several times during the tests), so I went ahead immediately and enter my api key in order to use a kit instead of the cdn.

The reason I wanted to access the settings page was precisely to change to a kit because I was getting a 2.4+ seconds block from from the cdn, (gtmetrix-insights tests) now I’m getting a 242ms load time from kit.fontawesome.com which is a lot better.

The settings page is loading correctly since then. Also the js error dissappeared. Without doing anything else besides the lighthouse report. I had obviously reloaded that page many times before trying to get it’s content so it wasn’t just a reloading issue.

Sorry I didn’t get to use the pre-release.zip and I’ll rather don’t make more tests since it’s a production site. I had never used the plugin so I can’t tell about prior versions.

Thanks for your help!

Ok, glad to hear that it worked itself out.

A 2.4 second response from the CDN is also abnormal and unexpected. So that makes me wonder what else might be going on. (And my guess is that whatever it was, it will also go away as network conditions change.)

I’m also seeing this problem with an empty settings page. I’ve gone back through the various releases and the settings page last worked with v4.0.1.

I’ve tested 4.0.2, 4.0.3 and 4.0.4-rc1 and all fail. The error in chrome devtools is:

index.js?ver=4.0.2:1 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'call')
    at c (index.js?ver=4.0.2:1)

The error changes with 4.0.4-rc1 to:

Font Awesome plugin error when initializing admin settings view TypeError: Cannot read properties of undefined (reading 'call')
    at __webpack_require__ (bootstrap:68)
    at Module../src/Alert.js (Alert.js:1)
    at __webpack_require__ (bootstrap:68)
    at Module../src/ErrorFallbackView.js (ErrorFallbackView.js:1)
    at __webpack_require__ (bootstrap:68)
    at Module../src/ErrorBoundary.js (ErrorBoundary.js:1)
    at __webpack_require__ (bootstrap:68)
    at Module../src/mountAdminView.js (mountAdminView.js:1)
    at __webpack_require__ (bootstrap:68)

I will roll all sites back to 4.0.1 until resolved. Hope this helps.

• This reply was modified 3 years, 2 months ago by sfoxe.

Thanks for the stack trace, @sfoxe.

This appears to be a problem with Webpack trying to load JavaScript chunks. I think I hit this problem myself during development, and it was clearing my browser cache that resolved it. The same kind of issue shows up in various other plugins that use similar tooling as we switched to in 4.0.2 for bundling JavaScript. See here, here, and here, for example.

So one experiment you could try would be to just load it using a different browser than you normally use. Or you could use the same browser, but use a “private” or “incognito” window. If you know how to clear the site data for the particular site, you could do that too. Or in the Chrome console, on the network tab, you can click to “disable cache” and reload that way.

I’d be curious, if you try that, whether you see different results. In the meantime, I’m looking at changing the build configuration to name those JavaScript chunks more distinctly to avoid such cache confusions.

Here’s a 4.0.4-rc2 pre-release where the JavaScript chunks have (hopefully) cache-busting hashes in their filenames. If you’re able, could you give this a try with whatever browser was failing before?

Release 4.0.4 is out. Can you give that a try and see if it resolves this symptom?

Confirmed 4.0.4 resolved this issue. Thanks for being so responsive on this!