twostraws / Ignite

A static site generator for Swift developers.
MIT License
986 stars 34 forks source link

Feature Request: Markdown Parser via Plugin? Alternative, a block that takes a "HTMLRepresentable" #24

Closed carlynorama closed 2 weeks ago

carlynorama commented 1 month ago

It would be nice to have the Markdown parsed via a "MarkdownParserService" or some patches of HTML provided by an "HTMLProvider" protocol?

Perhaps that could even not be a site wide call? My "Recipes" Content folder could use the RecipeoParser package and "BandReviews" could use the MetalMarkerExtreme package...

Maybe the simplest would be a Block Element that would take in any "HTMLRepresentable", not just an already rendered include.

I currently use hugo (partially to keep myself from fussing), but I really miss the plugin architecture of WordPress. hugo's lack of plugins is why I'll probably move on. Maybe to Ignite! Thank you!

twostraws commented 1 month ago

Hello! Thank you for this suggestion. It would be helpful to perhaps explain what your goal is – what is the result you're looking for? You should be able to parse arbitrary Markdown right now just by creating an instance of the MarkdownToHTML struct and giving it a URL or a string of your choosing. What are the problems caused by that, and how does your request solve those problems?

carlynorama commented 4 weeks ago

Of course. I can parse any Markdown that "swift-markdown" will parse. Which is great. There's no problem with that, exactly.

It's just that sometimes vanilla markdown isn't rich enough to convey complex information.

There are a few ways that hugo handles that:

That swapping in of a different parser isn't open ended. It requires hugo to offer the support (what a pain for them), and not all the features of those utilities can be used by hugo.

https://gohugo.io/getting-started/configuration-markup/

If wanted to make a stand alone CLI tool that could parse my content files using DoCC style markdown there is no hook I could insert it into the hugo pipeline without convincing the developers to officially support it. Although there are hooks for specific things

Some people leave hugo for Quatro for better math equation rendering, for example. (I've only just started looking at it).

Since Ignite is already in the package manager, I could see wanting to add my own dependencies for a "ParsingService" or a "SyntaxHighlighterService" if there was a Protocol and I could just replace the default?

Does that clarify?

For Ignite the Content folder is optional, not the whole the point of the framework, so this may not be a high priority change!

twostraws commented 4 weeks ago

Understood – that makes perfect sense. So perhaps if I declare a protocol that requires Markdown parsers to accept either a URL or some Markdown string, make it default to the current Markdown parser, then allow developers to override it at the site and/or ContentPage level. Would that solve your problem fully?

carlynorama commented 3 weeks ago

I think it might! WooHoo! (Understanding that wasn't a promise it could happen, of course.)

twostraws commented 2 weeks ago

This is resolved, although perhaps not as fully as you might have hoped πŸ˜…

You can now adjust the Markdown renderer to use site-wide for rendering Markdown placed into the Content folder. This does not change the parser used for rendering inline Markdown, e.g. when using Text(markdown:), and I'm afraid there's no option to customize this at the ContentPage level – it's one setting for the entire site. Hopefully that's good enough!