Write a YAML schema for all the currently supported front matter properties for blog posts

[caendesilva]

No description provided.

[caendesilva]

Had a random thought, what if we could write schemas as traits? That way the properties could be strongly typed and directly enforced. This way they are already semantic, and always up to date compared to documentation. And the front matter when accessed could merge those properties into the matter array at runtime.

For example:

class MarkdownPost
{
    use FrontMatter\BlogPostSchema;
}

[caendesilva]

Forgot the schema is actually documented, so this is gonna be a lot easier https://hydephp.com/docs/master/blog-posts#supported-front-matter-properties

[caendesilva]

Maybe also add a note that the slug/identifier is reserved by Hyde and cannot be overridden by front matter

[caendesilva]

Thinking a bit on how I want to handle these. On one hand, I like the idea of having these traits to only house data like follows (with comments removed for brevity)

trait BlogPostSchema
{
    public string $title;
    public ?string $description = null;
    public ?string $category = null;
    public ?DateString $date = null;
    public ?Author $author = null;
    public ?Image $image = null;
}

But being able to construct and configure the data right there would be nice, at least when developing, so I'll try that.

[caendesilva]

Also want schema for general pages to include the common shared data and any meta tags and opengraph tags. The whole point of this change is to make it clear to users and developers what data is accessible and where it is generated from.

[caendesilva]

Upside is also that it should be easy enough to write a parser that automatically makes changes to the docs based on the actual schema being used (not that that will be an issue later on in v1 as a schema change is probably breaking)