Have I (my photo site) outgrown Grav cms, hope not

I have been using Grav for years now. A couple of years ago I posted about having a large gallery. I wanted a single gallery with daily post, a bit like you would get on instagram.

I use a Media boxes and a twig template that adds every uploaded image to the gallery automatically. It works incredibly well and incredibly fast. I do have a few issues though.

  • Off course it works well once the entire page has been cached and the currently the attached images to that page account to about 2GB :slight_smile: After an update, building the cache for that page takes a really long time…well what do you expect :slight_smile:
  • Also the page in the back end shows all attachments and currently there are many hundreds, that is not very convenient anymore.

But once everything is in cache it still in ridiculously fast.

At some point I will have to find another solution though.

I am not exactly a developer so I could use some help. Does anyone have a idea how to handle such a use case? Is it possible maybe to have all images stored outside the page in nested directories? I guess that way images will no longer be ‘attached’ to the page and will not be shown in the back-end, right?

And is there any way I could handle the cache better?

I know I could always go back to wordpress with it’s databases but I really really don want to stop using Grav. Hope someone has any ideas.

This is the twig template part

`<div class="page-content">
            {{ page.content }}
			
					<div class="media-boxes-search">
        <span class="media-boxes-icon fa fa-search"></span>
        <input type="text" id="search" placeholder="Zoeken">
        <span class="media-boxes-clear fa fa-close"></span>
		</div>
			
			<div id="grid">
				{% for image in page.media.images|sort|reverse %}
                {% set imgtitle = image.filename|replace({'.JPG':'.','.jpg':'.','_':' ','__':', '}) %}
				<div class="media-box snaps">
				<div class="media-box-title">"{{ imgtitle }}"</div> 
				<div class="media-box-image">
					<div data-thumbnail="{{ image.resize(600,400).quality(100).url }}"></div>
					<div class="thumbnail-overlay">
					<i class="fa fa-plus mb-open-popup" data-src="{{ image.quality(100).url }}" data-title="{{ imgtitle }}"></i>
				</div>
					</div>
				</div>
				{% endfor %}
			</div>
		</div>`

@Japhy, Hum, that’s odd… As far as I know, by default, the cache of processed images should not be flushed when a page changes.

Unless… the following setting has been set to true in user/config/system.yaml:

cache:
  clear_images_by_default: false                  # By default grav does not include processed images in cache clear, this can be enabled

Despite above setting, the cache does however get flushed when Grav itself gets updated. There is an issue logged at the repo to request a change to this behaviour.

@anon76427325 Ah I am sorry, that was what I meant by update. When I update my page cache is not cleared, it is as described in the github issue, during Grav update

@Japhy,

Two possible workarounds:

  • Rename/move the /images folder before updating Grav and rename/move back afterwards.

  • When all images have been prepped upfront using an image editor like Photoshop or Gimp, Grav does not need to create new images and store it in /images.
    (If you’re a photography enthusiast you will probably edit your images anyway…)

    NB. Both editors have a batch option to process a bunch of images at once.

    When using the following Twig snippet

    {% for image in page.media.images|sort|reverse %}
    
      <div data-thumbnail="{{ image.url }}"></div>
      <div data-thumbnail="{{ image.resize(600,400).quality(100).url }}"></div>
    
    {% endfor %}
    

    The following output will be generated:

    <div data-thumbnail="/user/pages/02.typography/image.jpg"></div>
    <div data- thumbnail="/images/9/f/a/0/9/9fa0969e3ea4450123a38b54ecb3aa09cc29f5b1-image.jpg"></div>
    

    As you can see, only the manipulated image will be served from cache. The non-manipulated image is served as-is from its original location.

Very interesting @anon76427325 Thanks very much. I will give it a go!