Over time, I've collected quite some assets (i.e., images, etc.) and _includes in my Jekyll website that I don't use anymore.
Is there an easy way to locate:
_includes that aren't in use anymore
Assets that aren't being used (or referenced in the HTML) anymore
Related
I'm Making a multipage HTML Template. so in my assets folder, I have created a folder name images which contains all of the images. In my images folder, there are some subfolders like home-1, home-2, home-3, home-4 just like this. Into these folders, there are many unused images which aren't used in HTML file.
Now how can I find all of these unused images?
It depends on how many images you are using.
But in some IDE's (editors) it is possible to globally search the project folder.
In here you can search for the image name, And if it does not appear in the code, the image does not get used. It will be a pain to search for all of them if you have a lot though.
So let me ask the question. How many images are you talking about?
There is a huge difference between finding 10 images, or 500.
I feel as if I'm missing something. I've read through the documentation of Jekyll and Hugo, but am still confused as to why one would use them as opposed to something like Pug with Webpack or Parcel to create a static-site.
So, what do static-site generators provide that bundlers don't?
You are comparing apple with oranges here. While all those tools can technically be used to create static websites, they serve different purposes. To quote the header of Jekyll's homepage:
Transform your plain text into static websites and blogs.
Jekyll and Hugo are really designed for plain text and (mostly) blogs. As a user, you write articles in plain text or Markdown, and use those tools to turn them into static HTML sites. Besides generating HTML, the tools have a lot of functionality that is typically needed for blogs, e.g. they create an index of all articles and support categories.
With Jekyll (and probably Hugo, but never used it myself), you can also add pages to your site that are not blog articles. So theoretically, you can ditch the blog and use it to build a static website. But that is probably not why most people use it...
Compare that to Webpack: Webpack is first and foremost a build tool for Javascript. It doesn't care if you are building a static page, a progressive web app or a mobile app. It just bundles your assets based on the configuration you provide. With the right configuration, you can certainly use it for static pages, but Webpack will not offer more functionality than to bundle your files.
Depending on your goal, either of these tools might be better suited for you. Tools like Jekyll and Hugo make it very simple to get started and create a static website or a blog. You can style the HTML, sprinkle JavaScript on it and create your own design. Or you just grab an existing template that somebody else in the community created. Whatever approach you choose, you have something running in minutes.
Tools like Webpack on the other hand give you all the flexibility and a lot of power, but also require that you do everything yourself. It really depends on your use case whether or not it makes sense to build a static site with them.
I recently started learning to build webpages and custom themes with Wordpress using Timber, twig and Advanced Custom Fields and I don't really know how to organize everything. So far I've been tinkering with everything in the same place (.php and .twig separated) but I can really see that becoming a mess.
So the answer to this is obviously very subjective. There is no convention for how best to organize your folder, files and project/theme. A great starting point is the Timber Starter theme, which is made by the people who make Timber. You can find that here: https://github.com/timber/starter-theme
I am also going to share with you a project I recently completed with Timber and show you how it is organized. Unfortunately, I cannot share the repo with you as it was for work and the repo is private, however the file and folder structure is all that really matters here.
I started this project, and all Timber projects with the Timber starter theme, so that is my starting point. Inside of the Templates folder, I have the following
CPT = stands for Custom Post Types. Each CPT has its own folder inside of this folder and all of my .twig files for that specific CPT go there. For example: CPT > Staff > image.twig, biography.twig, etc.
components = this file contains things like the header, footer, navigation, mobile navigation, etc. These are all .twig files that are used throughout various pages on my site.
pages = this folder contains folders for each page. I like to break each page specifically into "components" and place each page specific component into its page specific folder.
For example, inside of this pages folder I have a folder called "home-page." This contains all of the components for the home page. So I might have a hero.twig, home-page-slider.twig, mission-statement.twig etc. I break each piece/component of the home page down and create a specific .twig file for each and place them within this folder.
I repeat this process for each and every custom page/template I am making.
That is about it, at least for this project anyways. I hope this gives you a general idea about how best to organize your files. The key, is to do whatever makes sense to you, and if you are working as a team, whatever you and your fellow team members agree upon.
For example you might want to rename what I called my "components" folder to "partials" as you might be more familiar with that terminology. It honestly does not matter what you do as long as it makes sense to you and whomever is going to be in this code base. Remember, what makes sense right now, may not make sense 6 months to a year from now. So think ahead too.
The way I approach all of this is what is the simplest way to convey what each file's role is. I shouldn't have to think or look at a readme. The filenames, folder names and structure should be as self explanatory as possible. I like to remind myself of the KISS principle in these situations... "Keep it simple stupid!"
https://en.wikipedia.org/wiki/KISS_principle
Hope that helps.
As indicated in this similar question (Switch theme in an existing Jekyll installation) there are many jekyll themes to choose from.
I would like to keep my own content separate from the jekyll theme used.
Is there a good (standard?) way of structuring a jekyll project so that your content can be kept distinct from the theme?
Most of your content is kept separate but there is a little bleedover.
This is evident from the answer to the linked question.
Changing the theme later can become a painpoint.
Ideally I would like to structure the project such that there is a theme sub-directory or similar and the theme may be altered by pointing at a different sub-directory.
Doing this dynamically (making the web-site 'skinnable' would be nice to have but not essentiall).
Is there a dynamic theme theme somewhere?
Short answer: Yes, you can keep theme and content separate, but only if your site stays with the basic layout calls (default, page, post).
Longer explanation and exceptions: If your existing jekyll installation is pure: you have edited only the content in pages, posts and not created-used special layouts, then, you can use the jekyll-remote-theme plugin and the switch is seamless, assuming that the new theme is not doing something radical with the defaults.
If your existing theme has special layouts (e.g., splash.html and the new one does not have it) then your pages that employ the respective layout will become orphans (i.e., basic html with no special formatting).
I have switched an existing installation that had been extensively edited, so I got several orphan pages, which I had to manually switch to a layout that makes sense within the new theme.
In conclusion, you can keep content and theme separate in many common cases (e.g., personal blog), but not if you want a custom solution (e.g., personal portfolio with gallery and splash pages).
Jekyll is tool that allow content separation beautifully, be it also from theme files. It's not about standard structuring - although following points will help out.
Do not move or disturb structure of theme files as it may be bought from 3rd party.
Create content as blocks and put jekyll code to insert them at runtime in theme. So if you want header somewhere you can insert {% include head.html %}. Also have a look at contentblocks plugin.
I am still using the default Octopress 3 theme, but would like to use Jekyll themes The instructions online, though, suggest that I fork a theme, change the _config file, and then add my content.
It seems like, since the themes should just be sass and _layout, I should be able to install those files and have a new theme.
I haven't seen clearer examples or documentation on that.
Posting here per the jekyll website.
Generally, the best way is to fork the theme, and copy over your content in the _posts folder, and your _config file, as per this answer.
It would also be possible to copy over the theme files into the _sass, css, _includes and _layouts folders, since this is where the theme rests, but this would mean a) more work and b) you can quite easily mess it up. Oh, and the js folder, the index.html file, any other pages not using the page layout...
Ultimately, Jekyll is not like Wordpress; It's not easy to just drop in a new theme.
Forking a jekyll theme just for using it is not a good practice, even github has recognised it and now provides the template type. Forking is good mainly for contributing back to the original.
The easiest way to switch theme on an existing or new jekyll installation is to use the following plugin: jekyll-remote-theme, which is available since November 2017.
The remote_theme method is almost similar to Wordpress usability, instead of clicking around you have to type-in the name of the new theme in the config file. You do not need to fork a theme or touch any of the style files.
This is an elegant solution, because in the long term you prefer the experts (i.e., the theme maintainer) to handle bugs and new version in the theme, while you can focus on your content.
If you have a custom theme with new and elaborate layouts then the switch might take some more manual work