How to include site wide background image

In my content folder I have a file rfp.css which contains:

body {background-image: url("assets/images/rfp_background1.jpg");
      background-repeat: no-repeat}

In site\snippets\header.php I have:

  <?= css('assets/css/index.css') ?>
**<?php foreach($page->files()->filterBy('extension', 'css') as $css): ?>**
**<?= css($css->url()) ?>**
**<?php endforeach ?>**

Which I got from here
but the background image doesn’t appear.
When I put

<body background="assets/images/rfp_background1.jpg">

in header.php it showed the background image.
What am I doing wrong, what’s the recommended method to add a background image to all pages?
How do I ensure it displays correctly on all screen sizes?
Thanks for any help

I’ve changed the header.php content to

  <?= css('assets/css/index.css') ?>
  <style type="text/css">
    body {background-image: url("assets/images/rfp_background1.jpg");
      background-repeat: no-repeat}

This works, not sure it’s the right way

The path for the background image is not correct, it should be

body {background-image: url("../../assets/images/logo.svg");
      background-repeat: no-repeat}

You can see these things if you open your developer console and check the errors.

You can put the style tag in the header like you finally did, but in this case, your background image will appear on every page, whereas with the first method, the file is only loaded for the home page.

If you want your background image on every page, you should put the styles into your index.css without loading an additional file. Loading additional files only makes sense if there are quite a few styles for just a single page (to reduce the page load) or if you want to allow the user to change styles by uploading css files.

I usually do this 100% CSS. If i have to give the ability to change the photo, then I do it via a custom field in the site options page (if its the same image every page) or from a field on each page. I still do 99.9% of the css in the main css file, except for the image path - I do that as an inline style on the body tag.

As for making it work in different screen sizes, it’s tricky because you need someway to know the screen size has changed - you could use device detection to generate a new URL to smaller images based on screen size. Device detection is not an exact science, and not without its own issues.

I think I would go with probably use a panel hook to generate the different image sizes, and leaves the screen size detection to CSS media queries.

You could try automatic systems like Adaptive Images or Squeezr - i’ve used both in the past with good success, but i’m not completely sure that they work on background images.

If you use a style tag in the head or if you use only one image, you can use media queries. It’s only when you apply the image with inline styles on the body tag that you run into this issue.

I’ve used for responsive inline background image sizes in the past.

Of course! I personally prefer to avoid CSS in my body though, I like to keep eveything in my SASS files.

An other approach is to do it with image tags in the page and position the container to z-index: -100. Then you can use ‘object fit’ to make it fill the view port. Depending on the browsers you need to support, theres a script for that. This way lets you use src set on the images to deal with the screensizes.

Thanks for all the replies, much appreciated.

I’m not clear about jimbobrjames comment "As for making it work in different screen sizes, it’s tricky "

I thought Kirby was a responsive cms which I understood to mean that screen sizes are automatically detected and everything displays (or not ) accordingly, is this not correct?

No, that is not the case. You have to write your templates and your CSS yourself. The Starterkit is just an example and it is responsive, i.e. it adapts to the screen size. But there is more to responsive images then just adapting to the screen size and there are some different ways to achieve that, it wouldn’t make sense for Kirby to force anything on the developer.

Further reading: Responsive Images – A List Apart
(this is an excerpt from the book by the same author)

Hi Sonja,
Just tried your suggestion in my header.php

body {background-image: url("../../assets/images/rfp_background1.jpg");
       background-repeat: no-repeat}

but it didn’t work - no background image.

body {background-image: url('assets/images/rfp_background1.jpg');
          background-repeat: no-repeat

is ok

What’s the logic when you prepend one or more “…/” to the path? Never quit understood

Where are you using this code now? In index.css? Or in a css file in the content folder. That makes a difference. The path is always in relation to where your file is located.

Are you familiar with dev tools and the console? Do you need any recommendations (tutorials etc.)?

There are two types of paths - relative and absolute.

Relative means relative to the current document (that could be CSS, HTML, PHP… whatever). Absolute means start from the webroot.

so when you use a path like ../../assets/images, you are asking it to climb up two folder levels from current page or file to find the assets folder. Thats a relative link. Which means if you use the same link on a page that is lower or higher in the folder tree, then the path will not work. If your doing this in a CSS file, then the path is relative to the css file, not the page you are using the css file on. Thats important.

Absolute path starts from the webroot, and I think this is what you should use, since it does not depend on where the page is in the site - /assets/images. This starts from the webservers public folder and works down from there:

body {background-image: url('/assets/images/rfp_background1.jpg');
          background-repeat: no-repeat

However, this won’t work if you run the site in a subfolder. So what works best depends on your setup.

@mdavid In your browser console, you can see where the browser is looking for the file and adapt your path as required. The path I suggested was intended to work for the css file in the content folder (or rather, a first level page in the content folder)