-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the old images folder #24
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good and works on my end!
This might be outside of the scope of this PR, but when reviewing it, I had some ideas on making it easier for content editors given this new strategy of storing images in /content/images
:
-
Open question: In the markdown front-matter, should we require the
/images/
part of the path to the image? If images that content editors add will always be in that directory, isn't it redundant? An alternative idea could be to:- in the markdown, specify image paths starting without the
/images/
part, sobg_image: "/images/methodology/banner.jpg"
becomesbg_image: "methodology/banner.jpg"
- specify the images directory as a param in the config file (e.g.
imageDir: images
) - then where images are inserted in templates, set the src with something like:
{{ path.Join site.Params.imageDir .Params.bg_image }}
- in the markdown, specify image paths starting without the
-
Now that we're not dependent on the file structure in the images directory matching the file structure of the markdown/content directory, I think that the images directory structure should be re-organized. Content editors might have an easier time finding and organizing the images they want to use with a simpler directory structure and more specific image names. For example, instead of storing the banner image used on the "Supporters" page like so:
/images/about/supporters/banner.jpg
, I suggest something like:/images/bannerImages/whale.jpg
. This strategy has the following advantages:- from the markdown file, it's clear to editors that they are using a banner image of a whale (whereas the file name
banner.jpg
is unclear) - it's a lot easier to change which banner image is used on which page, rather than moving identically named images between different directories.
- it's easier for editors to browse the banner images that are already available/in use on their website
- if the content directory structure changes, or a content directory is renamed, the directories in the images directory (and associated image paths) do not need to be updated.
- the same image can be used on multiple pages without confusion and without duplicating the image file
I propose following this strategy for all types of images (not just banner images): categorize images by a general type (e.g. banner images, charts, maps, etc.), create a directory for each category, give each image file a name that represents the content of the image.
- from the markdown file, it's clear to editors that they are using a banner image of a whale (whereas the file name
I could be wrong about those ^^ though and I'm fine making that change if you want it. b might be a strawman because they could just look at all the other image paths and see that they don't have
I would hope that someone can figure out that all of the images named banner.xyz are the banner images on each page. Every page has a banner.xyz and it's always going to be the banner for that page.
It is. But there's only going to be a single banner for every page. I don't think it would be difficult for someone to just copy + replace an image in a directory (probably a rare event). They wouldn't even need to change the frontmatter if they keep the filename :)
It would be a pain to have to go back and rename the image folders, but I don't think that this is going to happen that often. We have a pretty good idea of what the site's structure is like, so I don't see this happening that often in the future
I think that this is the biggest weakness in the folder structure. It would be weird (and against the pattern) to include images from other page directories and my way does't have a solution to this other than To me, the last point could be the nail in the coffin if we're going to share images across pages since neither are really acceptable; I'd be fine with the layout that you're proposing. |
The assets/images folder wasn't deleted when I moved it to
content/
. The is the PR for removing it.To test:
Fixes #23