Markdown and Media/image usage

Hello!
This post is just me trying to assemble some knowledge and best practice on using WYSIWYG alternatives (namely Markdown) without sacrificing regular content creation strategies like image inserts.

Obviously, as this is non-WYSIWYG, if someone proposes a group or documentation page that suits this topic better, I'll glady move this info someplace else.

WYIWYG approach: Media Module + WYSIWYG

• This has been well documented and is the proposed approach

cons

• for content-heavy sites I found this approach to make content creation harder for less experienced editors
• relies on external libraries + WYSIWYG framework

Method 1: Image Fields + Insert

setup

• Markdown filter
• Image Field (as provided by Core)

• Insert

• [TBD: add setup instructions]

pros

• dead simple
• no additional libraries / editors needed
• possibly better integration with existing image fields

cons

• images can't be handled via media module, meaning
• method is constrained to file usage (e.g. no video inserts)
• raw HTML gets inserted in Markdown content (instead of tokens or Markdown image tags)
• images get inserted with ?itok hash which break when using CDNs / different hosts (e.g. on test installations or domain changes)
• Javascript-dependent

Method 2: Media Module + BU Editor

setup

• Media
• Markdown filter
• BUEditor
• Markdown editor for BUEditor

• BUEditor Media Integration (Sandbox Module)

• see also: 1331996: Media Module

• this setup was developed just now when I needed to mix Video and Image usage on a content- and media-heavy site
• inserting the Button is a bit clunky to do; the Javascript function
  js: Drupal.media.BUE.insertMedia(E);
  has to be inserted manually in the BUEditor configuration

pros

• integration with media system: better UI, future-proof
• possibly better integration with existing media fields
• use all media types, including videos
• token system makes media links more flexible (e.g. host changes work flawlessly, images can be exchanged on the fly)
• tokens are potentially more readable in content

cons

• dependency on BUEditor
• button solution currently only via custom module
• Javascript-dependent