Grav: site crashes if header is invalid

[notklaatu]

The entire site falls over if there's an error in the header. This may be specific to the quark theme(?)

Server Error

Sorry, something went terribly wrong!
500 - Failed to read /home/username/public_html/example.com/user/pages/01.blog/blah/item.md: Malformed inline YAML string: 'My fake subtitle at line 2 (near "subtitle: 'My fake subtitle").
For further details please review your logs/ folder, or enable displaying of errors in your system configuration.

Is there a way to skip information that can't be parsed for any reason, rather than crashing the entire site?

[rhukster]

The issue with just skipping it is that you would not know the page is broken, and why it's missing from your site. It's kind of important to know when a page is not displaying and is considered a 'critical' error.

In this case, the error breaks the whole YAML parsing which means it can't et any data out of the YAML, which is kinda bad as the YAML describes important things.

[notklaatu]

My concern is that the entire site breaks (and exposes lots of information about the grav install). It might be better to just log the error so the admin can investigate.

The site I'm managing has more than one blogger, and it seems that the more people who post, the chances of something breaking catastrophically goes up exponentially. Breaking the entire site is overkill, and causes the bloggers undue stress about doing the very thing they are supposed to be doing: deliver content.

A broken post should only break itself, allowing the site to continue, and the admin to investigate the errant post as a separate process.

For now, I think I'll try to implement some client-side YAML verification so that errors are detected before posting, but I'd rather Grav not break.

[rhukster]

The default behavior for errors is to display a 'simple' error page that does not expose any setup configuration. Also if you are a general user, and you use the admin, it should not be possible to break the header YAML as the admin will not let you save if it's invalid.

That leaves just the more experienced developers that are editing the YAML directly in the files. As we can't validate YAML on 'save' in this scenario, the only 'feedback' we can give is showing an error.

[notklaatu]

Hm, maybe I got off of the defaults somehow, unintentionally? Is the error I pasted in the simple error you mean, or is that the advanced error? I don't consider it a simple message, because it betrays the path of webroot and the username, but that's just my opinion and others may not agree.

I also didn't realize it was expected for bloggers to use the Admin interface. Is it not the intended use of Grav to edit blog posts as text files, but to enter them via the Admin plug-in? I thought it was the opposite (that you're expected to use Grav by uploading text files, but if you want a GUI, then use the Admin plugin), but I'm happy to be corrected.

The workflow I've constructed for my bloggers is:
Client:

• edit blog posts locally in text files with a boilerplate YAML headers.
• modify YAML to suit the post (title, author name, subtitle, publish date, path to hero image, and so on)
• commit post to git and push
  Server:
• receive git push
• place blog post in webroot so it goes live

It's supposed to make the posting process easy, but when someone makes a mistake, the site breaks. So for now, I'm having my bloggers post to a test mirror -> verify site doesn't break -> re-post to actual site.

[daufinsyd]

I have exactly the same problem ... it's really annoying :( any news on this ticket ?
It would be nice that one bad file doesn't break the entire site.

[notklaatu]

I've had no luck working around this, aside from publishing to a test site first (which, luckily, is easy to set up, since Grav is so easy to set up).

I've tried integrating a linter (yamllint) but I can't find a yamllinter flexible enough to only parse part of a file. I've played around with the idea of splitting the file into two parts at lint time, but I'm afraid of too much complexity at commit time. I don't want to break the publishing process for the authors.

Also, yamllint complains about tags no matter what I do (too many spaces inside brackets), and starting out with a lint process that thas to ignore errors seems flimsy to me.

I think this issue is still valid. I'd much rather Grav refuse to publish an individual post rather than bring down the entire site.

[daufinsyd]

Then atm the best solution would to use a bash script to publish articles on a test grav site, curl the site to check whether the yaml is correct, if so publish it on the main website.

I'll give it a try but I still think a proper fix from the application side is better than a system side workaround #sysadmin ^^

@notklaatu how do your users publish their article ?

[notklaatu]

@daufinsyd They publish over Git. I have Git hooks on the server that copies their posts to the www dir upon receipt.

[rhukster]

OK i have a simple fix for you... This might not be the same line in your version but...

https://github.com/getgrav/grav/commit/cd8f578b39633e665f870a44f8bd4282a129a96a

[notklaatu]

Worked like a charm. I broke a post, proved that it crashed the site, then implemented your one line change, and the site was live again.

Brilliant, thank you! This is a game changer.