Files management in CMS not working

silverstripe-4
Tags: #<Tag:0x00007f10cfd0abd8>

#1

Silverstripe Version: 4.3

Question:

I have a installation of v3.4 of the CMS running under IIS. I am finding that I am unable to access the Files section of the CMS. I am also unable to use any upload of file selection tools elsewhere in the CMS.

When I click Files in the CMS I get the animated SS logo and nothing happens. When I inspect the page in the browser I find a script error:

Uncaught TypeError: Cannot read property ‘match’ of null
at t.diff (vendor.js?m=1545146508:1)
at e.fetchQuery (vendor.js?m=1545146508:1)
at e.startQuery (vendor.js?m=1545146508:1)
at t.setUpQuery (vendor.js?m=1545146508:1)
at t.onSubscribe (vendor.js?m=1545146508:1)
at vendor.js?m=1545146508:1
at new f (vendor.js?m=1545146508:1)
at t.subscribe (vendor.js?m=1545146508:1)
at t.o.startQuerySubscription (vendor.js?m=1545146508:1)
at t.componentDidMount (vendor.js?m=1545146508:1)

Does anyone have any ideas how I can fix this?


#2

I am experiencing the same issue. This thread seems to be a bit old but no one answered.
Did you fix that?


#3

To be honest, like a lot of posts on this forum, the trail just goes dead.

In the end I decided to copy over my old 3.4 version of our site and use that. Not ideal, as I have to use an old version of PHP as well. It’s worth noting that Silverstripe 3.7.x under PHP 7 also works as it seems to be the last version to be on the old approach.

Something that almost never gets mentioned is the fact that the emailing functionality in newer versions of PHP / Silverstripe, with the local IIS SMTP server, doesn’t work, so if you want to use forms or user defined forms, you will need to get an older alternative mailer module (the name escapes me at the time of writing) that handles emails in a different way. It’s all to do with the way it builds some addresses. It can’t handle the Name (email address) format, and seems to just crash the SMTP or raise errors in the PHP log.

While I accept that, in theory, the Silverstripe should work under IIS, that fact is it has been tuned for Apache based systems (Linux, MacOS, etc) is evident.

Never more so than this change to the “public” folder approach. It is so clearly designed to make it easier for Apache hosting to work, which is fine if that’s what you need, but it lacks the flexibility if you want anything else.

While I acknowledge that IIS isn’t as popular as Apache in the web server world there is clearly still a market for it.

Finally, I don’t know about you, but under Windows I don’t seem to have much luck with the Composer tool. The old way of downloading a folder and putting it in the root of the site was so much more reliable!

Sorry for my mini rant, it’s a very frustrating element of what is otherwise an excellent product once working.