Skip to content
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

Metadata not in correct format - in v3.7.2 only #470

Closed
sueyacoub opened this issue Aug 20, 2014 · 9 comments
Closed

Metadata not in correct format - in v3.7.2 only #470

sueyacoub opened this issue Aug 20, 2014 · 9 comments
Assignees
Milestone

Comments

@sueyacoub
Copy link

(IMO) ever since this commit,

We are getting the following runtime error:
The file #{content_filename} appears to start with a metadata section (three or five dashes at the top) but it does not seem to be in the correct format.

We use yaml headers on each page, and they are in the format:
---
filename: <fileame>
<custom-layout-type>: <layout-name>
---

We haven't changed how the metadata headers are formatted. Has anything changed in how the yaml header / metadata should be formatted?

To avoid this error, we have had to set the nanoc version in the gemfile to 3.7.1 and uninstall version 3.7.2 of the nanoc gem from our local machines.

Thanks in advance.

@gpakosz
Copy link
Member

gpakosz commented Aug 20, 2014

Has anything changed in how the yaml header / metadata should be formatted?

Yes, #463 changed the way content is separated from metadata. However, we didn't notice any regression when running the tests.

Could you please copy paste the exact content of the offending file? Or ideally upload the offending file somewhere?

@gpakosz gpakosz self-assigned this Aug 20, 2014
@Fjan
Copy link
Contributor

Fjan commented Aug 21, 2014

It fails on any file that has \r\n line endings instead of \n line endings. I narrowed down the problem to this regex that is new in 3.7.2:

   pieces = data.split(/^(-{5}|-{3})[ \t]*\n/)

One way to fix it would be:

   pieces = data.split(/^(-{3,5})[ \t]*\r?\n/,5)

Note that the last parameter to split limits the number of pieces so there is no need to join them later, which could potentially mess up a file that has '---' somewhere in the middle.

@gpakosz
Copy link
Member

gpakosz commented Aug 21, 2014

@Fjan please see my comments on #471.

@gpakosz gpakosz removed the waiting label Aug 21, 2014
@kraftkern
Copy link

Hi @gpakosz,

i have this error all over the place, but in files that actually have NO CONTENT. I.e. files with metadata but no content part. This worked great in previous versions and I have lots of files like that :) This is much needed feature I always used.

@gpakosz
Copy link
Member

gpakosz commented Aug 27, 2014

@kraftkern we believe we identified the regression, can you confirm your files are in CR-LF mode? (dos encoding)

@kraftkern
Copy link

hey @gpakosz ! Thanks for quick reply. No, can't confirm that. All files are UTF-8 with LF-only (I'm working on a mac). Are they supposed to be CR-LF?

@kraftkern
Copy link

Here's an example (full content with all new lines):
index_md_ nanonick__git__master

P.S.: i got the site working again with nanoc 3.6.1

gpakosz added a commit to gpakosz/nanoc that referenced this issue Aug 28, 2014
@gpakosz gpakosz added this to the 3.7.3 milestone Aug 28, 2014
@gpakosz
Copy link
Member

gpakosz commented Aug 28, 2014

@kraftkern reproduced and fixed it in the PR. Thank you.

@denisdefreyne
Copy link
Member

Fixed in #471 (3.7.3).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants