Export to Mardown of a rich text field is the operation that i use many times per day.
Now i have to use Copy to markdown, then create an empty external editor, paste it in, save it as a .md file. Lots of work.
Export to Mardown of a rich text field is the operation that i use many times per day.
Now i have to use Copy to markdown, then create an empty external editor, paste it in, save it as a .md file. Lots of work.
Good question.
The reason is that there are a lot of fields “internal” fields in the databases that i use for content. They all show up in the entity export.
If I would dedicate databases purely for public facing content, (with only Name and rich text field) that would double a lot of content databases i use.
Also, i do not use the Name field for public facing content titles, most are formula driven fields that are for internal use (for clarity in data views, searches etc)
Furthermore, database fields may change over time. I need snapshots that never change. That means that i cannot rely on all database fields of a content entity to stay the same, since they will eventually change.
What i can rely on, is only a single rich text field per entity, which contains the entire exact data that never changes, and that exactly matches the formatting needed for the content.
Indirectly related:
And even a single rich text field is actually problematic because of Prosemirror tinkering with the content in the background; essentially Fibery is not yet built for enterprise level reliability of content… for that you need a dedicated code field where you or a script or an agent knows exactly what it gets when writing or reading.
But the code field is not implemented yet in fibery. Waiting for the team to update on that. It will be the biggest relief.
Thanks for the details, but what do you mean by this:
I have no idea of what ‘tinkering’ you’re referring to