Unfortunately, to get this to work I had to remap my site’s index.html file to a main.html file, because when I try to view the site at the index.html either by explicitly routing there or by going to the implicit view I am pushed back to the implicit view and given a 500 error.
Note that I cannot copy the index.html file to the site root i.e.,
What you’re doing now is the best way to do such a thing. We have plans to do better though, to do something like designate a cloud object (such as index.html) to serve as the “face” of any cloud directory, not just the $CloudRootDirectory.
Any idea what the timeline for this might be? I’m assuming it doesn’t have to be pinned to the standard Mathematica release schedule, being a Cloud feature.
Cloud software releases much more often than Mathematica (try CloudEvaluate[$CloudVersion, CloudBase -> "https://www.wolframcloud.com"] to check what the current version is and when it was built), and the Wolfram Language side to contact the cloud is largely contained in the CloudObjects paclet that is pushed to the public paclet servers at the same time that the cloud software is changed.
I can’t comment on release specifics officially, but I can say it is being actively worked on.
One final follow up on this. When this feature finally gets rolled out, whenever that might be, how will we know? I can’t say I really know where to look for an up-to-date listing of the cloud’s various features–or if such a (very useful) listing exists.
(1) if you visit a cloud object directory and do nothing else, it will show a page indicating it’s a directory, instead of giving the 500 Internal Server Error page.
(2) inside a cloud object directory, if you create a cloud object named index.html or index.nb, it will be served when the directory URL is accessed. The object can be any type (including an APIFunction or Delayed or FormPage), those are just the magic names to use. You need to additionally assign appropriate permissions to those objects (read for static content, execute for server-side WL content like APIFunction).
In future we will have support for specifying any cloud object, not just ones with magic names, but for now this should serve the purpose.
Example:
dir = CreateDirectory[CloudObject["directory-index"]]
CloudDeploy[ExportForm[Panel[
Column[{
Style["How to use a Directory Index in Wolfram CLoud", Large, Bold],
"",
"1. If you visit a cloud object directory and do nothing else, it will show a page indicating it's a directory.",
"2. Inside a cloud object directory, if you create a cloud object named index.html or index.nb, it will be served when the directory URL is accessed. The object can be any type (including an APIFunction or Delayed or FormPage), those are just the magic names to use. You need to additionally assign appropriate permissions to those objects (read for static content, execute for server-side WL content like APIFunction)."
}, BaseStyle -> Directive[FontFamily -> "sans-serif"]],
ImageSize -> 700], "CloudCDF"],
FileNameJoin[{dir, "index.nb"}],
Permissions -> "Public"
]
Wonderful! I’m glad this is up. I don’t really care about anything other than static HTML as cloud notebooks are still a bit too slow for me and I don’t have want to use cloud credits on APIs or Delayed or anything. But I’m glad this works now.
Has there been any progress on making the path to webpages less nasty? I can now use: https://www.wolframcloud.com/objects/b3m2a1/home which is great, but I’d really much rather drop the put my username in the subdomain path. As it stands I don’t think anyone not immersed in Wolfram World would by default believe that URL was attached to me.
I have a question, index.html files are now supported by cloud but I wonder how to use relative sources robustly. Obviously I can’t use /assets/logo.png because / refers to cloud base which will almost never be your index.html container.
One could use ./assets/logo.png and it will work when you start your app from {cloudbase}/something/myApp/ (index.html dropped) but the way index.html is supported makes {cloudbase}/something/myApp (without final /) a valid URL too. It will be found but it will be corrupted because lack of / means that ./assets points to /something/assets not /something/myApp/assets
So the answer is to use absolute urls, because at one point I need to evaluate/inject $CloudRootDirectory. Maybe I will use it one day but I was looking for something more suited for WL independent deployment methods.
I experiment with a project where except PC/EPC which will be a host, most of content is generated via webpack etc and only backend apis are WL based. So I can use $CloudRootDirectory but it would be neater to use relative paths like everywhere.
Will post my experiences once I’m back to that project. Thanks for feedback.
Making usernames in the subdomain (e.g. b3m2a1.wolframcloud.com) is good, but somewhat involved to develop, and from what I can tell there’s very little demand for it. We have our own reasons for wanting to do it, but it really is at least a year out.
That’s unfortunate, but I suppose not entirely surprising. The Mathematica user base has never struck me as particularly developer-y and this is definitely a feature that would appeal to developer types.
I guess it really is time to move on whenever I need to update my sites again. Thanks for all the updates over the past year or so.
Hi Joel, unfortunately I have a real reason to want this now that can’t be circumvented by just using GitHub Pages. I want to use the cloud to circumvent a security issue in GitHub Pages (can’t use true 302 redirects), but I can’t really ask people to install stuff from:
Like, that looks like a scam. I would never touch anything from that URL if I didn’t know that wolframcloud.com was WRI’s beta cloud platform and I’m willing to be most people don’t know that.
Are you sure it’s over a year off? I can’t see any other free solution to this problem.