I am trying to build a more complex template based site for another project, to transform the GitHub Wiki pages to a more fancy layout.
The idea is to let the technicians write markdown content and put the layout to the system.
I agree, static pages are the way to go.
Thank you for the suggestion to use GHPages.
Iāve started the process of putting a framework out there. As this is not an area Iām particularly familiar with, Iād love to hear your thoughts.
If I understand the things Iāve setup:
main branch/docs/_posts, following the specific naming convention for dates specified, and they will show up anywhere I have that little snippet that loops through categories.Are there any gotchaās I should be aware of? I imagine folks whoāve been using this for a while may have a list of tips, tricks, and best practices.
If you can help me by sharing those, I will appreciate you even more! 
I am mostly annoyed by the fact GitHub is using another (modified, not really known) version of the layout files. So it is a little hard to develop local and push online. You will get headache while working with tables. My workaround is embedded html instead of markdown.
First you create a repo at http://github.com/username with the name `username.github.io`, which is available at the same direct domain. But It can be redirected to a known CNAME, for a more professional look.
As I see you are already over this steps.
I have a Debian VM with a clone of my repo. I am using a local jekyll build to test changes with a nginx virtual directory ā¦ as said before, it looks a little different, but close enough.
Instead of copying every layout from file to file, make sure the layout is stored in one file. Like Layouts | Jekyll ā¢ Simple, blog-aware, static sites
I like your theme. Nice terminal style.
As I see above, your text is, for a good reason, very spoiler rich. As I have not written them in Markdown so far, I was curious. And as the tables, the solution is also embedded html:
https://stackoverflow.com/questions/32814161/how-to-make-spoiler-text-in-github-wiki-pages
<details>
<summary>SPOILERS - Second stage skills</summary>
The second stage is actually almost trivial, once you understand how the āECBā mode of AES works:
- Each 0x10-byte block is independently encrypted / decrypted.
- Only the last block is required to have the PKCS7 padding.</details>
- [...]
</details>
The auto convert works, as I see at your page. But I think I prefer the local jekyll build way.
One of the best features is to write in markdown at any terminal, and still get the complete layout.
See Layouts | Jekyll ā¢ Simple, blog-aware, static sites for the layout format and how to include header/footer.
Plus the static files, for example an āaboutā which differs from the ā_postā pages. See Directory Structure | Jekyll ā¢ Simple, blog-aware, static sites
One issue I hit was that including embedded HTML in markdown can prevent the text in those elements from being converted to HTML.
## Section Title
<details><summary>Section Title</summary><P/>
This should be a list, but is not:
* Foo
* Bar
* Baz
</details>
I actually am disappointed by that, since I have used those extensively in my write-ups. My āhow to use SPIā post originally used those for each section ā¦ but I had to quickly commit an edit to remove all those collapsible sections.
Thatās painful, because I really want folks to be able to browse without seeing the actual spoiler text, but I donāt want to have to reformat everything to HTML.
Sighā¦
Ask Claude? Itās surprising good at that kind of thing, and you can do winmerge or whatever to make sure the text hasnāt been mangled.
I see. I will take a look, but I canāt test it before tomorrow.
I hoped the more complex solution 2 in the linked article would help. But I have not tested it myself. And as said before, sometimes the GitHub pages are a little quirky.
But in general, they are developing and react to feedback.
Hereās a test page that shows how it just munges everything in a markdown file that uses <details>. I even tried various options to put stuff into <P>, <DIV>, or none of the above. Every option so far has resulted in the details being put as unmodified text ā¦ no markdown ā html conversion.
Iāll ask Claude next, but Iām starting to think Iāll be forced to transition from markdown to full HTML. 
Well ā¦ Claude found the correct cause and fix:
The issue is Kramdown (Jekyllās default Markdown parser) doesnāt process Markdown inside block-level HTML elements by default. The fix is the
markdown="1"attribute on the<details>tag, which tells Kramdown to process the inner content as Markdown.
This will be a huge help in reducing spoiler fatigue.
Woo-hoo! The collapsible sections are confirmed working now. Iām ready to start pushing more content. Thank you for the help!
Haha! Glad it worked out. I just meant to have Claude do all the reformatting but I guess this is one better!
Four posts are now live, now including stage 2. Enjoy the read!
The source code link under āWhile you waitā¦ā returns a 404 error.
https://github.com/gili-yankovitch/SwordOfSecrets/src
fixed, thanks!
words words
# Sample workflow for building and deploying a Hugo site to GitHub Pages
name: Deploy Hugo site to Pages
on:
# Runs on pushes targeting the default branch
push:
branches: ["main"]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
contents: read
pages: write
id-token: write
# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
group: "pages"
cancel-in-progress: false
# Default to bash
defaults:
run:
shell: bash
jobs:
# Build job
build:
runs-on: ubuntu-latest
env:
HUGO_VERSION: 0.124.1
steps:
- name: Install Hugo CLI
run: |
wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
&& sudo dpkg -i ${{ runner.temp }}/hugo.deb
- name: Install Dart Sass
run: sudo snap install dart-sass
- name: Checkout
uses: actions/checkout@v4
with:
submodules: recursive
- name: Setup Pages
id: pages
uses: actions/configure-pages@v5
- name: Install Node.js
uses: actions/setup-node@v3
with:
node-version: '16'
- name: Install Node.js dependencies
run: |
npm install -g postcss postcss-cli autoprefixer
[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || npm install
- name: Build with Hugo
env:
HUGO_ENVIRONMENT: production
HUGO_ENV: production
run: |
hugo \
--minify \
--baseURL "${{ steps.pages.outputs.base_url }}/"
- name: List files in public directory before rename
run: ls -l public/
- name: Rename offline search index
run: |
for file in public/offline-search-index*.json; do
mv -f "$file" public/offline-search-index.json
break # This ensures only the first matching file is copied
done
- name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path: ./public
# Deployment job
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
needs: build
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
```
Iāve added posts up to the initial evaluation of stage3, and Iāve published my (sos_helper)[GitHub - henrygab/sos_helper Ā· GitHub] python-based sword of secrets helper. Made it SO much easier to interact with the sword, even by just having up arrow / down arrow history. Of course, also adds programmatic access.
Hope to post the remaining bit about Stage 3 this weekendā¦
ā¦ and stage 3 review, hints, and walkthrough are now out, as is the module for sos_helper.
The sos_helper library has grown into an indispensible tool, wrapping the SPI functionality into easily used commands (and python functions).
I put up stage 4 last week or so, and I started thinking about just how deep I wanted to break into this device.
Things I could still write about (done already):
The author of this kickstarter campaign said I could write whatever I wanted, but I feel like publishing either of those two AES keys would be ā¦ in poor taste.
What do you folks think?
Given the authorās explicit āOKā, should I include the AES keys directly in my library and/or posts?