1
  • [ ] I’m using stock docker compose setup, unmodified.
  • [x] I’m using docker compose setup, with modifications (modified .yml files, third party plugins/themes, etc.) - if so, describe your modifications in your post. Before reporting, see if your issue can be reproduced on the unmodified setup.
  • [ ] I’m not using docker on my primary instance, but my issue can be reproduced on the aforementioned docker setup and/or official demo.

This is not a bug but a request for advice after migrating to a docker-compose setup. First, my changes from stock are simply a custom theme, local-overrides.js and a handful of git-cloned plugins, no changes to .yml. I’m using Docker on a Mac (because I hate myself) but it is working really swell so far despite it being a pain to get files from the host to the container volume (as I said, no modifications to .yml so I’m still using the default persistent docker volume “app”.) Also, I’m a Docker newbie.

I used docker cp /local/files container_id:/var/www/html/tt-rss/themes.local/ to get files from the host to the container volume and then set permissions inside the container. (Did I mention I was a Docker newbie?)

There was one other minor change I had on my pre-Docker setup; I commented one line in “js/Article.js” because I personally didn’t like the way articles would jump and scroll when going through the list of unread articles as I read them.

My edit was simply to comment the line “ctr.scrollTop = row.offsetTop - grid_gap;” as in:

//ctr.scrollTop = row.offsetTop - grid_gap;

What is the recommended way to maintain a one-off like this? In a pre-Docker setup I would stash my change, git pull and then pop the stash. Should I do the same within the container (stash the change) then down the container and then up and build again to update? Will I be able to pop the stash within the container once up again? Is there a better way? If this is too basic a Docker question, feel free to nuke it.

  • Tiny Tiny RSS version (including git commit id): v21.12-92747b1d2
  • Platform (i.e. Linux distro, Docker, PHP, PostgreSQL, etc) versions: MacOS 10.13, Docker version 20.10.11, build dea9396
2

the only clean way here is commiting your changes to the repository and accepting responsibility for merges from then on, because what you’re running is a fork.

it doesn’t matter if it’s just one change or a hundred, there’s no lower threshold here.

alternatively you could invent any number of hacks up to and including applying a .diff on container startup or making a plugin which would replace whatever JS function you need changed (like headlines_classic_whatever plugin).

when you inevitably run into issues, please don’t report them.

e: screwing around with docker cp / git is not going to be persistent for the docker hub images, for the hubless (i.e. master branch) image you could technically do this, i guess, although i can’t imagine a less elegant solution.

making and maintaining a plugin i think is the lowest effort approach.

3

Thanks for the reply, Fox. I went with hubless for this very reason. Doing it through a plugin makes perfect sense and thanks for the link to the legacy plugin, I’ll see if it can be adapted to do what I’m looking for.

Edit: And I’m not surprised my first inclination was the least elegant solution … still learning.