{"action":"created","issue":{"url":"https://api.github.com/repos/tightenco/jigsaw/issues/14","labels_url":"https://api.github.com/repos/tightenco/jigsaw/issues/14/labels{/name}","comments_url":"https://api.github.com/repos/tightenco/jigsaw/issues/14/comments","events_url":"https://api.github.com/repos/tightenco/jigsaw/issues/14/events","html_url":"https://github.com/tightenco/jigsaw/pull/14","id":125826840,"number":14,"title":"Add basic support for Markdown","user":{"login":"adamwathan","id":4323180,"avatar_url":"https://avatars.githubusercontent.com/u/4323180?v=3","gravatar_id":"","url":"https://api.github.com/users/adamwathan","html_url":"https://github.com/adamwathan","followers_url":"https://api.github.com/users/adamwathan/followers","following_url":"https://api.github.com/users/adamwathan/following{/other_user}","gists_url":"https://api.github.com/users/adamwathan/gists{/gist_id}","starred_url":"https://api.github.com/users/adamwathan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/adamwathan/subscriptions","organizations_url":"https://api.github.com/users/adamwathan/orgs","repos_url":"https://api.github.com/users/adamwathan/repos","events_url":"https://api.github.com/users/adamwathan/events{/privacy}","received_events_url":"https://api.github.com/users/adamwathan/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-01-10T15:41:42Z","updated_at":"2016-01-29T14:47:28Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/tightenco/jigsaw/pulls/14","html_url":"https://github.com/tightenco/jigsaw/pull/14","diff_url":"https://github.com/tightenco/jigsaw/pull/14.diff","patch_url":"https://github.com/tightenco/jigsaw/pull/14.patch"},"body":"Allows you to create files  with `.markdown` or `.md` extensions that will be compiled to HTML.\r\n\r\nSpecifying which layout to use and the layout section is done through YAML front matter. For example, you might have a layout like this:\r\n\r\n```html\r\n<html>\r\n    <head>...</head>\r\n    <body>\r\n        @yield('body')\r\n    </body>\r\n</html>\r\n```\r\n\r\nIf that layout was named `master` in the `_layouts` folder, you could create a Markdown template that used this layout like so:\r\n\r\n```markdown\r\n---\r\nextends: _layouts.master\r\nsection: body\r\n---\r\n\r\n# My awesome heading!\r\n\r\nMy awesome content!\r\n```\r\n\r\nThere is also support for custom front matter variables, so given a template like:\r\n\r\n```html\r\n<html>\r\n    <head>...</head>\r\n    <body>\r\n        @yield('body')\r\n\r\n        @if (isset($footer))\r\n            <footer>{{ $footer }}</footer>\r\n        @endif\r\n    </body>\r\n</html>\r\n```\r\n\r\n...and a Markdown file like this:\r\n\r\n\r\n```markdown\r\n---\r\nextends: _layouts.master\r\nsection: body\r\nfooter: 'My custom footer content'\r\n---\r\n\r\n# My awesome heading!\r\n\r\nMy awesome content!\r\n```\r\n\r\n...you'd get this output:\r\n\r\n```html\r\n<html>\r\n    <head>...</head>\r\n    <body>\r\n        <h1>My awesome heading!</h1>\r\n\r\n        <p>My awesome content!</p>\r\n\r\n        <footer>My custom footer content</footer>\r\n    </body>\r\n</html>\r\n```\r\n\r\n## Questions\r\n\r\n1. Right now this only support replacing a single section in a Blade template, so you couldn't have a Markdown file with two chunks of content that are meant to be `yield`ed in two different parts of the parent template.\r\n\r\n    I don't know if this actually matters at all, no other static site generator I've ever seen supports this either, but I'm curious what people think. The main reason this is important is because the current approach of using front matter is not forwards compatible with supporting multiple sections. We'd have to use `@section` and `@endsection` directly in the Markdown and parse it out ourselves.\r\n\r\n2. Right now all variables share the same namespace/scope. So any variables defined in the root `config.php` can potentially collide with variables set in the YAML, and `extends` and `section` become reserved variable names because they are used to tell the Markdown handler what Blade template and section should be used.\r\n\r\n    I don't know what I really think here. On one hand, from a purist perspective it would be better to keep everything separately scoped, but on the other hand, trying to do that would likely make it gross to work with. Instead of just being able to do `{{ $myPageVariable }}` you'd have to start doing things like `{{ $pageVariables['myPageVariable'] }}` and `{{ $config['myConfigVariable'] }}.\r\n\r\n    It's not totally horrible on it's own but it's one of many small aesthetic decisions that could eventually pile up and muddy things up."},"comment":{"url":"https://api.github.com/repos/tightenco/jigsaw/issues/comments/176791059","html_url":"https://github.com/tightenco/jigsaw/pull/14#issuecomment-176791059","issue_url":"https://api.github.com/repos/tightenco/jigsaw/issues/14","id":176791059,"user":{"login":"damiani","id":357312,"avatar_url":"https://avatars.githubusercontent.com/u/357312?v=3","gravatar_id":"","url":"https://api.github.com/users/damiani","html_url":"https://github.com/damiani","followers_url":"https://api.github.com/users/damiani/followers","following_url":"https://api.github.com/users/damiani/following{/other_user}","gists_url":"https://api.github.com/users/damiani/gists{/gist_id}","starred_url":"https://api.github.com/users/damiani/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/damiani/subscriptions","organizations_url":"https://api.github.com/users/damiani/orgs","repos_url":"https://api.github.com/users/damiani/repos","events_url":"https://api.github.com/users/damiani/events{/privacy}","received_events_url":"https://api.github.com/users/damiani/received_events","type":"User","site_admin":false},"created_at":"2016-01-29T14:47:28Z","updated_at":"2016-01-29T14:47:28Z","body":"1. I haven't dug into Jigsaw enough to comment intelligently on this one, but supporting multiple `@yield`s seems worthwhile on the face of it. But if implementation is nasty, it may not be worth it.\r\n\r\n2. My vote would be to avoid scoping and leave it to the user to handle it through prefixes if they want...so long as there's clear behavior about which variable would win out in the case of a collision. This could even, perhaps, be a feature rather than a bug—if the page variable has primacy over a config variable, it could be an easy way to conditionally override a config variable."}}