Solstice

In short, instead of just making my own website, I wanted to make a guide on how to make a website in a way that I felt people without the time or energy to learn some of the more technical aspects of the process could easily follow along with. Not just for setting the website up in the first place, but also for using it on a regular basis. The biggest thing I learned in this process, having never actually set up a website, is that there are many, many ways to do it. The way I did it may not be the way you want to, but I'd suggest skimming it over, particularly the "Using Grav" section, to see if the look and feel is what you're after. If you don't like the look of that, I ended up breaking out a section about alternatives into its own post here. You should look at those and see if they're a better fit.

My guesstimate is that this process is about 3-4 hours from front to back (pending someone actually using it to confirm), including carefully reading everything and what not. But once it's set up, there's not an awful lot you need to remember or maintain. This guide is kind of long because I wanted to try and answer a lot of questions and point out as many pitfalls as possible. I hope it's useful.

I wanted to be able to create a website without touching any HTML or CSS, but still have full control over the site itself. The basic goals are:

• A mostly or entirely statically loaded website, avoid JS as much is reasonably possible.
• A main intro/directory page, for anyone landing on the URL.
• A Blog for Posting.
• An RSS feed.
• And a gallery, because I really want to see people's art and photos.

And my goals for using the website:

• Avoiding any platform that would make it difficult to stand the website up elsewhere in a hurry.
• I don't want to mess with any HTML or CSS, or avoid it as much as possible, ideally just Markdown instead.
• Avoid weird workflows that would be easy to forget if not done for a month or two.
• And, crucially, I want to be able to post from mobile. I know too many people who do this.

This entirely rules out static site generation, as you can't reasonably do that from a phone. I still like the feel of a static or mostly static website, but I don't actually want to hand write it. Managing it from a phone means a Web UI with a login, which effectively ruled out any hacked up solution made by me for security reasons. I still want some control, but I don't want to get too deep into it. So, sort of like wordpress...

Sir, a second hammercar exposion has hit Matt Mullenweg. You know, the CEO of Tumblr and the guy that made wordpress.

We will not be using wordpress. I ended up settling on Grav. Grav is a "Content Management System", which is... basically what wordpress is. It's just a software stack, which runs as part of a web server (Apache and PHP, but without a database requirement in Grav's case) and we can get that webserver however we want.

The upsides of using it are: Getting it setup on a web server is relatively easy, its lower resource usage than other CMSes, and once it's set up we can do everything from the web UI. Even on a phone.

The downsides are, it's still a complex tool with plenty of pitfalls, oddities, bugs, and other weird things. My goal is to try and point out those problems and help you avoid them.

Here's a high level overview of this guide

1. Set up on a hosting provider. I'll be using NearlyFreeSpeech.net (NFSN) since it manages a few of the setup problems away for us, and it's cheap (probably a dollar or two a month).
2. Install Grav, which consists entirely of copy and pasting commands into NFSN's web UI.
3. Setting up and using Grav.
4. Talking about alternatives (which got made into its own post).

But first we have step 0: showing you what the end result will look like. What websites made with Grav actually look like depends entirely on what Theme you use. Here's three of them:

The first is Quark. This is the default theme in Grav, and as you can see it is designed for single page websites. Maybe I missed something with how it works, but it didn't really want to make anything particularly blog looking for me. I didn't dig too much because I'm not a fan of how it looks personally.

The second is Quark Open Publishing, a custom version of Quark that does blogs as I expect. You make a blog page and child pages for posts, and they all populate automatically. Its got a lot of other plugins too for things like search and embedding and all sorts of stuff. This is nice, but was not what I was after.

The third is Hypertext. This is what I'm after. Very basic layout, but presents almost everything I want. There's some basic options for colors and fonts, and if one wanted to start messing with CSS for those things it's very easy to do so. No JS involved, auto populates blogs, etc etc. Yes, those CSS options are basically Themes within the Theme, it's a little confusing. I'll just call those "stylesheets" from here on out, just in case.

Also, here's the website I've made. I've intentionally kept it minimal effort for now. www.plumpan.net

So now you have an idea of what the site is going to look like. If you really detest how it looks and don't like any of the stylesheet options, aren't interested in either modifying Grav's theme files, or otherwise playing with CSS to fix it, go ahead and skip to the alternatives. Keep in mind that once you have a site set up, changing the Grav theme can potentially break stuff, and everything in this guide is based around the Hypertext theme.

But if this looks and sounds like what you want, then keep reading from here.

Hosting Options

TL;DR go here https://www.nearlyfreespeech.net/signup/ and expect to pay a dollar or two a month, not counting yearly domain renewal fees. You can do everything without the domain for free (and no payment info) if you just want to try it out.

There are lots, and lots, and lots, and lots, of hosting providers. They generally fall somewhere between being "Unmanaged" and "Managed". Unmanaged is, here's your login info to a *nix box somewhere, have fun. Managed is, press some buttons in your web browser and this box will magically have all of the software you want already running on it and somewhat set up. Obviously managed solutions tend to cost a bit more, since they take less work.

The one I decided to go with is NearlyFreeSpeech.net. I first heard of them here on Cohost, and despite the name they're not some fucko right wing shop. The name does work both ways, they're quite cheap and also proponents of allowing any legal (in the US) content to be hosted there, along with a strong privacy policy. Here's another post about that, for full disclosure. It's not an ideal policy, but I don't think any other hosting provider is going to do much better honestly, so they're my pick for this. (More about other options below)

Their payment system is basically pay-per-use but also pay-up-front. You deposit money in and the site runs until your money runs out. I haven't ran my site long enough to know for sure but the pricing estimator puts me at around a dollar a month, not counting a yearly domain registration (Assume around $20, but optional if you REALLY want to save the money and don't mind not having a "personal" URL). If something happens and the website suddenly gets slammed with traffic, the worst that happens is the money in your account gets used up sooner and you can decide what to do from there. I think the minimum deposit is 25 cents USD so it should be pretty low stakes.

As far as the technical side goes, they have enough Managed stuff going on that everything Grav needs is already on the box ready to go when you create it. They have a "run command" option in the web UI that we can abuse to do all of the setup without having to SSH in. It's almost as easy as possible.

The signup process is laid out pretty clearly on the site here. The only real downside is they do require your legal name. They do let you put in your Real Name if they don't match, which is nice, and have a strong policy against disclosing personal information regarding people using their service unless legally compelled (by US law) to do so. If you're following along at home, skip anything about setting up a domain for now, we'll do that after the site is up and tested. You can do everything up to that point for free as well.

If any of that sounds particularly off-putting, some of the larger bit barns to look into would be, in alphabetical order: DigitalOcean, DreamHost, Linode, Namecheap, and Rack9. Namecheap specifically I've heard of other Cohost users using, and while much more expensive (think like ~$10/mo), they offer a heck of a lot more support, managed services (such as cpanel), and other bells and whistles. Rack9 has a basic plan with cpanel for like $3 a month, which sounds really good? Some services will specifically help you install Grav easier too. I've not used any of those personally, so YMMV. If you have nerd friends with websites, ask what they use. I can not stress this enough: there are so many hosting options out there.

Spec details: Obviously Grav wants Apache and PHP. You can get more details about versions, settings, and modules from their requirements page here. It can run on other webservers, but that's more work, so just use Apache unless you want more work. I also used Composer for the install process, For me I used about 200mb of disk for specifically Grav (including a site backup, which was ~55 of that) and everything it wanted. I'm not super sure about ram use but it looks like a couple hundred megs or so. You should be able to run Grav on whatever the cheapest option for hosting available is, more or less.

If you want to try and make this a Project and get Experience for your Resume, you could look into AWS (Amazon Cloud), Azure (Microsoft Cloud), or GCP (Google Cloud). I think most of these have some sort of free or cheap tiers but there's a ton of gotchas involved, risks of huge bills if something goes wrong or you get a ton of traffic, and they're also just a big pain in the ass to use if you're not a professional IT person. I say this as someone who has used all three professionally. Figured I'd mention it here but these are the worst option for most people.

Also I'm going to call Nearly Free Speech dot Net NFSN from here on out.

NFSN site creation

At this point I'm going to assume you signed up and have an account. And that you read about the difference between what they call a "Membership" (an account specific to your legal name) and an "Account" (the part you put money into and run websites from). It doesn't really matter a lot since we're just making a website for ourselves, but it's good to keep in mind.

When you go to the sites tab without any sites yet, you should be prompted to create a new one. You'll be asked for a shortname. This will be part of the URL if you don't yet have a domain, i.e. it will be sitename.nfshost.com. Pick something you like so you can use that name publicly before you get a domain. After you enter the name, assuming it was unique, you'll get a few default options. The only one you want to change is "Site Plan", set that to "Non-Production". If for some reason your website is actively Making Money, it's about a dollar a month additional roughly, so it should pay for itself pretty quickly. But one can always change that after the site is up and running. Everything else can be left default, we're using Apache and PHP so that's all good to go.

For now we're going to avoid anything related to domain names, since we can set everything up and do testing without putting any money in. We get two cents of credit to use with a new account, and that's all we need.

Once you've got your site set up, go to the site page (the leftmost URL on the table). You'll see a bunch of stuff that you don't need to worry about for now. Give it a minute or two and refresh the page, any red, orange, or blue text should now be green. Status, down at billing information, should be "Normal". This means the server has been set up and we're ready to start doing stuff.

Now if you know what a SSH is and you're comfortable doing that, you should SSH in now. All of the info you need is in the SSH/SFTP information table. If you wish to set up an SSH key, you do that in your profile, not on the site page.

If you don't want to to mess with SSH, there's a text button over on the right side that says "Run Shell Command". Go there. We will be running everything as "me", which should be the default option. The bad news is we have navigate back to this page a few times, but the good news is we only have to do the whole process once. If you're in SSH you can just chain all of these together with && and paste it in as one big blob, natch.

I'm going to list these out with info about what they're doing, for your own enrichment. Just copy the command text without the surrounding `s. Be sure to copy everything inside the ticks!

composer -q create-project getgrav/grav /home/public/ Composer is already installed for us, so we just tell it to grab Grav and dump it in our webroot, which is already being served by Apache

At this point it's good to wait a minute or two, just to make sure that's done running. We've no real visibility into progress doing it though the web UI like this unless it errors out. After a minute or two, you can run the following commands back to back:

sed -i '' "s/# RewriteCond %{HTTP:X-Forwarded-Proto} https/RewriteCond %{HTTP:X-Forwarded-Proto} https/" /home/public/.htaccess This is a big messy command to un-comment one line in a file. See the member's only wiki page here

sed -i '' "s/# RewriteRule .* - \[E=HTTPS:on\]/RewriteRule .* - \[E=HTTPS:on\]/" /home/public/.htaccess Same thing again, different line.

chown -R $UID:web /home/public/* Permissions fixing, also from the same wiki page. Only difference is we're using the $UID variable to avoid finding out what our user ID is.

find /home/public/. -type f -exec chmod 664 {} \; && find /home/public/bin -type f -exec chmod 775 {} \; More permissions fixing again. There's a character limit for running commands from the UI this way, but since these are short we can run two steps at once this time.

find /home/public/ -type d -exec chmod 775 {} \; && find /home/public/ -type d -exec chmod +s {} \; Final round of permissions fixes.

touch /home/public/favicon.ico look it's a long story, don't worry about it.

At this point it's good to wait a minute or two again to let all of that wrap up, those commands iterate over the entirety of the Grav install and while not too big, it has a lot of files to go over. Then, finally:

cd /home/public && bin/gpm -q install admin This installs the "admin" plugin in Grav, which is the Web UI control panel.

After a minute or two, that should have finished running. And we're practically set.

A final optional step. For Reasons, there is a file upload size limit in Grav admin. This limit is not set in Grav, but rather in PHP, so it can't be changed in Grav itself. In NFSN this is set to 10MB by default. If you never plan on uploading a file larger than that, you don't need to do anything. If you do, you'll want to do this:

printf 'upload_max_filesize = "100M"\npost_max_size = "101M"' >> /home/conf/php.ini && chmod 644 /home/conf/php.ini This sets the upload limit to 100M. You could make this larger if you want, but consider the bandwidth implications of other people downloading files that large. 10M should be fine for most users.

From here on out we can do Everything in the Web UI for Grav itself.

Grav Setup and use

Setting up the site itself

So now if you go to the site URL, you should be greeted with a page asking you to create an account in the Grav user panel. The email address doesn't matter, but go ahead and fill out the rest.

Once that's done, first thing to do is go to the themes option on the left side, then add in the top right. Search for hypertext and install it. Then click on themes on the left again (yes instead of clicking Activate on the page you were on, it's bugged) and click on the big activate button. Now we're using the theme.

Now we'll go to the plugins section and do the same to install the "Feed" plugin. This generates RSS feeds with 0 effort on our part, which we want. You might want to come back here later and click on the plugin to configure some options, but they're all pretty straightforward.

Next you probably want to name the site something. Go to configuration on the left, then the site tab in the middle. There are a LOT of options in the configuration, most of which we don't need to worry about. You probably want to change the Site Title and Default, and change or remove the Default Email and Metadata description.

Taxonomies are basically a grouping system. The names here are arbitrary and they all behave the same way, so if you just want "tag things and be able to see groups of posts by tag", then you can just remove the "category" taxonomy here and leave "tag". Or leave both in, having unused ones doesn't really cause any problems.

A Correction: This is normally how they behave, but with Hypertext specifically, it has the option to show Taxonomies named "Category", the default first option, linked at the top of posts. What this means is, you'll probably just want to use Category, because you can turn that option off with a switch.

You'll also want to go back to the "System" tab real quick and go set the Timezone. If you don't do this, the system will assume you're in UTC and might say, publish pages early. Or late, depending on where you live.

And hop into the "Advanced" section for just a moment (yes I know another one I'm sorry) to go set "Force SSL" to "Yes". This may not be needed on other hosts, but on NFSN I had issues with direct links to images breaking without this.

And that's basically all of the important setup done. Below are some OPTIONAL steps, but they are recommended.

First is to change the URL that leads to the admin page. Click on the Admin Panel plugin from the plugins page, and change the "Administrator path" to /something. Something can be whatever you want, as long as you remember and/or bookmark it. Be sure to save in the upper right again after doing so. This changes the page the admin login lives on, so it's less likely an automated tool will find it and attempt to break in.

Second is to make the failed login timeout more aggressive. This works for all logins, not just the admin panel, but that's the only one we're using so it's one and the same. Go back to Plugins, then Login, then the Security tab. We want to change "Max logins count" for number of failed logins allowed and "Max logins interval" for how long the cooldown is. I set these to 3 and 900, but since I'm using a password manager that autofills my login info, I could go even more aggressive since I should never actually fail a login. You should also use a password manager. This step is doubly important if you decided not to change the admin page above, otherwise it's more an abundance of caution.

Third optional step is to go to the Accounts section to create a user that only has Page permissions, so basically a posting only user. Click add user in the top right, then fill out the username, email (again, placeholder if you wish), password, and full name fields. Then scroll down and set the following two fields to "Allowed": Login to Admin and Pages (which enables its sub options). Then save at the top right. This user would be ideal to be the one to use on your phone.

Final optional step is to turn off Sessions. Nothing in this guide uses this, since we're more or less building a static site, so we don't need it. This also has the advantage of removing all cookies from the site for normal users (admin UI still uses some, obvs). Just go to the Session option under the System tab and set Initialize Session to "No".

Making Pages

And with that all of the setup is for sure, finally done. Now we actually go make some web pages. In the pages section.

This is where you actually create Web Pages on the website. You should start out with a "Home" page, a "Typography" page, and a "Root". Ignore Root. "Typography" is a demo page showing markdown examples. Home is similar, but it's already set up to be the page you see when you go to the site, and it's easy enough to just go edit it to be your own home page.

I'm going go walk through setting up a blog page for posts, a rost page for techically-but-not-entirely-RSS-only posts, and a gallery page.

The workflow for pages is the part where things can get a little confusing and annoying. If I had the ability I'd try and modify grav-admin to streamline this but... I don't. I'll try my best to go over the not-obvious things.

First, we'll make a page for a blog. From the pages section there's Add button in the top right.

When you name the page, the folder name will auto populate for you. The "folder name" is how the URL will show in the browser, and the folder is where our actual posts will live. In Grav the page templates are defined by the theme, and Hypertext specifically has a lot of templates that are all aliased to the same thing for compatibility with other themes. We will use "Blog" for the main blog page, and "Blog Item" for posts within it.

Ok here's the first big stupid thing: In my testing, the visibility option in this window does not work the way you expect it to. You should probably pretend it doesn't exist. We're going to be manually setting this soon.

Now we're at the page editor. Here's the important things you need to know here that aren't obvious:

As the page says at this point, the page does not exist until we save it for the first time. Because of this, for Reasons, we also can't add media (read: pictures) yet. This sucks, and the solution is to just save a non published post and then edit it properly. To do that, we'll hop over to the options tab:

Taxonomies is the other important thing here. These are just arbitrary items you can assign to pages, and work more or less like tags on Cohost. You assign a tag to some posts, and you can view all posts under that tag in a single group. What groups you have here depend on which ones you set in the site settings earlier. Also, any fields left blank won't show up at all, so don't worry about filling something in here if you don't want to. Since this is just the main blog page, we'll leave it blank.

There's also options here for the listed Date, as well as dates to auto publish or unpublish pages. If you plan on sorting your blog in chronological order, you'll want to check the Date box and click in the field when you first publish a post within the blog, which will autopopulate it with the current date and time. If you don't do this, the date value will be the last modified time of the page, which means editing it later on will change the date. Better to set it ahead of time.

There is a plugin called "Auto Date" that literally just does this for you every time you make a new page. You'd probably prefer to use that than remember to check a box.

Next we'll skip to the Hypertext tab, which is a tab for theme specific settings.

The important thing here is the "Children & Ordering" section, which defines how child pages are displayed. By default they sort by folder, which is alphabetical folder order. This is useful if you use the "Folder Number Prefix" option, which we'll talk about in the advanced tab. The problem is it's set to Descending by default, which you probably won't want. So you may wish to change this to Ascending.

Or, you may wish to sort by Date instead, in which case Descending is what you want. Just be sure to be using the Date field in the Options tab along with this, or again it will change the order based on last modified. (see comment about Auto Date plugin above)

There's a lot of other knobs to tweak here, you can play around with them after making a few test posts if you want. For now this is enough to make the main blog page, so we'll go back to Options, set Published to Yes, and also go to Advanced and set "Visible" to Enabled, and save. Why both? Sometimes Visibility is bugged and I don't know why, so best to explicitly set it every time.

So now we have a blog page, but no posts. Since we're still in the editor for the main blog page we just made, we can use the "add" button at the top to create a page within this folder. The only difference between using the add page button here or on the main Pages area is the default Parent Page setting, which you can change if you wish. We want it to be here, so nothing to change. This time we'll set the Template to "Blog Item". And then we'll again go set "Published" to No in the options, and save the page.

Now we can add images or other media and do whatever. You can save it again and set a publish date or just mark "Published" as yes and "Visibility" to Enabled when you're ready to present it on the website.

After you've saved the page, let's check out these other buttons up here.

The arrows navigate the folder structure. So the up arrow would go to the parent page, in this case the main blog page we made. Down would go to the first child page, so we could go back down to this page from the parent if we wanted. Left and right go between different pages within the same folder, sorted by folder name. All of these can be useful if you decide to edit a bunch of pages at once, like if you say decide you did want to turn on the Folder Number Prefix on all of the child pages. You can just cycle through them with these buttons. The "back" button on the far left hops back out to the Pages screen if you wish.

Delete, Add, Copy, and Move are all self explanitory, but useful. You can move entire folders around including putting them within other folders. Very handy. But I don't think you can move a page to the very top level, annoyingly.

The little eye will preview the current page, but this option is not visible if the page isn't published, which is very annoying. I've also seen it be bugged on occasion, so it's best to check the site itself when possible. Sometimes updates will take a moment to propagate, and you can use the refresh cache button on the left to hurry it along if you're impatient.

Finally we'll go back to the posts page, we can see the blog page we made, and the little icon showing child posts, and our child post within there.

That's an awful lot of things, but that's the bulk of using Grav for typical use. We do have a couple other things to try out though.

Rosts

So a rost is an RSS only post, coined by YuushaRuby here. I wanted to see if I could do this within Grav. The current solution I have isn't really a rost, it's more like an unlisted feed.

This requires addressing another big annoyance for me in Grav: how Visibility works. This was fun to fight with while making this guide, and is why I say to explicitly set Visibility on all pages. I think part of this might be a bug in Hypertext, I'm not sure, but here's what you need to know.

• Always set visibility in the new page dialogue to Auto. Because it won't do what you expect it to. I still don't fully understand how it works, the things I've looked up don't line up with how it's working in practice.
• The "Visible" option in the Advanced tab of a page will sometimes change if a post is visible as a child page within a collection, sometimes not. Maybe I hit a weird bug, but you should not trust setting it to Disabled to hide something as a child page.
• If you want a page to not be visible no matter what, you want to set it to Unpublished in the Options tab.

So our solution for a rosts page is making a new blog with Visibility turned off. Since it's a top level folder, it can't show up as a child anywhere. One can still navigate to the URL and see the posts, but it's not otherwise visible on the website unless you paste the URL into the browser. So if we say, make a blog called "Rosts", set visiblilty to disabled, and then make some posts within it all with just default settings,

We can see the icon for the page here is grey, indicating it's not visible. The child posts aren't "visible", but since they show up in collections as children regardless of that setting (ugh), that doesn't matter. I did make one of them Unpublished here to point out that it gives it a little red dot, to indicate such.

With the Feed plugin installed, we can just add .rss or .atom to any page URL to get a feed from it. So if we wanted to link the rosts on the home page, we could just go do add

[Rosts here!](/rosts.atom)

and that creates a markdown link to the feed. Since we're on our own website, we can make relative links like that, too. Fun!

What I'd really prefer is if I could mark any given blog post as not visible, but have another toggle for if it's visible specifically to Feed, so I can choose if any given post is feed only or blog only. Or both or neither. But that requires work that is beyond what I'm capable of at the moment, unfortunately.

Gallery Page

One of the big goals I had for using Grav like this was to be able to make a gallery page. For myself, for posting art, and for others who would want a page for art, or photography, or whatever. I'm sure someone wants to make a gallery of memes.

I've come up with two different ways to do it. The first uses a whole plugin and is supposed to make a whole lightbox, a web term for fullscreening an image and giving you next/previous buttons and what not. Yes I know that's taken from a photography term. Anyway, by default in Hypertext the whole lightbox function is broken, but it still generates a basic gallery VERY easily, all on one page.

The second way is a bit of a CSS hack to turn the way child posts are presented on the collection page as a gallery. This takes a bit more work to post, but gives you whole pages so you can write lots of text to go with each image.

You can use either, or even use both on different pages.

Method 1: Shortcode Gallery++

Since it's a plugin, There's already nice documentation on the github project page for it, with pictures too..

But, due to some oddities of how Hypertext loads assets, all of the JS stuff is broken. Thankfully the gallery still shows images and lets you click on them to open the fullsize, which is most of the work. Here's what that looks like in practice.

So the process is simple. Go go the Plugins page and install "Shortcode Gallery++" just like we did with the Feed plugin before. It will say it needs to install extra packages, say yes of course. Then on any page, just use [gallery] tags to wrap normal markdown image posts.

There is a fix to get full functionality, but it involves editing the theme files itself. For now this is the "more basic" option.

Method 2: Some CSS hacks

Unfortunately this solution is a bit of a hack. This was the first working method I have, and I take little credit for it. Cohost user @nex3 was kind enough to take a look at my problem and give me some CSS that turns the normal "Summary" collection into a functional gallery page. I adjusted it slightly, so any compliments can go to her and any criticisms can go to me.

This method does depend on you creating pages a certain way however.

So what we'll do is make another blog page, but name it gallery. Then we'll go to the Hypertext tab and do some things. By the way, if you're missing parts of this page, it's because you set the page template as an Item instead of a Collection (Blog Item instead of Blog, etc).

Under "Child Rendering" we want to make sure the "Render Style" is set to Summaries, which is the default. We also want to Enable "Show image". This shows the first image uploaded as a banner normally, but in this use it's going to become our thumbnail. Then in the "Custom CSS" box, we'll paste the following incantation:

main > article {
  display: flex;
  flex-wrap: wrap;
  gap: 0.8rem;
}

main > article > :not(.snippet) {
  width: 100%;
}
    
main > article > hr {
  display: none;
}

main > article > .snippet {
  max-width: 22%;
  aspect-ratio: 1/1.5;
  padding: 0.2rem;
  border-radius: 5px;
  box-shadow:
    0px 4px 5px rgba(0, 0, 0, 0.14),
    0px 1px 10px rgba(0, 0, 0, 0.12),
    0px 2px 4px rgba(0, 0, 0, 0.2);
}

Yes I said we wouldn't touch CSS, I'm sorry. You can just paste this in as-is, and now the posts you make on this page will line up in a grid as you go. Wonderful! But, as I mentioned, you need to build your posts in a specific way.

Unfortunately, we have to manually make thumbnails. For a post, we'll upload two files. The first file is going to be the thumbnail, and we want it to be a 1:1 aspect ratio, and ideally larger than the boxes will be. Say, 400x400 just to be safe. One of the things lacking with this gallery setup is the thumbnails will resize the boxes a bit based on their aspect ratio, so keeping everything 1:1 is the simplest and makes everything look even. The second file is the image itself, easy enough. You can drag the images round in the media uploads of the post page, just make sure the thumbnail is the leftmost one.

Then, in the post itself, we'll put a read more at the very top of the page, which by default for Grav is === (compare cohost's ---). Then below that, we'll put the image itself (easy to just hover over the full size image and hit the + button), and any text we want to add. If we didn't do this, the full size image and text would also show on the gallery page itself. But, by posting things this specific way, we can make it work.

Long titles can offset things a bit, but the boxes themselves should stay even. Like I said, this is a bit of a hack, and nowhere near as clean as I'd like it to be. What I'd prefer is if there was just a display option for "Gallery" where it says "Summary" that does all of this for us, plus some auto or in-browser thumbnailing. But right now I don't have that for you, I'm sorry.

Miscellaneous Other Bits

Backups

You should back up your website. No matter how much you pay any hosting provider, if they decide one day to trash your whole site/vps/disk/whatever, you're not getting that back. Since Grav just operates as files without a "real" database, the site can exist entirely in a single zip that can just be plonked back on a new server with no extra setup. In the "Tools" section the first tab you'll see is the Backups tab. There's a "Backup Now" button in the upper right, and all you need to do is click it. It will run for a bit and spit out a zip file as a download, and will also keep a copy of that on the server too.

The backup is a copy of the entire webroot, minus temporary folders that Grav builds automatically. So all you need to do to restore is extract the zip to the webroot, which for NFSN is /home/public/. You would need to SFTP/SSH in to do this on NFSN, but you shouldn't need to restore from backup unless something went very wrong.

Since a copy of the backup zip is saved on the server, you may wish to change how backups are retained on the server for cost reasons. Hosting providers often will either have a limit of how much disk space you're allowed to use, or charge based on how much you use. NFSN is the latter, so I decided to change "Backup Storage Purge Trigger" to "Maximum Number of Backups", and "Maximum Number of Backups" to 1. This only keeps the latest backup on the server. Since it's just a zip file and should be <100MB unless you put a lot of images on your site, I think it's best to maintain other copies elsewhere rather than leave them on the server.

Since the restore process is very easy, backups can also basically be used as a site export if one wished, to move it to a different site, different hosting provider, move from a local copy to hosted, etc etc. You will have to set the file permissions again most likely, but the commands listed for setting up on NSFN can be tweaked (really you just need to change the chown to match whatever the apache username is) for that.

Just do not leave the backup zip in your webroot for any reason. If you leave it there and someone guesses the filename, they can download the whole thing. Be sure to delete it after you extract it.

"I want to add someone's webring to my page, they gave me some HTML...."

You can just put raw HTML into the post editor, similar to on Cohost.

You may also wish to use the "Headers, Footers, Links" tab inside Themes > Hypertext (clicking the box, since it's not super clear) to put something like that in your footer.

I want an RSS feed for a taxonomy entry

The URL for a taxonomy entry, in this case "tags", will look like this:

/main-blog/tag:shitposts

you add /.atom (or /.rss) to the end, like so

/main-blog/tag:shitposts/.atom

Again these are automatically generated, no settings or effort on your part. Taxonomy entries are created the first time you use one, and feeds are generated from all collection pages.

"This looks kind of ugly"

Check the "Style & Formatting" tab inside Themes > Hypertext (again clicking the box, since it's not super obvious that you can) and read the Themes & Styles section. You can also do custom CSS here if you wish.

"Can I make it fancy?"

Sure. I kept this to a pretty barebones, "don't touch the dials" kind of guide. If you want to, it's very easy to start throwing custom stylesheets on top of Hypertext. Hell there's two dozen of them already sitting in Hypertext already as examples. Once you get SSH/SFTP access to the server it's very easy to start going in and editing the guts of Grav, and since it's entirely file based you can get in really deep, really easy, but realistically you probably only want to mess with the Twig templates in the theme. You should probably go look at their official documentation for more info on how all of that stuff works.

I avoided all of that in this guide because I think the most important part is having a website. Making it fancy is optional, and comes after you have a site.

NFSN Domain Creation

Why did I put this at the very end? Because this is the most expensive part, and it's fully optional. You can, and probably should, go through everything else and actually get a functional website stood up, maybe even showing it off to friends and such, before you get a domain.

Another reason for using NFSN is because they make this whole process very easy, and offer a relatively cheap proxy service to not plaster your legal name and contact info all over your WHOIS page. Here's their domain pricing per TLD, some have discounted new registration fees but the renewals tend to be a bit higher. It is possible to get cheaper domains elsewhere and bring them in, but for me I'd rather pay another $7-10/year to have the extra work taken care of for me. In my case, I went for a .net domain. Nothing fancy.

Their proxy contact service, which they list as "Respect My Privacy!", is a checkbox option after you decide on your domain name. It costs just under $4, billed up front with the domain registration rather than per-day like the server costs. So add $4 to whatever domain you're looking at.

Once you have a domain, you need to actually tell your website to use it. This is, thankfully, quite easy in NFSN. Go to the site tab, and click on the short name for the site.

By the way, if you for some reason named the short name anything dumb, you can't change it, so if you don't like it, now would be a good time to create a backup of the site, and spin up a new server with one you'd prefer.

Then go to "Add a New Alias" under the Site Names & Aliases box, and type in your domain name, ideally with "www." ahead of it. If you did add "www.", then do that again but without it. If you didn't do it, do it again with it. So when you're done, you should have three site names in the box:

• shortname.nfshost.com
• www.domain.net
• domain.net

Then go down to the "Canonical URL" within the Config Information box and edit. You should have the option here to pick any of the three site names listed as the "Canonical Name". Pick whichever one you like the best. We'll also turn on Canonical Name Redirection, which for us will just point those other site names as a redirect to the one we just picked.

You may need to wait a minute or two for those little locks beside the site names to show as "locked" with a key, indicating that the SSL setup has all been done. Once that's done, your site should load as expected from your new domain! If it doesn't, and you tried to load it before everything was set up, you may need to clear your cache for it to load. Or wait a few minutes.

If that seems like a lot of work, trust me, having all of the DNS and SSL taken care of like that is very nice to have.

TODOs

• Add command to build "block all" robots.txt
• Find a good way to make collapsible sections on cohost to try and break the length up a bit

In Summary

While Grav does have a number of little annoying things, I feel like it's ease of setup and the general "CRM" concept make it one of the better ways to go about setting up your own website. I don't think there's a best way, each way has its own tradeoffs for cost, flexibility, ease of use, and so on, but this is the one I'm most comfortable with recommending if someone wants "their own website" for minimal effort.

That being said, there's a lot of close runners up that will be better solutions for a lot of people. Bear is most of this plus a few limitations, but a faction of the time to set up and use. RuSShdown can be used from a phone to make little rosts to toss on your neocities/nekoweb from wherever! I made a whole post about alternative options, and you should probably go read that here.