Well the first thing to establish is whether that folder exists or not. Easiest to look on the server but you can also look on the Integration > Storage Locations panel which will tell you if it exists and if it is writeable.

Assuming that it does then perhaps your server will not allow you to open the cached files so it may be best to trun off their use. Options > Global Settings – turn on/off the two CSS and JavaScript cache options. Then, of course, the system will not even look in that folder for them at all.

Thank you.

I looked in Integration – Storage Locations

I see the Location not Found and Write Denied icons.

All of the other integrations are green and they point to:

/wp-content/sp-resources/forum-…

But these two trouble makers point to non-existent directories (not by my doing!):

Forum CSS/JS Cache

/wp-content/blogs.dir/1/files/sp-resources/forum-cache

Gravatar Cache Folder

/wp-content/blogs.dir/1/files/sp-resources/forum-gravatar-cache

I clicked the Update Storage Locations button and nothing happened.

I then set Forum CSS/JS Cache to be:

/wp-content/sp-resources/forum-cache

and clicked the Update Storage Locations button and nothing happened.

So via SFTP, I added the /forum-cache/ folder and changed the permissions from 755 to 755 (which the other green folders have).

I clicked the Update Storage Locations button and again–the folder is still red.

The site is at WP Engine so I have some really good admin tools available. I used the WP Engine Reset File Permissions button, where they advise “(Properly sets your WP file permissions needed for normal operation. Use this button after uploading files via SFTP.)“. Then I clicked the Update Storage Locations button and again–the folder is still red.

So for now I’m following the advice to turn them off but I prefer to have green lights everywhere.

Update – I turned off CSS/JS Combined Caching in Options – Global Settings and clicked the Update Global Options button. But on the Integration – Storage Locations page the itemis still red and a message persists at the bottom of the page: “For Simple:Press to function correctly it is imperative that the above location errors are resolved” …so turning them off didn’t seem to turn them off.

I could not find an on/off switch for the Gravatar Cache Folder.

I tried turning CSS/JS Combined Caching off and on again and nothing changed.

– – – 

Update # 2 – because I need to get the most out of my time, and because I’ve got an SFTP session, this response, and several browser tabs open, I decided to try my luck with the Gravatar Cache Folder

/wp-content/blogs.dir/1/files/sp-resources/forum-gravatar-cache

…change to 

/sp-resources/forum-gravatar-cache

and the folder already exists in their and has files in it. And now the Gravatar Cache Folder is green.

So when I updated the storage locations the only red light is the Forum CSS/JS Cache folder.

– – – 

Update # 3 – I just gave it one more run through on that folder (again), top to bottom, with all the above steps and it is still red–even though it is turned off.

Any advice?

Thank you, 

Chris

Sidebar: It would be easier work if the Integration – Storage Locations text input field for each of the directories scaled to fit the page. Sadly they’re only big enough to show 1/3 of the directory path and even when my browser is half the width of my monitor the page has a huge gap that would easily hold the full path in view. From a use experience it adds more actions to each thing that needs to be done on the page.

You may have turned off the caching of CSS and Scripts but it still leaves the storage folder location available for use and it will still report a problem if it finds one.

So firstly – yes – if the install or upgrade is unable to create the folder (and that WILL be down to permissions) then you do have to create it manually. If we can not create it during install we will never be able to create it on subsequent tries so it needs manual intervention.

You also said that you ‘…changed the permissions from 755 to 755… ‘ so I am guessing one of those values is wrong! Bit 755 should be the target permission.

And if – after you manually create the folder and set it to 755 it is STILL unwritable then that means there is still a problem with permissions and it probably comes down to the UID/GUID settings which probably means the folder does not actually ‘belong’ to your user account. We have seen users have all sorts of access problems with wp-engine hosted sites before and as far as I can tell wp-engine like to really restrict their users to a very fine band of options. My guess is you will need to ask their support to heck the UID and GUID settings on all the folders under wp-content and especially all of those on and under sp-resources. Assuming they are incorrectly set then they will probably have to reset them for you. Annoying.

Hey, thank you for the support.

Yes, I did misquote the 755. In the SFTP session the permissions are 775, so that’s what I used on the new folder.

775 – /wp-content/

775 – /wp-content/sp-resources

775 – /wp-content/sp-resources/forum-avatar-pool

775 – /wp-content/sp-resources/forum-avatars

775 – /wp-content/sp-resources/forum-badges

775 – /wp-content/sp-resources/forum-cache

775 – /wp-content/sp-resources/forum-custom-icons

775 – /wp-content/sp-resources/forum-gravatar-cache

775 – /wp-content/sp-resources/forum-language

775 – /wp-content/sp-resources/forum-plugins

775 – /wp-content/sp-resources/forum-smileys

775 – /wp-content/sp-resources/forum-themes

As you know there are many other subfolders but those are the top level permissions.

I’ll work with WP Engine to find out why I still get the folder error.

Thank you, 

Chris

Please do let us know what happens next…