Editing current theme

[AlexKalopsia]

Hi everyone,

I am a bit confused as to how I am supposed to do some edits to my current theme. Even though I mounted /content, there are no files within the /themes folder.

What am I missing?

[pascalandy]

Hi,
This is not related to this docker image.

But let me try to help. You have to download the theme. Then, you must update it (it uses Handle Bar).

See https://ghost.org/docs/api/v3/handlebars-themes/
You can also ask for help on https://forum.ghost.org/c/help/6

Cheers!

[lapphan]

@AlexKalopsia please provide your docker-compose.yml.

[pascalandy]

Before editing your themes, you should be able to run ghost normally, then upload themes via the GUI in the admin panel.

[kopax]

I have issue when starting the container, I can't work on the theme in intellij due to permissions access, the uid guid used are 1000, there's no way to change that, my user is another uid guid

[pascalandy]

Can't help without details

I have issue when starting the container, I can't work on the theme in intellij due to permissions access, the uid guid used are 1000, there's no way to change that, my user is another uid guid

[1player]

The problem is that this image nukes any mounted volume's permissions with its chown/tar in docker-entrypoint.sh, which is incompatible with many setup and/or rootless containers.

I'm trying to set this up using Kubernetes, and I would like to develop my theme locally. If I mount from "./themes" to "/var/lib/ghost/content/themes", there are three ways it might go:

• On a regular Docker setup, iff your host uid == 1000 (like the node user on the Docker image), everything is fine.
• On a regular Docker setup, if your host uid != 1000, like @kopax has, the entrypoint will nuke your permissions, so you won't be able to edit the theme files locally (because they're not owned by your uid anymore)
• On a rootless Podman/k8s setup, as recommended nowadays, the node container user with uid 1000 is mapped to host uid 100999, so it's basically like case 2, where as soon as the container starts your theme files get chown'd to 100999 and you won't be able to edit your themes on your machine.

The entrypoint script should not chown nor change any permission of its files, as it works only on a small percentage of setups, and it's a nightmare to work around on others.

[tianon]

For production setups, it's definitely useful, but I agree it's less than ideal for development workflows (the worpdress image has struggled with this a lot).

What I'd suggest here is to use a non-root user for the container, which will bypass the chown behavior entirely (docker run --user 1000 ...).

[1player]

What I'd suggest here is to use a non-root user for the container, which will bypass the chown behavior entirely (docker run --user 1000 ...).

Not really, the tar command will try to write to /var/lib/ghost and subdirectories, and if you have a bound volume there (i.e. your theme, which should be perfectly fine if it's read only), the image won't start because tar fails.

[jalberto]

To change file permission is very intrusive, I understand the need for something like this a couple of years ago, but now both in production (k8s has a way to define which permissions should be used to mount a volume) and dev (rootless) is a pain

[jalberto]

My workaround in docker-compose:

    user: root
    entrypoint: ["node", "current/index.js"]

this works fine with podman rootless

[derek-adair]

Before editing your themes, you should be able to run ghost normally, then upload themes via the GUI in the admin panel.

This is not practical or useful in development workflow. I want to be able to;

1. Make edits on my custom theme
2. See them in a ghost instance that uses this theme
3. Commit changes

When you manually upload a theme in a local instance this workflow is broken. @pascalandy this is certainly an issue with the image as outlined quite succinctly by @1player. I understand that this is ideal for production but it is quite convoluted in development.

Perhaps this can be addressed by documentation? I am trying some pretty insane things to try and bypass the way this image works. I really dont want to fork/maintain my own image that works for me so any tips on how to avoid that would be great.

[derek-adair]

Ok, I have figured out a config that will support my desired worklow with the supplied official compose file.

The trick was to mount my theme in the compose file directly to the theme directory;

volumes:
  - /path/to/theme:/var/lib/ghost/content/themes/theme-name

This theme will not show up in the list of themese and you must click "advanced" to select it.

[derek-adair]

Update: It was a more ideal setup to just add a volume(s) to the given docker-compose

version: '3.1'
services:

  ghost:
    image: ghost:5-alpine
    restart: always
    volumes:
      - ./content:/var/lib/ghost/content
    ports:
      - 8080:2368
    environment:
     # see https://ghost.org/docs/config/#configuration-options
      database__client: mysql
      database__connection__host: db
      database__connection__user: root
      database__connection__password: example
      database__connection__database: ghost
      # this url value is just an example, and is likely wrong for your environment!
      url: http://localhost:8080
      # contrary to the default mentioned in the linked documentation, this image defaults to NODE_ENV=production (so development mode needs to be explicitly specified if desired)
      #NODE_ENV: development

  db: 
    image: mysql:8.0
    restart: always
    volumes:
        - ./data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: example

Then you can just clone into your theme in the theme directory. It should be noted that you will need to run yarn install && yarn run dev to see live css changes.