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

[1.x] Custom Folio Extensions #71

Closed

Conversation

snellingio
Copy link

@snellingio snellingio commented Aug 8, 2023

This is a first pass at making #70 possible.

It turns out, the FolioManager class has a $renderUsing closure. This PR makes it possible for users to tell Folio to actually look at other file extensions other than .blade.php.

(See renderUsing here: https://github.com/laravel/folio/blob/master/src/FolioManager.php#L25)

It's still unclear whether including a heavier "markdown" extension out of the box is worth it r/e the cost of complexity and maintenance. However, because Folio allows users to pass in a custom Render function, if we allow passing in of extensions, this will give end users the ability to extend this functionality themselves.

@nunomaduro nunomaduro changed the title Custom Folio Extensions [1.x] Custom Folio Extensions Aug 8, 2023
@snellingio
Copy link
Author

A couple of thoughts:

  1. Technically it's possible to not have to do anything with Folio. You can close this issue if you don't want to work towards making Folio more extendable. I've wip'd a package together: https://github.com/snellingio/folio-markdown
  2. My approach on the package is bad, it technically duplicates all the work of the router. This PR is a much better avenue.
  3. The extension order actually does matter when passing them in if they overlap. Kind of sucks. We could make a note of it, sort it from longest -> shortest, or something else?
  4. The renderUsing is kind of a hack... because I don't really want to override the default Blade rendering, only custom extensions. So it might be more thoughtful to store a map of extension -> handler
  5. Some additional thought on things like the InlineMetadataInterceptor which really should be pulling from the front matter, instead of using PHP. I've done that in my package, but I've literally just swapped the singleton in the container.
  6. What extensions" do you support, and how? I really do think having .md by default out of the box is a no-brainer... but if you give a mouse a cookie... IMO this moves the package closer to VitePress or Astro territory, and inevitably someone will want to stick their images next to the markdown files.

In light of the above, I'm going to move this to draft status. And I'm leaning away from you merging this without more thought. I'm also open to someone taking a completely different shot at how to implement it.

I just want this feature 🙏

@snellingio snellingio marked this pull request as draft August 9, 2023 04:10
@nunomaduro
Copy link
Member

Thank you for proposing this. We putting this on hold for now!

@nunomaduro nunomaduro closed this Aug 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants