search

Moonshine-IDE / MoonshineWebsite

The website for Moonshine-IDE.com
4 stars 1 forks source link

Move Moonshine Website to GitHub Pages #21

Closed Aszusz closed 9 months ago

Aszusz commented 2 years ago

GitHub Pages supports Jekyll but not SASS. In order to move the website to GitHub Pages I decided to:

At some point I may want to opt out of SASS and even Materialize CSS framework completely and refactor to a lighter approach of Tailwind CSS for example.

Aszusz commented 2 years ago

I successfully moved the website to GitHub Pages. This required use of baseurl param in _config.yml. The value of this parameter needs to be:

All the links in the markdown and liquid templates were prepended either with {{ site.baseurl }} or appended with relatvie_url liquid filter.

Aszusz commented 2 years ago

What remains to be done:

Aszusz commented 2 years ago

@MarkProminic The table with all asset locations

Where it is Where it needs to be
https://moonshine-ide.github.io/MoonshineWebsite/ https://moonshine-ide.com/
http://199.103.3.72/downloads/ https://moonshine-ide.com/downloads/
https://moonshine-ide.github.io/MoonshineWebsite/download-sdk-installer/ https://moonshine-ide.com/moonshine-app-store-helper/
https://199.103.3.72/downloads/updater.xml http://moonshine-ide.com/wp-content/uploads/updater.xml
MarkProminic commented 2 years ago

I propose that for any URL that is loading from: 199.103.3.72, is set to use a FQDN of something like: prominic.moonsine-ide.com, or static.moonsine-ide.com, or some FQDN.

Then we edit the Links referencing the "/downloads" subdirectories to use the updated FQDN. Once all links that point to the old server using the old FQDN are adjusted to the new FQDN, we can move URLs that use "https://moonshine-ide.github.io/" to use: "http://moonshine-ide.com/"

When we move from a statically hosted source for the artifacts, to a CDN, we simply update the URLs of the links to point to the CDN URLs.

Aszusz commented 2 years ago

OK, I'm not sure if I understand everything but there is one thing I have to make clear. We cannot update some of the links as they are a part of the already released software.

So if Moonshine IDE 2.5.0 wants to access http://moonshine-ide.com/wp-content/uploads/updater.xml this is the location where it needs to find it.

MarkProminic commented 2 years ago

So we are tied to always having "wp-content" folder despite not running WordPress? We may need to submit an issue to fix that.

I was not aware of that direct link, are you aware of any others? This should be solvable with a subdirectory redirect. However I am finding it difficult on how to do redirects from subfolders in GitHub pages. The only way I know around this is to put a HAproxy server in front of GitHub pages, but that would defeat the purpose of moving to GitHub pages.

MarkProminic commented 2 years ago

Looks like Github pages does not support .htaccess or nginx style redirects, nor does it support generic 301 redirects, rather you have to use something like:

https://blog.netnerds.net/2020/08/url-shortening-redirects-using-github-pages-and-jekyll/

https://github.com/jekyll/jekyll-redirect-from

Aszusz commented 2 years ago

So we are tied to always having "wp-content" folder despite not running WordPress? We may need to submit an issue to fix that.

It doesn't have to be a folder, but /wp-content/ in the URL, yes. No fix can work backward in time. As long as we want automatic update detection for archived versions of moonshine we need to support this. At some point, it may be not worth the hassle but right now there are other hardcoded links so it's not the biggest issue. One thing I learned is URL need to be treated as permanent and designed carefully.

I was not aware of that direct link, are you aware of any others?

Most of the dependencies in the downloads folder are hardcoded like that. If the downloads folder will work from https://moonshine-ide.com/downloads/ they will too.

Aszusz commented 2 years ago

The only way I know around this is to put a HAproxy server in front of GitHub pages, but that would defeat the purpose of moving to GitHub pages.

Actually, I was thinking about doing exactly that, we even talked about it on one of our calls. But if there are other ways let's explore them.

MarkProminic commented 2 years ago

Reading further into the plugin and other GitHub Page documentation, wildcard/recursive/catch all redirects are not possible.

A meta refresh redirect, the method we are using here, loads the page, and uses something like HTML or JavaScript to redirect the browser to the appropriate page.

Since this happens at the page level and not the server level, we cannot forward entire subdirectories, we have to specify a redirect for every file in the directory.

If we know the names of the artifacts are always going to be the same, IE no version number appended in the name, this would work.

I think we should use the CDN, like Cloud flare, to manage this redirect for us, however we should have the appropriate ability to do other sorts of redirects that may be needed on the site now with the Jekyll redirect plugin.

If there are any on the site that you want to update. It should be as simple as copying the downloads.md to a unquiet file and replacing the permalink with the path they visit, and redirect_to with the URL you want to redirect the page to.

https://www.whatsmydns.net/?utm_source=whatsmydns.com&utm_medium=redirect#A/static.moonshine-ide.com

The static.moonshine-ide.com domain has been Lets' Encrypted, and it is mostly propagated now in case you want to use that domain to replace any of the ones on the Website to reference that. (I know this won't fix the end users clients update path, but it at least solves temporarily new users)

So before we move the domain over, lets focus on getting the CDN so that we can use it for the Redirects and for the distribution of files.

JoelProminic commented 2 years ago

@JustinProminic proposed something like this for the changing URLs:

This should be the URL for auto-updater: https://moonshine-ide.com/downloads/updater.xml For the purpose of this example, we'll assume that this needs to change to: https://cdn.moonshine-ide.com/downloads/updater.xml

We would update the Moonshine logic to use the original URL and failover to the new URL:

response = getPage("https://moonshine-ide.com/downloads/updater.xml");
if (!response.isSuccessful()) {
    response = getPage("https://cdn.moonshine-ide.com/downloads/updater.xml");
}

We would then release this update a week or two before we release the new Moonshine website. This would give active users time to update.

Once the website is updated, the new Moonshine build would failover to the new URL. Older builds would give an error, and the user would need to go to the website to download a new build. We could have a message at the top of the website to guide users like this.

Then, we would remove the failover code from Moonshine for the next release, once we are satisfied with the new website.

Of course, it would be better if we can get redirects working so that this isn't needed.

Aszusz commented 9 months ago

MoonshineWebsite is fully functioning on GitHub Pages