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?
1 Like
I am experiencing the same issue. This thread seems to be a bit old but no one answered.
Did you fix that?
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.
I’m sorry to hear about your issues with the files section, and I’m not sure how to deal with that - it all works on GraphQL and is likely a null value where a response is expected - otherwise it’s simply down to browser support and I find it unlikely that you’re using IE 10 
The system is tested in Apache, yes. Time & resource constraints make it difficult to test beyond the most common setup, and community effort and voice is very limited on the IIS front.
The email system however does suprise me. In terms of underlying technology both v3 and v4 will use PHP’s mail command by default. It is perhaps to do with php.ini settings differing between two installations that is causing you these issues? I know mail on Windows isn’t as straight forward as it is on a Linux based system, I know this from testing in Windows (albeit with Apache, sorry).
The new mailing system in CMS 4 though has compeltely changed since CMS 3 (and 2) where it was essentially a bunch of regular expressions making a few mediocre tests before calling PHP’s mail function.
In contrast CMS 4 uses swiftmailer.org to back emails - meaning addresses MUST be valid to the RFC identified in the error message you are receiving.
As with major version changes, APIs have also changed - setTo now requires a valid email address, and ONLY the address - it does not attempt to parse an address out of a string such as "somebody <someone@somewhere.test>" - note that even though this format is valid as a header, it is not a valid address. Also note that it uses angular brackets < > not parentheses () as parentheses are not valid, despite Microsoft based technologies insisting on formatting mail addresses this way. This has not changed, only that I think from faint memory the regex in v3 would allow for it (and correct it). The correct API to call in v4 is e.g. setTo($address, $optionalName) - separating out the two portions of the address.
To configure SMTP from within Silverstripe (not using PHP mail) there is documentation on setting this up
Hopefully these will solve your email issues. I believe the problems with the files section were resolved in a previous release a wee while ago, so it might be worth giving the upgrade another go 