Scope path glob

[alexey-pelykh]

Same as #5854

When this may be useful: when you have two different set of files (e.g. *.doc & *.pdf) in the same folder that requires different values used by Jekyll plugins or Jekyll itself.
Examples:

defaults:
  # Content
  -
    scope:
      path: "content/*.pdf"
    values:
      sitemap: false
  -
    scope:
      path: "content/*.html"
    values:
      sitemap: true

or

defaults:
  # Offers
  -
    scope:
      path: "offers/*/index.html"
    values:
      layout: offer
  -
    scope:
      path: "offers/*/thank-you.html"
    values:
      sitemap: false

[parkr]

What happens if I have *.html here? Should it apply to about.html and contacts/index.html?

[alexey-pelykh]

Since we're using Dir.glob, according to docs, *.html will match only files on top directory, to match any HTML file, a **/*.html pattern should we used

[parkr]

That's what would happen with the current code, yeah. I'm wondering if it makes sense to have *.html apply to all files in my entire source that end in .html. If I were using globs, that's what I would expect.

[alexey-pelykh]

Seems to me that EntryFilter#glob_include behaves in a similar way since File.fnmatch uses same rules of matching. Making *.html to match all files recursively will limit usability of the feature since if I want to set values only for root html files for whatever reason and not for any other - it will be impossible to achieve. Anyhow, this behaviour should be documented somewhere?

[parkr]

It should definitely be documented! If you wanted to apply to just root, would /*.html work?

[alexey-pelykh]

Well, it would, though it would definitely take more custom logic that using Dir#glob and then there would be question why EntryFilter treats *.html differently

[alexey-pelykh]

Regarding the documentation - where should I write what?

[parkr]

We have some code in EntryFilter#glob_include? we might be able to use here.

[alexey-pelykh]

Looked through that code, it relies on File#fnmatch? that uses the same rules as Dir#glob, though EntryFilter#glob_include? itself is not super-useful in this code, it would take more lines of code to reuse glob_include?

[alexey-pelykh]

@parkr what's next?

[alexey-pelykh]

@parkr rebased

[DirtyF]

@alexey-pelykh That's great, could you add a usage example in our documentation?

Note that CI is failing because of ABC/Metrics Cop. If you can refactor it's great, if not just add the offended file in .rubocop.yml

[ashmaroli]

If you can refactor it's great, if not just add the offended file in .rubocop.yml

Do not add the file to .rubocop.yml.
Instead refactor the two Pathname.new(sanitized_path).ascend { |path| [...] } into a private method..

That should appease Rubocop..
Also the last return isn't necessary.. Ruby always returns the last statement evaluated..

[alexey-pelykh]

@DirtyF to which section should I add that example?
@ashmaroli hope it will work better now

[ashmaroli]

do you want to expose this method as a public method? or would it rather be a private helper method?

[alexey-pelykh]

@ashmaroli Isn't there a private scope starting right before applies?

[ashmaroli]

right.. my bad.. ignore..

[alexey-pelykh]

@DirtyF docs and example added

[parkr]

❤️

[DirtyF]

@jekyllbot: merge +minor

[letrastudio]

Is it possible to attach this to a release milestone yet?

Found it mentioned in the documentation (it was exactly what I was looking for!), sad to see it's unreleased. I can provide my specific usecase if it helps.

[ashmaroli]

@letrastudio this has already been merged to the master branch. It'll be included in the next release. If you want, you can use it right now by pointing your Gemfile to the master branch:

gem "jekyll", :git => "https://github.com/jekyll/jekyll.git"