Media and other folders in GitHub, to include them or not?

The CMS Questions
1

Is there a particular strategy to the Media folder in the repo?
Does one ignore this folder locally so all of it isn’t uploaded to GitHub?

I edit content locally in the Panel and whenever I’m ready to do a PR, all of the newly generated media/pages/… really make the PR unnecessarily crowded.

After reading this post I started to wonder, since it sounds like these files don’t need to be in the repo at all, and are only generated on the live server:

Also, what other directories can be ignored in the repo? Sessions?

2

I just discovered that @texnixe edited this file for the starterkit a few weeks ago. This is a good clue as to what to include in your GitHub repo:

3

I added the .lock files, yes, the media folder was already in there.

Depending on the tools you use, you might want to add other stuff to the .gitignore, too.

1 Like
4

I think there’s no correct answer and it mostly depends on the project and setup. For example, I have a repo for this project. Including the media is not even an option because that’s probably 15GB of data.

But I also excluded the content folder because they update the site using the panel and everything else is pushed live automatically using push to deploy.

On the other hand, my site is all stored in a private repo, including media and content folder. That’s because everything is pushed automatically live and I don’t use the live panel to edit the content.

There’s a few folders and files you definitely don’t want to have in a public repo: users and license for example. But other than that, it mostly depends on the project and setup.

1 Like
5

Personally, I would never include the media folder in a repo, it just blows it up unnecessarily. The media folder–contrary to the content folder–is something that is re-generated automatically if you remove it and should be deleted when doing upgrades.

1 Like
6

Well that’s not really true. The entire media folder is not re-generated every time. It would honestly be a crazy thing to do, especially on big sites. I can’t possibly imagine to ask the server to re-generate 15000 images every other week just because I updated Kirby. The panel portion of the media folder sure, I can delete and regenerate that.

1 Like
7

Deleting the media folder shouldn’t be a big deal imho. Even stronger; you should feel confident when doing so. It’s “just” a cache layer.

As it gets rebuilt in increments (per page visit), the only thing that could hurt performance is pages that have a lot of (heavy) images on them. But when you have this kind of site, you’re probably better of anticipating for this and use hooks to resize on upload / use workers to pre-heat caches / …

2 Likes
8

In theory yes. In practice, if your site receives thousand of daily users and you have tens of thousand of images, unless you’re running on a very expensive vps you’ll just crash the server.

1 Like
9

I agree, but in this case it’s probably better to have a pre-heat cache strategy and use a CDN :+1:

1 Like
10

If you have the budget, sure :wink:

1 Like
11

Thanks, everyone. So, to clarify:

  • the media folder is regenerated wherever the installation is viewed, whether it be on a live server or locally, but it is needless to track it in GitHub.
  • the other folders that hold sensitive data such as:
    – site/accounts/
    – site/sessions/
    – site/cache/
    – site/config/.license files
    …etc., (and should only be judiciously tracked, if at all, and only if it is in a private repo).

Is this accurate?

12

I’d argue that the session and the cache folders should never be tracked. The accounts and .license file if then only in a private repo

1 Like
13

Thanks, any other tips about tracking files in situations like this?
Could any of this info help others setting up repos in GitHub with Kirby?