Failed to initialize filesystem usage - after upgrade to 5.0.1

[smoenkhoff]

After upgrading to Font Awesome on a self-hosted Wordpress site, I now receive the following notice at the top of the admin pages. I run a pretty restricted and locked down installation as far as what the directories the apache process can write to or not. If the new version requires a directory to be created or access to a specific directory, this may be the reason.

How can I resolve this issue and/or is there anymore information I can provide to help solve this fatal error message.

"The Font Awesome plugin caught a fatal error.

Failed to initialize filesystem usage for creating self-hosted assets. Please report this on the plugin support forum so it can be investigated."

[tagliala]

Hi!

Thanks for being part of the Font Awesome Community.

It is unclear to me which approach is being used here

Maybe this belongs to the https://github.com/FortAwesome/wordpress-fontawesome repo? /cc @mlwilkerson

[smoenkhoff]

@tagliala - is that repo for the wordpress plugin? If so, then yes, it probably belongs in there. When I went to to fontawesome website support, it only listed this location to place issues.

Please let me know and I can submit the issue over there.

[tagliala]

I've tried to transfer, but I couldn't. Anyway, let's wait for Mike's feedback, don't worry

[mlwilkerson]

Hi @smoenkhoff. Thanks for the report. Let's figure out how to resolve this!

Yes, the new version of the plugin does retrieve a stylesheet from the Font Awesome CDN, which is required for styling the new embedded SVG icons. (The main new feature of v5 is that the Icon Chooser embeds SVG icons directly into the page content in the Block Editor.)

In your scenario, is there a way--by some hook or filter--to enable the writing of this asset?

Or would it work for you if you were given instructions on how to put it in the right place, manually?

Or...if you don't use the Block Editor, would it work for you if you could add a filter that skips the fetching of this stylesheet?

Or is there some other way that would seem natural to you in your more restrictive setup?

Another possibility: this same resource could be loaded from the Font Awesome CDN instead of being fetched for self-hosting. In an earlier alpha version, I added a filter that could toggle whether the SVG stylesheet is loaded from the CDN or fetched for self-hosting. In the interest of keeping things more simple, I removed that, but it might be a difference-maker in your situation.

A problem I can foresee, though: one of the use cases I was targeting for this release is where customers want avoid Font Awesome CDN retrieval on front end page loads via visitor browser (as part of their GDPR compliance, for example). For those use cases, I wouldn't want to fall back to loading this stylesheet from a CDN. So, considering trade-offs...

[smoenkhoff]

Hi @mlwilkerson, Thanks for the reply.  If I know the file path that is required to be written to, I can add the necessary allowance on my side to allow the plug in to write it. I have done this for other plug-ins, so I'm not opposed to allowing it.  I just need to know the path for this. I completely understand about the GDPR / CDN requirements, as I have recently been changing and restricting more of my stuff and have had to put in exceptions for plug-ins that still pull from CDNs.  

[mlwilkerson]

@smoenkhoff if you're up for some bleeding-edge testing, you could try the pre-release of plugin 5.0.2-1 here.

Download the font-awesome.zip attached to that Release, and install it in the WP plugins dashboard by uploading that zip.

Does this work for you?

Also, this pre-release adds a filter for entirely disabling whatever the plugin does for Block Editor support, including this attempt to retrieve and store the SVG stylesheet.

See the notes on PR #243 for usage.

Do you use the Block Editor on this site?

[smoenkhoff]

@mlwilkerson, I think I may have found the original problem. I downloaded the pre-release and re-installed it (for some reason, WP would not let me re-install it, so I had to move the original plugins/font-awesome directory out of the way before selecting the 'replace current with uploaded' button).

I received the warning with detailed instructions on what to do for the missing SVG icon stylesheet. I went to the server's wp-content/uploads directory and realized no font-awesome subdirectory existed. Perhaps this is the original issue? The prior installation that I had didn't have the wp-content/uploads/font-awesome directory, as the server process should have been able to create the font-awesome directory within the uploads directory.

Interestingly, when I created the uploads/font-awesome/v5.15.4/css directory and gave 777 permissions to it, reuploded the pre-release again, it did not pull the SVG stylesheet down and put it in that directory (unless this only happens when the Block Editor is used?).

After manually copying it into the directory, I no longer get the warning.

# ls -ltR font-awesome
font-awesome:
drwxrwxr-x. 3 www-user www-grp 16 Feb 28 14:36 v5.15.4

font-awesome/v5.15.4:
drwxrwxr-x. 2 www-user www-grp 28 Feb 28 14:45 css

font-awesome/v5.15.4/css:
-rw-rw-r--. 1 www-user www-grp 6359 Feb 28 14:28 svg-with-js.css

My site consists of a mix of posts and pages from the Classic Editor and Block Editor. After they released the Block Editor I have solely been using it.

[mlwilkerson]

@smoenkhoff Thanks for the feedback.

The plugin does normally create the uploads/font-awesome directory, but only if we can initialize the WP_Filesystem object.

The specific error message you posted originally shows that it failed right there, before it ever attempted to create the uploads/font-awesome directory.

Thanks again!