I'm hoping this could be a feature added to this module, to make selecting which fields should be displayed in the markdown version of the entity easier to configure.
The markdown module uses the entity view mode 'full' as a default, but would be great to be able to set/specify a custom display (view mode) for the markdown version of the entity.
This would give more control on which fields are output in the markdown version of the page.
Allow specifying a target display mode for the markdown version of an entity from the module config page
Add a view mode selector input field on the module config page (with fallback to full as default?)
A bit like in the related issue 
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
telegraph commentedComment #3
djschoone commentedThanks for opening this, @telegraph. We ran into the same limitation:
rendering through the `full` view mode pulls in fields that are fine for human
display but add noise to the markdown an LLM consumes, things like related
content, share blocks, and call-to-action regions.
We've built markdown output for AI crawlers in one of our projects, and we'd
rather contribute the reusable parts back here than maintain them separately,
starting with this one. The approach matches your proposed resolution:
- A per-content-type setting to choose which view mode is used for the
markdown representation.
- Fallback to `full` when nothing is configured, so existing behaviour stays
unchanged.
- Because it reuses Drupal's standard view mode system, site builders
configure the markdown output with the tools they already know (Manage
display), rather than a module-specific field list.
Two design questions before I open an MR, so it fits the module's direction:
1. Would you prefer the configuration per entity type and bundle (for example
a dedicated `markdown` view mode convention), or an explicit per-bundle
selector on the module config page as you sketched?
2. Should the module ship a dedicated `markdown` view mode out of the box, or
only let people point at an existing one?
If you're open to it, I can put up an MR against `1.1.x` with the per-bundle
selector and test coverage. Happy to align with however you'd like the
configuration stored.
Comment #4
telegraph commentedHi @djschoone, thanks for taking the time to follow up on this, and it's great to hear that you are looking to add a solution to this!
I think your approach works well, leverage Drupal's view mode system and have the fall back to full as the default. This enables it to work out of the box.
To continue your discussion,
1. The reasoning I had for explicit per-bundle selector on the module config page is that it gives the freedom for the user to select which view mode they want to use, if one is already acceptable, or the option to create a new dedicated markdown view mode independently as needed.
Example use case:
- page [default/full view mode is ready for .md use]
- blog_article [needs a new 'markdown' display mode where specific fields are available = user creates view mode]
2. If users can create their own and point to it, it saves for extra install settings (default install points to default/full), and doesn't create a new view mode if that site doesn't need it.
Happy to assist if you need any help with this.
Many thanks
Comment #5
djschoone commentedThanks @telegraph, that's clear direction on both points.
Per-bundle selector on the config page, fallback to 'full', no dedicated view mode shipped out of the box. I'll get started on an MR against `1.1.x` and will post it here once it's ready for review.
Comment #7
djschoone commentedMR !31 is ready for review against 1.1.x:
https://git.drupalcode.org/project/markdownify/-/merge_requests/31
Pipeline is green.
Comment #8
telegraph commentedThanks @djschoone, tested this on my local environment and it works great!
This update adds the functionality I needed to have fine grained control over the node output in the markdown version of the node.
Looking forward to see this as part of the next release.
Comment #9
djschoone commentedGreat to hear, thanks for testing!