Initial Set Up and Deployment

To get things started, I ran through a quick set up sticking with the defaults and deployed to Github Pages. The are a few options on how you deploy or package a website with Publii, and the ones provided set you up for all the common static site deployment methods that I'm familiar with.

For initial set up, I wrote an introductory blog entry. On first go I had a look at the block editor, which I didn't like. I decided instead to go with the WYSIWYG (What You See Is What You Get), aka "Wizzywig", editor. You can't change editor after setting it to a post, but you are also not limited to a single editor for all posts - you can pick any editor that may suit your current blog-entry-in-progress best. Nonetheless, this meant I had to delete the current post and start anew in order to change editor. This wasn't a grievous task at all, but it did cause my starting post to be dubbed hello-world-2. Not the most serious issue in the world, but when I know hello-world-1, or as it was formally known hello-world no longer exists in this plane of existence, there is no reason why it's successor need be known, regally, as hello-world-2. My first response to this was to change the Post slug in the SEO settings pane to the right of the editor, but each time the site re-cached, it was changed back to hello-word-2 ... how bizarre. Well, while dearly-departed hello-world (the first) does not exist in this realm, they do still exist, within the limbo of the trash (or recycle bin, as we prefer to say here in His Highness's domain). Simply emptying the trash and once again renaming the Post slug solved this entirely. However, I did note that the resources for post in the final generated static site do organise their data using an SQLite database per generated website, meaning that the final version of hello-world collects it's resources, such as images, from a sub-folder named 2, corresponding to the post ID within the site's SQLite database. This information will be useful later on when dealing with bugs (that may, or may not, arise from my refusal to set up an Intel machine to work with Intel software on).

After making my first post I went through the deploy instructions for Git. Github and Gitlab both appear to be options labelled as deprecated, this makes sense since those both use git itself anyway. What I did find interesting, is that unless I'm mistaken, they were deprecated after this outdated Arm64 version of Publii I am using was released, so it appears that certain things in the software are being handled via an API perhaps? After setting up my repository in the settings I clicked on the Test connection button, at which point the app appeared to hang, but after waiting a few minutes I clicked on Sync your website anyway, and my website was in my Github repository. I went through the usual DNS set up with my provider, configured the Github Pages settings, and once everything was verified the website was displaying at my custom domain.

After this, any new sync operations will remove the CNAME file that Github places in the repo to match it to the DNS configuration. To remedy this, I just had to click on File Manager in Tools & Plugins, and add a CNAME file to the root directory. Unfortunately I couldn't edit the CNAME file from within the Publii app, but opening vim in ~/Documents/Publii/sites/my-blog/input/root-files was an easy enough solution to that problem.

All that I tweaked after this were a few things in the theme. I'm using the default Simple theme, which I quite like. I will take a look at other themes later on, but I feel like this one gives me everything I need. The theme handles the Blog intro on the home page, in which there's a Read more button there that doesn't really seem to do anything, so I just deleted it - if you are using an up to date version of Publii with the Pages feature you could maybe link that to an About page. This was not intuitive to find, until I realised that the theme, or template, dictates the structure of the pages, with that in mind it makes sense to look here when making adjustments to website outside of post content.