/help should redirect to latest documentation version

[carlosperate]

Not sure if this can be done directly through the Jekyll configuration file, or if we'll need to set up a redirect in a `/help/index.html' page.

[ZanderBrown]

Redirects on GitHub Pages & the plugins documentation

[carlosperate]

That specific plugin requires the page itself to have the redirect values, so the index.md file from https://github.com/mu-editor/help-pages would have to include that, and therefore all future git submodules in https://github.com/mu-editor/mu-editor.github.io/tree/master/help would include it as well.

We need a way to indicate "/help" to redirect to a specific page, rather than a page indicating it should also be redirected from "/help". Do you know of any pluggins that could do that?

[ZanderBrown]

No that i'm aware of.

Perhaps my JS snippet from #17 could be a solution? (not ideal i know)

[carlosperate]

yeah, if it wasn't possible within Jekyll the alternative would be the html redirect with that script.
I'm not a fan the idea of having to wait for a REST call, there is no good fallback without hardcoding an version number (like it is now).
Perhaps we could have a very small ruby pluggin to just check the folder names inside "help" and edit the html redirect with the latest version present in the documentation. It'd be really easy with something like Pelican, hopefully it is as well with Jekyll, but I've never really used it before or wrote any Ruby either.

[ZanderBrown]

Don't have a clue about Ruby & very little Jekyll experience.
Perhaps our local Jekyll expert @dannystaple has something to enter into consideration

[dannystaple]

I'll take a look at our options. As a GH page, due to github secuirty - we only get to use the plugins they have, and wouldn't be able to add our own Ruby code.

[carlosperate]

That's shame, but I guess it makes sense. Thanks for taking a look @dannystaple.

[dannystaple]

For more interesting functionality, the best thing may be to use Travis for an off-site generator without the same restrictions. You could then choose alternatives. I'd imagine putting the source into a branch so the Travis job can push output to the master. There may be a yml config way to specify a pages folder with an output alias so I'll look into that. It may mean putting help src into a _help folder.

…

On Sun, 23 Apr 2017, 15:51 Carlos, ***@***.***> wrote: That's shame, but I guess it makes sense. Thanks for taking a look @dannystaple <https://github.com/dannystaple>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAaDaxvDbjE6MdbdpRjwqms18pREUcodks5ry2V5gaJpZM4NFFgx> .

[carlosperate]

To be honest I'd rather go for a simpler version of the current build system rather than adding even more layers with Travis also having to get secure push access to this GH repository. If things are going to get complicated we could go back to have the latest version string hardcoded in a file that can be accessed from javascript. After all, we still need to add a new submodule for each new release, so editing a string somewhere is not that bad.

[ZanderBrown]

Is there anyway we could setup a directory listing style page?

[dannystaple]

I'm trying something now (locally) - I think a collection might be the key to this.

[dannystaple]

Nope - no dice, "The folder must be named identically to the collection you defined in your _config.yml file, with the addition of the preceding _ character." - I was hoping I could rejig it to point help at a subfolder. Frustrating that input_dir -> output_dir mapping is that inflexible.

Can we come at this from another direction? Since we must update submodules anyway, could we use an additional submodule "help/current" which is updated to a recent release when that is required. The help/version_no submodules would still be in play.

[carlosperate]

Done in #20.