Updated preset sections with variable substition example

[ToshY]

What does this PR do?

Regarding php-flasher/php-flasher#142, the solution that was provided can be documented to make it clear for other users that it is already possible to use variable substition for presets by using the translation files.

Relevant Issues

• [Feature] Preset messages with value substitution php-flasher#142

[ToshY]

hey @yoeunes 👋

Regarding the issue that was discussed, here the PR. If you have feedback/suggestions let me know 👌

---

For your information, while I'm able to preview the markdown, I'm unable to actually setup the site locally. I normally use docker images/containers to run applications, but I'm not familiar with ruby(gems) and jekyll, so I couldn't figure out on how I would get this to work in a docker container (even though I tried).

Dockerfile

FROM node:alpine AS node

WORKDIR /srv/jekyll

COPY ./ ./

RUN npm install \
    && npm run build

FROM ruby:3.1-slim-bullseye as serve

COPY --from=node . /srv/jekyll

COPY ./ ./

RUN apt-get update  \
    && apt-get install -y --no-install-recommends build-essential git \
    && rm -rf /var/lib/apt/lists/* \
    && gem install jekyll \
    && gem cleanup \
    && bundle install \
    && bundle add webrick #webrick gives issues when actually starting up the container; beyond my understaning

EXPOSE 4000

CMD [ "bundle", "exec", "jekyll", "serve", "--livereload", "--trace", "--host", "0.0.0.0", "--port", "4000" ]

So if you by any chance have a bit of experience with Docker, or either maybe further clarify the normal installation steps needed to setup the documentation, that would help me out tremendensly 🙂

[yoeunes]

Hey @ToshY thanks for your contribution 🤗, i just added docker support based on your feedback please check this commit: 72631d9

[ToshY]

Hey @yoeunes 👋

Thanks for merging the PR ande even adding docker support to it. 👍

Regarding the docker part, I got the web service from docker-compose.yml working, but I have a couple of questions/remarks after trying it out:

1. In the Taskfile.dist.yml I see docker-compose instead of docker compose. As they announced GA for v2 last year, v2 has become the standard. So I thought I mention this, as it may be worth updating this (using v2 myself as well).

2. In the current docker-compose.yml you have opened 35729 to host for both web and watch services which causes port conflicts when docker compose up. I think you don't even need to open ports for the watch service as its only used for compiling assets. Sharing the volume should be enough.

3. Regarding the deployment, I'm not sure if that's done manually (as I see no github action in the repo), but currently files like Dockerfile, docker-compose.yml, Taskfile.dist.yaml, are still available from https://php-flasher.io. Example: docker-compose.yml. Think these need to be added to exclude in _config.yml?

4. Question: I'm somewhat confused on what the usage of the dist folder is or why it isn't ignored. These are compiled assets by webpack, so can't they be written to _site/dist directly? Like I stated before, I'm not familiar with Jekyll, so maybe this is normal for Jekyll, but I don't think adding compiled assets to git is best practice. Also seems kind of troublesome for the dev experience, as (p)npm run dev would override the dist, making it more likely to accidently commit it compiled dev assets.

   Anyway, my train of thought on how to do this would be:
   1. Do a (p)npm install to get node_modules.
   2. Do a bundle exec jekyll build, which I assume creates the actual _site directory.
   3. Do a (p)npm run build to compile (prod) assets into _site/dist
   4. For development, if you have (p)npm run watch running in the watch service and an asset changes this will be directly written to _site/dist.

   Then you'd be able to omit the entire dist directory. I'm not sure if that's a bit too naive, but I hope you get the gist of it.

---

If you're interested, I've made some changes locally myself to get it running a bit more smoothly, and I could create another draft PR with some of the points above. Regarding the way of deployment, if you're open to trying out github actions for automatic deployment, I could take that into the draft as well (by taking inspiration from this repo).

Let me know 👌