Django

Code

Ticket #2910 (closed: fixed)

Opened 2 years ago

Last modified 1 month ago

[patch] Add extension support to Markdown filter

Reported by: waylan@gmail.com Assigned to: wayla
Milestone: Component: Contrib apps
Version: SVN Keywords: markup markdown
Cc: waylan@gmail.com, gajon@gajon.org Triage Stage: Ready for checkin
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

Starting with Markdown 1.6 (released Oct 12, 2006) including extentions has become much easier. It would be nice to easily utilize that functionality in Django. Therefore, I propose that my suggestion, which Yuri expounded upon, be included in the markup contrib app. (Note that I am leaving out the use of escape and linebreaks on import failure here - that is another issue for another ticket)

Usage:

* Load extensions by listing them in quotes separated by comas:

    {{ post.body|markdown:"imagelinks,footnotes" }}

* To disable HTML, include "safe" as the first argument:

    {{ post.body|markdown:"safe" }}

* For no extensions (backword compatible) just do the same as before:

    {{ post.body|markdown }}

Attachments

markup.diff (421 bytes) - added by waylan@gmail.com on 10/13/06 13:58:02.
diff for adding extention support to markdown
markup.2.diff (0.9 kB) - added by waylan@gmail.com on 10/16/06 15:48:43.
markup.diff in proper format
markup.3.diff (1.2 kB) - added by Waylan Limberg <waylan@gmail.com> on 01/20/07 17:18:03.
Added check for older versions of Markdown, in which case the extensions are ignored silently.
2910.diff (1.9 kB) - added by ubernostrum on 03/05/07 14:08:57.
Alternate version of other patches
2910-2.diff (1.9 kB) - added by alex@gc-web.de on 10/02/07 21:46:54.
fix for stdout+mod_wsgi problem, please review wrt. unicode changes
2910-3.diff (2.2 kB) - added by wayla on 11/07/07 15:11:17.
Address older versions of markdown and unicode support.
2910-4.diff (2.1 kB) - added by wayla on 11/15/07 13:15:07.
Patch updated to support the new auto-escaping

Change History

10/13/06 13:58:02 changed by waylan@gmail.com

  • attachment markup.diff added.

diff for adding extention support to markdown

10/16/06 15:48:43 changed by waylan@gmail.com

  • attachment markup.2.diff added.

markup.diff in proper format

11/03/06 13:41:48 changed by waylan@gmail.com

  • cc set to waylan@gmail.com.
  • version set to SVN.

11/07/06 13:45:04 changed by Waylan Limberg <waylan@gmail.com>

  • keywords set to markup markdown.
  • summary changed from Add extension support to Markdown filter to [patch] Add extension support to Markdown filter.

01/18/07 03:44:49 changed by Simon G. <dev@simon.net.nz>

  • stage changed from Unreviewed to Design decision needed.

Are the older versions of MarkDown? going to have problems with these extensions?

01/20/07 17:18:03 changed by Waylan Limberg <waylan@gmail.com>

  • attachment markup.3.diff added.

Added check for older versions of Markdown, in which case the extensions are ignored silently.

01/20/07 17:26:21 changed by Waylan Limberg <waylan@gmail.com>

Just added a updated patch which checks for older versions of Markdown. Unfortunately, Markdown only identifies the version in the doc string, so is was easier to wrap the call in a try, except block. Perhaps it would be better to wait for the newer versions of Markdown to become more common and defer this for then.

Personally, I copied the contrib app to my project and made the changes there. Anyone else is able to do the same.

03/05/07 14:08:57 changed by ubernostrum

  • attachment 2910.diff added.

Alternate version of other patches

03/05/07 14:10:16 changed by ubernostrum

Added a patch which cobbles together useful features from various patches:

  • Exception trapping for no Markdown.
  • Not using extensions on older versions of Markdown.
  • Running escape(linebreaks(value)) when no Markdown is available, to safely handle the input.

(follow-up: ↓ 7 ) 04/11/07 18:05:36 changed by alex@gc-web.de

just silently ignoring the "safe" extension seems to be a possible source of security problems...

(in reply to: ↑ 6 ) 04/11/07 20:38:35 changed by Waylan Limberg <waylan@gmail.com>

Replying to alex@gc-web.de:

just silently ignoring the "safe" extension seems to be a possible source of security problems...

I understand the concern, but allowing raw html in Markdown is generally considered a feature - which some will want/expect. Therefore, it should be left to each site developer to chose for him/herself whether markdown should use safe mode in that particular app according to the needs of that projects users. The above patch does that.

Regarding the fact that safe mode is ignored in older versions, that is no different that the current behavior. If I recall correctly, it was not possible to call safe mode that easily, or at all, in older versions of Markdown. If anything, this adds one more reason to apply this patch.

07/13/07 13:48:46 changed by sciyoshi@gmail.com

Is there a way we could do the extension loading manually by using extension.extendMarkdown(markdown)? Currently, python-markdown's extension loading seems to require that packages be on sys.path. I think it would be nicer if you could do something like

{{ content|markdown:"myproject.utils.markdown_extension" }}

A SETTINGS variable that specifies the default extensions to use would be cool too.

07/14/07 13:16:59 changed by Jorge Gajon <gajon@gajon.org>

  • cc changed from waylan@gmail.com to waylan@gmail.com, gajon@gajon.org.

09/10/07 16:39:57 changed by Waylan Limberg <waylan@gmail.com>

  • owner changed from nobody to anonymous.
  • status changed from new to assigned.

09/10/07 16:50:49 changed by wayla

  • owner changed from anonymous to wayla.
  • status changed from assigned to new.

Lets try this again, now that I'm logged in.

10/02/07 21:42:51 changed by alex@gc-web.de

There is a problem with this patch in combination with mod_wsgi: when using the markdown filter without any arguments, arg is '', so extensions ends up being ['']. This causes markdown to print the following on stdout:

couldn't load extension (looking for mdx_ module)

when running under mod_wsgi this results in the following exception:

IOError: sys.stdout access restricted by mod_wsgi

because mod_wsgi disables writing to stdout. see http://code.google.com/p/modwsgi/wiki/DebuggingTechniques

It can be worked around by filtering out empty values: extensions = [e for e in arg.split(",") if e]

10/02/07 21:46:54 changed by alex@gc-web.de

  • attachment 2910-2.diff added.

fix for stdout+mod_wsgi problem, please review wrt. unicode changes

10/16/07 08:02:40 changed by jpd <jd@discordant.org>

To be expected of course, but this will fail with "markdown() takes exactly 1 non-keyword argument" if an older version of markdown is used (for instance 1.4, which is still the latest available in ubuntu feisty, debian etch, etc). Is it worthwhile to check markdown.version (an attr which doesn't exist in the older markdown.py) here and provide a more helpful error?

11/07/07 15:11:17 changed by wayla

  • attachment 2910-3.diff added.

Address older versions of markdown and unicode support.

11/15/07 13:15:07 changed by wayla

  • attachment 2910-4.diff added.

Patch updated to support the new auto-escaping

11/15/07 13:29:31 changed by wayla

I just updated this patch to support the recently added auto-escaping. I left off the fallback to linebreaks(escape(text)) when markdown fails to import. IMO auto-escaping should be taking care of that - if not, then textile & restructuredtext should be patched as well. That's also why I left off the linebreaks - while its nice to have, it should be applied to all three processors, not just markdown - and therefore isn't relevant to this patch IMO.

12/01/07 07:53:03 changed by jacob

  • stage changed from Design decision needed to Ready for checkin.

12/02/07 09:49:11 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

(In [6834]) Fixed #2910 -- Added support for markdown extensions to the markdown markup filter (try saying that ten times quickly!). Thanks, Waylan Limberg.

02/11/08 10:48:13 changed by anonymous

  • status changed from closed to reopened.
  • resolution deleted.

I have problems using german umlauts with the markdown markup filter.

Using markdown.markdown(smart_unicode(value) instead of markdown.markdown(smart_str(value) in the returns solves the problem.

s = "öäüß"

print force_unicode(markdown.markdown(smart_str(s)))

MARKDOWN-CRITICAL: "UnicodeDecodeError?: Markdown only accepts unicode or ascii input."

print force_unicode(markdown.markdown(smart_unicode(s)))

<p>öäüß</p>

02/11/08 12:22:10 changed by jokull@radgjafahus.is

  • status changed from reopened to closed.
  • resolution set to duplicate.

02/11/08 12:26:05 changed by jokull@radgjafahus.is

  • status changed from closed to reopened.
  • resolution deleted.
  • stage changed from Ready for checkin to Design decision needed.

Oops. 6387 is a duplicate of this. Sorry.

02/11/08 12:57:40 changed by wayla

  • status changed from reopened to closed.
  • resolution set to fixed.
  • stage changed from Design decision needed to Ready for checkin.

Replying to anonymous:

I have problems using german umlauts with the markdown markup filter. Using markdown.markdown(smart_unicode(value) instead of markdown.markdown(smart_str(value) in the returns solves the problem.

This is a result of stricter unicode enforcement for the newly released python-markdown 1.7 and not related to the extension support at all. In fact, this would have failed before the patch for this ticket was committed. Therefore, I am restoring this ticket to it's closed/fixed status and have opened a new ticket #6577, which has then been marked a duplicate of #6387.


Add/Change #2910 ([patch] Add extension support to Markdown filter)




Change Properties
Action