Hacking the JAMstack

Hacking the JAMstack

Do you follow the Reclaim Hosting Blog? If not, now is a great time to subscribe as the whole team has been doing intentional learning topics each month and as Jim reminds everyone, The blogosphere is hot! I caught some of this late since my life is practically consumed by the arcade these days, but I wanted to participate so I joined the most recent meeting where the group reflected on files and folder structures on a hosting server. This next month is all about WordPress and the topic is timely as ever as Lauren notes that we're thinking through things like documentation and presentation in the Domain of One's Own interfaces we provide schools.

But this post is not only about WordPress, it goes a bit deeper down a rabbit hole that I've only just this past week entered in which I'm learning more about something called the JAMstack. Now, the idea is not wholly unfamiliar to me. It's very much built on the idea of the headless CMS and Jim and I got a great introduction to that via Tom, Matt, and Jeff at VCU when they showed us how they were using a blog on RamPages to drive a public VCU site on a server they had no control over as a static site pulling content from the blog via API. Jim wrote about that at https://bavatuesdays.com/headless-at-vcus-alt-lab/. So what's JAMstack? Well the term refers not to a particular CMS headless or not, but rather the idea of running static sites where the content is pregenerated. So in other words instead of pulling content on the fly via API (which might be fast for a small site, but perhaps not so when the API gives you thousands of results with a lot of stuff you don't need), a JAMstack setup would have the entire site generated as HTML and any new publish action would trigger a rebuild of that site. The files can then be stored in a git repository and hosted via CDN for performance. No PHP, Node, Go, or any other language necessary to run the site making it screaming fast and easy as hell to host.

Going back to some of the ideas driving this, it feels to me like a long running goal since even when I was at UMW was this idea of how we could share documentation across institutions via some type of centralized repository. Could we have a Github repo with tons of DoOO documentation written in Markdown and allow folks to contribute there or fork it for their own needs but also allow folks who want to use it in WP to do so but also offer static site variants for other needs? Seems a lofty goal, but I have to believe some of this technology is staring us in the face. I mean if Hugo is good enough for D'Arcy who am I to question it?! ;) I'm also taking a deeper look at the work Alan did with CC on their certifications as I think there could be some interesting stuff there.

Back to the JAMstack because this post really is an initial brain dump of where I am and not a tutorial or fully fleshed out post at all. A couple core tools that many are using for this stuff:

It's worth noting that a static site doesn't necessarily have to give up dynamic content in this scenario. The key to pulling in dynamic content (say allowing someone to search a term on your site) is using APIs to poll that specific content and inject the results into your static site using Javascript. Another huge benefit to this is security. When the end user is only interfacing with your content via a static intermediary it makes it much harder for a potential hacker to decipher how they might get access to that content.

This is super early stages but what better use of blogging than putting it all out there as a starting point to bounce off of? I've got a lot of reading and writing to do this coming month but my goal is to have some type of use case with DoOO Documentation living in Github and being served up via a static site with authoring happening in WordPress and perhaps other places as well. Let's see how this goes!

Hacking the JAMstack

Hacking the JAMstack

Do you follow the Reclaim Hosting Blog? If not, now is a great time to subscribe as the whole team has been doing intentional learning topics each month and as Jim reminds everyone, The blogosphere is hot! I caught some of this late since my life is practically consumed by the arcade these days, but I wanted to participate so I joined the most recent meeting where the group reflected on files and folder structures on a hosting server. This next month is all about WordPress and the topic is timely as ever as Lauren notes that we're thinking through things like documentation and presentation in the Domain of One's Own interfaces we provide schools.

But this post is not only about WordPress, it goes a bit deeper down a rabbit hole that I've only just this past week entered in which I'm learning more about something called the JAMstack. Now, the idea is not wholly unfamiliar to me. It's very much built on the idea of the headless CMS and Jim and I got a great introduction to that via Tom, Matt, and Jeff at VCU when they showed us how they were using a blog on RamPages to drive a public VCU site on a server they had no control over as a static site pulling content from the blog via API. Jim wrote about that at https://bavatuesdays.com/headless-at-vcus-alt-lab/. So what's JAMstack? Well the term refers not to a particular CMS headless or not, but rather the idea of running static sites where the content is pregenerated. So in other words instead of pulling content on the fly via API (which might be fast for a small site, but perhaps not so when the API gives you thousands of results with a lot of stuff you don't need), a JAMstack setup would have the entire site generated as HTML and any new publish action would trigger a rebuild of that site. The files can then be stored in a git repository and hosted via CDN for performance. No PHP, Node, Go, or any other language necessary to run the site making it screaming fast and easy as hell to host.

Going back to some of the ideas driving this, it feels to me like a long running goal since even when I was at UMW was this idea of how we could share documentation across institutions via some type of centralized repository. Could we have a Github repo with tons of DoOO documentation written in Markdown and allow folks to contribute there or fork it for their own needs but also allow folks who want to use it in WP to do so but also offer static site variants for other needs? Seems a lofty goal, but I have to believe some of this technology is staring us in the face. I mean if Hugo is good enough for D'Arcy who am I to question it?! ;) I'm also taking a deeper look at the work Alan did with CC on their certifications as I think there could be some interesting stuff there.

Back to the JAMstack because this post really is an initial brain dump of where I am and not a tutorial or fully fleshed out post at all. A couple core tools that many are using for this stuff:

It's worth noting that a static site doesn't necessarily have to give up dynamic content in this scenario. The key to pulling in dynamic content (say allowing someone to search a term on your site) is using APIs to poll that specific content and inject the results into your static site using Javascript. Another huge benefit to this is security. When the end user is only interfacing with your content via a static intermediary it makes it much harder for a potential hacker to decipher how they might get access to that content.

This is super early stages but what better use of blogging than putting it all out there as a starting point to bounce off of? I've got a lot of reading and writing to do this coming month but my goal is to have some type of use case with DoOO Documentation living in Github and being served up via a static site with authoring happening in WordPress and perhaps other places as well. Let's see how this goes!

Hacking the JAMstack

Hacking the JAMstack

Do you follow the Reclaim Hosting Blog? If not, now is a great time to subscribe as the whole team has been doing intentional learning topics each month and as Jim reminds everyone, The blogosphere is hot! I caught some of this late since my life is practically consumed by the arcade these days, but I wanted to participate so I joined the most recent meeting where the group reflected on files and folder structures on a hosting server. This next month is all about WordPress and the topic is timely as ever as Lauren notes that we're thinking through things like documentation and presentation in the Domain of One's Own interfaces we provide schools.

But this post is not only about WordPress, it goes a bit deeper down a rabbit hole that I've only just this past week entered in which I'm learning more about something called the JAMstack. Now, the idea is not wholly unfamiliar to me. It's very much built on the idea of the headless CMS and Jim and I got a great introduction to that via Tom, Matt, and Jeff at VCU when they showed us how they were using a blog on RamPages to drive a public VCU site on a server they had no control over as a static site pulling content from the blog via API. Jim wrote about that at https://bavatuesdays.com/headless-at-vcus-alt-lab/. So what's JAMstack? Well the term refers not to a particular CMS headless or not, but rather the idea of running static sites where the content is pregenerated. So in other words instead of pulling content on the fly via API (which might be fast for a small site, but perhaps not so when the API gives you thousands of results with a lot of stuff you don't need), a JAMstack setup would have the entire site generated as HTML and any new publish action would trigger a rebuild of that site. The files can then be stored in a git repository and hosted via CDN for performance. No PHP, Node, Go, or any other language necessary to run the site making it screaming fast and easy as hell to host.

Going back to some of the ideas driving this, it feels to me like a long running goal since even when I was at UMW was this idea of how we could share documentation across institutions via some type of centralized repository. Could we have a Github repo with tons of DoOO documentation written in Markdown and allow folks to contribute there or fork it for their own needs but also allow folks who want to use it in WP to do so but also offer static site variants for other needs? Seems a lofty goal, but I have to believe some of this technology is staring us in the face. I mean if Hugo is good enough for D'Arcy who am I to question it?! ;) I'm also taking a deeper look at the work Alan did with CC on their certifications as I think there could be some interesting stuff there.

Back to the JAMstack because this post really is an initial brain dump of where I am and not a tutorial or fully fleshed out post at all. A couple core tools that many are using for this stuff:

It's worth noting that a static site doesn't necessarily have to give up dynamic content in this scenario. The key to pulling in dynamic content (say allowing someone to search a term on your site) is using APIs to poll that specific content and inject the results into your static site using Javascript. Another huge benefit to this is security. When the end user is only interfacing with your content via a static intermediary it makes it much harder for a potential hacker to decipher how they might get access to that content.

This is super early stages but what better use of blogging than putting it all out there as a starting point to bounce off of? I've got a lot of reading and writing to do this coming month but my goal is to have some type of use case with DoOO Documentation living in Github and being served up via a static site with authoring happening in WordPress and perhaps other places as well. Let's see how this goes!

Reclaiming Jekyll (Two Years Later)

Two years ago Tim wrote a great post detailing how you can get Jekyll up and running in shared hosting on Reclaim Hosting.* I’m late to this party, obviously, but playing with Grav recently led me back into Github thanks to the Github Sync plugin. I had explored Jekyll back in 2014 briefly (almost 4 years ago now, really?!), but I forgot most everything. I wanted to see if my Grav repository in Github (synced with my Grav install on Reclaim) would allow me to run the Grav files through Github pages (which is powered by Jekyll). Is this all crystal clear now? Good.

Turns out I was on a fool’s errand. Grav is a flat-file CMS, but it needs PHP to dynamically those pages as a site—which I should have understood. So it will not run on Github Pages.  Grav Sync is first and foremost for forking and collaborating on specific Grav instances (which I did understand), but I was trying to understand if those files could be seamlessly archived/translated into Jekyll given it was a repository, but I see my foolish ways now. Thank you, Tim ? So while you can bring up individual pages from my Grav repository on Github, like the Welcome page:

But the site functionality of my Grav instance could not be reproduced. Lesson learned. But this did peak my interest in synching my locally installed Jekyll on Reclaim Hosting with my Jekyll on Github. So, I asked Tim and he suggested the following:

I’m not sure the exact steps but it would involve setting up the repo in Github and cloning it to your hosting account and > then you could use git commands like git pull to grab the latest from git (even setup a cron every 10-15 min to do that piece).

Turns out that was the exact approach—I wish I was that good. I took the Github repo I have at jimgroom.github.io (which maps to jimgroom.me) and clone it into the jekyll folder on my Reclaim Hosting account. I made sure to run jekyll build in the jimgroom.github.io folder so that it would build the site files in the _site directory. After that I pointed the DNS of the subdomain jekyll.murderinc.biz to the new directory, i.e. jekyll/jimgroom.github.io/_site and the same site at jimgroom.me on Github is cloned and also resolving through my shared hosting account at jekyll.murderinc.biz. The two things needed to sync changes made on Github is running the following commands in the jekyll/jimgroom.github.io folder on my shared hosting (making sure you are logged into command line through your virtual Ruby environment):

git pull

and then

jekyll build

Pull in any changes and then rebuilds the site so those changes are published to _site. None of this is new by any means, I am just playing catch up. Adam Croom went down this road two years ago in order to stick a fork in the LMS using Github, and I can say from firsthand experience that wrapping your head around Github can be intense, but that’s no excuse for an ed-tech to give up:

“An Ed-Tech spends her life getting into tense situations!”
-A Github Repo Man


*This setup requires CloudLinux, which we have installed on all our shared hosting servers. 

Running a Jekyll Site on Reclaim Hosting

Running a Jekyll Site on Reclaim Hosting

This weekend I decided to experiment with a feature we have enabled on some of our servers that is sort of an unsung hero for advanced users (so advanced I hadn't taken the time to understand how it works!). Jekyll is a static site generator that has grown in popularity in large part due to its inclusion in GitHub Pages as well as a wider movement to have sites built from HTML based on Markdown templates. Plenty of folks today already run Jekyll sites but the process of using them with Reclaim typically involved generating the files locally on your computer and then publishing them to Reclaim because of Jekyll's requirement to run newer versions of Ruby than cPanel supports.

On many of our servers we now run a piece of software called CloudLinux. While the primary purpose of this software is to handle resource allocation (CPU/Memory/IO) per account, it comes with a stellar list of other features that allow a user to choose alternative versions of PHP, Python, and Ruby for their account. Python and Ruby are not languages I've played much in but I figured this was a perfect opportunity to see if I could install Jekyll and get it to run right inside my Reclaim Hosting account to remove some of the barriers to using it. And I'm happy to say I was successful! Here's how it works.

Looking at the requirements in the Jekyll install guide you'll note that Ruby 2+ is required (thankfully Jekyll 3 no longer requires NodeJS which would have been a dealbreaker here). So to start we'll create a Ruby application within cPanel under Software > Setup Ruby App

Running a Jekyll Site on Reclaim Hosting

For the version I've chosen the latest available here, Ruby 2.2, and setup jekyll folders for the application contents and the public directory.

Running a Jekyll Site on Reclaim Hosting

Click Setup and you'll have a generic Ruby application ready to go! Of course there's nothing there yet, it simply displays some basic information in cPanel and the URL shows a simple Hello World style page letting you know it's running.

Running a Jekyll Site on Reclaim Hosting

Running a Jekyll Site on Reclaim Hosting

The next step according to the install guide for Jekyll is to use the RubyGems installer to run gem install jekyll bundler. Here's where things get interesting. You'll need to login to your shell account for these next steps, something we include by default with our accounts. But if I just login and try to run that command I get the following error:

Running a Jekyll Site on Reclaim Hosting

This is because your Ruby application runs in a virtual environment that allows you to run different versions for different applications. So in order to work within our app we need to enter the virtual environment before doing anything else. If you look back at the application details a command was provided for entering the virtual environment, in my case source /home/towensne/rubyvenv/jekyll/2.2/bin/activate. So I'll enter the environment first and then run the command gem install jekyll bundler from there.

Running a Jekyll Site on Reclaim Hosting

Now we're cooking! We've got Jekyll installed in our account and should be able to use it to build a site. At this point I could grab a theme from somewhere but Jekyll also has a built-in site generator tool that can be used by running jekyll new myblog where myblog is the name of the folder you want it to create. In this case I'll navigate to my public_html folder (cd public_html) and run jekyll new blog to setup a blog folder for it. Keep in mind I need to stay in my virtual environment while doing this. The Jekyll command will not exist outside of it.

Running a Jekyll Site on Reclaim Hosting

Yikes, ugly Ruby error. But have no fear, this is a pretty straightforward one to deal with. Our Ruby app is complaining that it needs something called "bigdecimal" in order to run. Similar to how we installed Jekyll we can just run gem install bigdecimal to get that package in place.

Running a Jekyll Site on Reclaim Hosting

And now let's setup that blog again.

Running a Jekyll Site on Reclaim Hosting

Score! If we look at the blog folder in our File Manager we'll have a better idea of what this looks like. This isn't meant to be a comprehensive introduction to Jekyll by any means, but you'll notice lots of folders and files in there and this structure is essentially a basic Jekyll site.

Running a Jekyll Site on Reclaim Hosting

Now we've got our Jekyll site structure done but it's important to note that we haven't generated the HTML for the site yet. In fact if we go to towens.net/blog where I put this site you'd see just a bunch of code.

Running a Jekyll Site on Reclaim Hosting

We need to run Jekyll's site generator in order for it to convert all the markdown and templates into a static HTML site. This is done back in our shell session by running jekyll build (make sure you change to your blog directory)

Running a Jekyll Site on Reclaim Hosting

What this does is takes all those templates and turns it into an actual HTML site. From the printout you can see the site is generated in the _site folder (you can specify a different name for the folder using the --destination parameter, read more about the options at https://jekyllrb.com/docs/usage/). If we look at the _site folder you'll notice this looks a lot more like a regular HTML site than the Jekyll folder did.

Running a Jekyll Site on Reclaim Hosting

Our last step is to setup a URL for the generated files and for this I'm going to create a subdomain in cPanel under Domains > Subdomains. I'll give it the subdomain blog.towens.net and we know that the files we want to server are in public_html/blog/_site so I'll set that as the Document Root for the subdomain.

Running a Jekyll Site on Reclaim Hosting

Now if we've done everything correctly we should be able to load blog.towens.net and get our Jekyll site.

Running a Jekyll Site on Reclaim Hosting

Booyah! Now all we need to do anytime we make changes to the Markdown files in our Jekyll directory is running jekyll build to rebuild the site. It will update _site with everything each time. For extra credit it's possible to setup a cron job that will schedule and run a build every X minutes. The command would look like this: source /home/towensne/rubyvenv/jekyll/2.2/bin/activate && cd /home/towensne/public_html/blog && jekyll build (obviously you'd need to replace the first part with the command to enter your virtual environment and update the path it changes the directory to).

So that's it! Certainly more advanced stuff than just publishing via WordPress or something like that but I know a lot of folks who have been itching to try Jekyll or use it more with their account and this is a great way to run it as a Ruby application directly from your Reclaim Hosting account without having to do all the building locally and publish the files as an additional step.

Running a Jekyll Site on Reclaim Hosting

Running a Jekyll Site on Reclaim Hosting

This weekend I decided to experiment with a feature we have enabled on some of our servers that is sort of an unsung hero for advanced users (so advanced I hadn’t taken the time to understand how it works!). Jekyll is a static site generator that has grown in popularity in large part due to its inclusion in GitHub Pages as well as a wider movement to have sites built from HTML based on Markdown templates. Plenty of folks today already run Jekyll sites but the process of using them with Reclaim typically involved generating the files locally on your computer and then publishing them to Reclaim because of Jekyll’s requirement to run newer versions of Ruby than cPanel supports.

Continue reading “Running a Jekyll Site on Reclaim Hosting”