Reviewers

Assignees

Labels

Projects

Milestone

5 participants

I implemented the feature I asked for, namely: The Convertible class now reads YAML metadata either from the convertible file itself, or from a separate file with the same filename but .metadata as an extension. The metadata in the file itself is merged with the external metadata, and takes precedence. This is a small incremental change that doesn't add any other features (Such as attaching metadata to files that aren't handled by the Convertible class).

Unfortunately, I can't get the test suite to pass on the unmodified Master branch, nor Cucumber to run completely, so I can't verify that it passes. I did verify that no new failures or errors are introduced (I.e., my branch fails as much on my machine as the unmodified master branch). I also verified that Jekyll still works as expected and the new feature works with an ad-hoc test (Since I can't use the cucumber test suite). Hope that's okay and you can verify that the commits did not introduce any problems.

If you mean this line, it looks for a file called foo.md.metadata, OR for three dashes at the head of foo.md.

I considered making it so it ignores opening/closing dashes on the .metadata file itself, but didn't think it was worth the complexity cost, so it may break files in unspecified ways depending on what the yaml parser does/thinks.

Edit: Just checked. a .metadata file with opening/closing --- will break, and the file won't be converted.

The file is run unmodified by the YAML parser in exactly the same way the extracted front matter would be. And yes, it does break if the external metadata has ---, I'm unsure as to the specifics of why.

I've rebased to the last couple days of commits to the main repository, to keep this tracking them. So now the Travis build is failing (quite spectacularly) the same way it is for that repo.

Also: I corrected a bug with how metadata was being read. That bug was mine (Oops) but it wasn't caught by the test suite. I recommend (Regardless of whether this pull request is merged) adding a test to check if the metadata on layout files is being read (Since that would have caught the bug).

I thought about it more and I think this would be an incredibly helpful/useful/powerful feature to have built-in to Jekyll. As long as it has no security issues (we'd YAML.safe_load in the metadata file), I'd 👍 to include this feature! Sorry for the delay, @sequitur!

I had a chat with @mojombo a week or so ago and he shared some of his ideals for Jekyll features. When a new feature is suggested for the core of Jekyll, he laid out several criteria:

Is this something that can be (reasonably) accomplished with a plugin?

Is this something that significantly enhances the value of GitHub Pages?

Will this be widely used (essentially used enough to warrant maintaining it)?

Is there a better solution to the problem this feature is trying to solve?

... and several others of less consequence here. If I were to answer these question for myself, I'd assign the following answers:

Not really, no.

Depends on the answer to 3.

Not unless it's used as a curol for adding new converters.

Yes. A system of specifying certain file extnames for explicit inclusion (e.g. .scss, .coffee, .md) would mean a cleaner filesystem (no need for foo.scss.metadata files) and a cleaner file (no need for the ---'s at the top). This explicit inclusion would default to [] so as not to modify current behaviour.

That's my impression: if we can say ok, jekyll, all .scss files should be read in as pages and processed accordingly.

If you specify that all files with a certain extension should be read as pages, where would Jekyll get metadata for those files? If the files still contain metadata at their head, this wouldn't solve the problem this patch was designed to solve. The metadata would have to live somewhere else - I'm happy to have it live anywhere, really. I made it this particular way because it's how Hakyll does it.

Edit: One use we've discussed for this is that it improves the integration of Jekyll with various tools that output or read .md files, including literary programming and automatic documentation tools like literate Haskell, POD and rdoc. This may make it easier to plug source documentation right into a Jekyll page, which I think would enhance the value of Github Pages.

Unfortunately, it's been five months of changes to the Jekyll codebase since the last rebase and right now I don't have time to rebase the changes and make sure everything checks out. Someone who currently has their head in the Jekyll code probably wouldn't take too long to pull the external-metadata branch from my fork and rebase it onto the current master branch from @parkr. Hopefully.