Ignore hidden files
Opened this issue · 3 comments
While editing a post, the build task finds and processes the corresponding swap file, resulting in parse errors. I'd be happy to submit a pull request (probably for a filter statement in Obelisk.Tasks.Build
), but I'd like to know how you want the matter handled.
Right now, all files are processed, regardless of filename, and one test, three tests rely on this functionality to pass. Constraining post filenames to Build task compiled pages into the build dir
, relies on this functionality to passYYYY-mm-dd-some-title.markdown
breaks this these, but just omitting hidden files (beginning with ".") allows the test[s] to pass.
If the suggested filename formatting is to be enforced, I presume the following might do.
defp is_valid_filename(filename) do
try do
<<year::4*8, "-",
month::2*8, "-",
day::2*8, "-",
title_and_extension::binary
>> = filename
[title, "markdown"] = String.split title_and_extension, "."
Regex.match? ~r/^[a-zA-Z][a-zA-Z0-9\-]+$/, title
rescue
MatchError ->
false
end
end
Of course, if exploding is intolerable, all errors can be matched, but I don't believe it's necessary.
Let me know what you think, and thanks in advance.
My previous statement about which tests fail was incorrect. There are three tests that fail, all on account of the create_post/1
helper function, which generates single-digit days in the resulting filename. Sorry for the confusion.
This is also a problem for Mac OS X users with the .DS_Store files added by Finder. I just get around it temporarily by filtering them out in the list function:
def list do
File.ls!("./posts")
|> Enum.filter(fn ".DS_Store" -> false; _ -> true end)
|> Enum.sort
|> Enum.reverse
end
How to actually handle it, I think instead of locking into a specific filename structure, this should be configurable. E.g. Maybe could have a regex in the site.yml (probably more appropriate in a different config) for what files should be matched. That way it could be setup to match for Obelisk's post filename structure by default, but users that use a different format can just simply change it to what they use.
Submitted pull request #32 as a starting point. I've been using that code a few months now.