Hi Ed,
Sorry you had a disappointing experience with the Eleventy Starter! We’ll do what we can to go through and update the starter to a more useful condition, in particular updating it up to use Eleventy 3, and using the new 11ty filter renderContent where we can.
I think one of the main problems here is that we haven’t made it clear that snippets in markdown fields in the visual editor won’t work without significant custom implementation.
The issue is that rendering Snippets/Shortcodes is usually the responsibility of 11ty (or whatever SSG you are using). When 11ty runs a build it parses your markdown body content, and renders any shortcodes amongst that body content.
A markdown field in frontmatter getting run through Bookshop does not get run through 11ty (at least not in the visual editor). Instead it would usually get parsed into html through a markdown library, eg. markdown-it. 11ty will also be doing this under the hood (but also more - like resolving your shortcodes into html) when it parses the markdown in the body content of your pages. Bookshop doesn’t run any part of Eleventy proper in the browser, it just runs the liquidjs engine, so anything to support a specific Eleventy non-liquid feature like renderContent has to be emulated in a custom Bookshop plugin.
When we update to the latest version of 11ty we do gain access to the renderContent filter, which renders markdown and snippets unlike just pumping the content through a standalone markdown library. This is probably where you noticed that, although your shortcode will render during local development and on your real site, Bookshop doesn’t know anything about the renderContent function (remembering it is an 11ty fn not a Bookshop one). This means it cannot render shortcodes in the same way as would happen during the build. To use renderContent with Bookshop, you’d need to add a custom plugin that does the same thing as renderContent, to tell Bookshop what the markdown field would look like if it did get processed through an 11ty build, and therefore the renderContent filter. This ensures the visual editor can reflect what your changes would actually look like if you were to save and build.
I’m doing some experimenting to see if there’s any way we can implement the same logic that renderContent uses under the hood in a custom Bookshop plugin, but so far it does seem like quite a large piece of 11ty to try to recreate in a plugin.
We’d like to offer this workflow if we can work out how, but currently its not possible. I think the approach you’ve settled on of nesting components inside of other components is the best way forward for now, as you’ve said in your last couple of replies. Hopefully that should still offer your editors enough flexibility with page building/editing. This could also mean reverting to use a markdown library for markdown inputs in Bookshop (which is nice an easy to emulate in a custom plugin) and removing the option for editors to add snippets in those inputs. Although you can’t use a markdown input with Bookshop to add components (snippets) throughout that content, it could still be handy to allow editors basic markdown formatting like bold, italics and links.
Again, my sincere apologies that you had a round-about frustrating experience getting to that point. If you have any questions, or further feedback on how we could better communicate this in future to avoid others having to face the same frustration you had did, we’d love to hear.
Thanks to both of you - Ed and Gio - for being such active community members - it really is appreciated and helps us out a lot!
Best wishes,
Tom
.
I’d be interested in seeing what you came up with.
