Add Doks theme

[amme2]

I may have done this the wrong way round... but I'm a bit confused about how/if it's possible to add a theme without installing Hugo (or dependencies).

[amme2]

Or indeed whether adding NetlifyCMS has added a different template?

[amme2]

Actually I am wondering whether it might be better to start again on a different computer on which I can install dependencies; slightly concerned my very old macbook might not cope with this though.

[amme2]

If you have time, would you be able to explain to me for future reference what you included in #2 and also how I could set up a theme and deploy rather less clumsily on another occasion please? I feel there is something fundamental I've not quite understood here.

I get that the code presumably runs where its deployed, so there's no need to have it installed locally and content could still be edited in a text editor. But I was confused/misdirected by the Doks introduction 'for novice to intermediate users' beginning with step 0. Install requirements. And similarly for other themes: Just the Docs for Jekyll 'can run on GitHub Pages’ standard Jekyll compiler' but Jekyll itself requires Ruby and so on.; also Geekdoc instructions begin 'install requirements' etc., etc.

Is it as simple as forking or cloning the theme repo, and if so why isn't this covered in any of the documentation as a quick option?

Only now do I notice there is a 'Deploy to Netlify' button on the https://github.com/h-enk/doks, but even then the Getting Started instructions below involve installing javascript packages. Are these two separate options?

Whilst I can (and do) make use of an array of personal computing equipment for various tasks that our locked-down corporate infrastructure forbids on my work laptop, where there are methods of publishing via github that don't involve installing software locally I'd like to understand them better.

Many thanks for all your help so far.

[chrisdaaz]

Yes. This was an interesting and somewhat surprising experience for me. I'm not sure what I did was necessary, but it worked, so that's OK I think.

One of the reasons why I recommended Hugo is that adding and removing themes are supposed to be easy. In my previous experience, one could install a theme by downloading the theme files to a directory called themes and change a value in the configuration file (theme: new-theme-name) and that was it. Two things happened with this project I didn't anticipate:

• The Hugo-Netlify-NetlifyCMS starter kit was not configured in a way that would easily allow someone to switch themes. The theme (victor-hugo) was tightly knit together with the NetlifyCMS configuration.
• The Hugo Doks theme has way more features than a typical Hugo theme. As a result, it requires NodeJS and has it's own set of commands and configurations.

In #2, I did this:

• Delete everything from the original project within the tw-hugo-cms folder (except the .git subfolder).
• Install Hugo Doks to see if it works
• Add NetlifyCMS manually and test locally
• Pull request

I think the takeaway from this is to start with a theme and progressively add features and customizations in small chunks. I shouldn't have assumed that themes are easily interchangeable. In general, you can migrate Markdown content files from one theme or static site generator to another, but it'd have to be done manually (copying and pasting files between directories). It seems that some of the nicer Hugo themes are starting to take for granted the huge number of dependencies they are adding by using things like NodeJS and Webpack (and the hundreds of node modules that come along). It definitely make it harder for non-developers like you and me!

re: installation requirements... Most users of static site generators prefer to install and run everything locally for development and testing purposes. This is not a requirement, but it's typical. I don't know why the forking/cloning/deploy-to-netlify/deploy-to-github pages options are not well documented. I think it's thought that most users will prefer to install and build/test locally. Projects like Wowchemy, CollectionBuilder, and JekyllNow demonstrate that this can be down without locally installing dependencies like Hugo, Ruby, Jekyll, NodeJS, and the like. I'm currently trying to make a project like that for publishing OER textbooks.

The challenges we're working through on this are normal, especially for the first time ever trying this. You may well decide that a WordPress or Drupal site is the better option for documentation, but hopefully this is somewhat interesting as a learning exercise. I've battled with static site generators for years, but overall they've completely changed the way I do my job (which is digital publishing) and think about technology, but I might just have an unusually high tolerance for technical documentation and unexpected errors. Personally, I think this stuff is easier and less confusing than working with XML-based metadata schemas.

[amme2]

Yes, it is interesting, I just feel like I am taking up a lot of your time and not doing much myself!

I guess I would also prefer to install and test locally if I could, but there are some circumstances in which that isn't possible - so it's good to know where there are other options.