#149: Improved Markup Support

Contents
  1. Motivation
  2. Assumptions
  3. Proposal
  4. Risks
  5. Progress log
  6. Participants
by Tom Lazar last modified Jan 21, 2010 07:26 AM

Creating a mechanism for adding support for additional markup languages such as Markdown and Textile for TextField fields and a site-wide policy for defining available and default formats.

Proposed by
Tom Lazar
Seconded by
Alexander Limi
Proposal type
User interface, Architecture, Process
Assigned to release
Repository branch
plip-149-markup-support
State
completed

Motivation

There's currently no way of setting the policy of what markup types are available in the site.

Two things should be possible:

  • Selecting available markup types
  • Selecting the default format

Preferrably, this should be available on a per-type basis, but even global selection is sufficient if per-type is too much work.

Ideally, this selection would be in the general types control panel, along with the workflow stuff and discussion on/off etc.

In addition, Markdown rocks and we want it ;-)

Assumptions


Proposal

  1. Create an example PortalTransformation for Markdown (following optilude's tutorial)
  2. Create site_properties for storing the default content type and a blacklist of undesired content types
  3. Modify Archetypes (specifically TextField class in Fields.py) and ATCT to honor those properties
  4. Create a UI for setting default type and allowed types in 'Portal Settings'.


Risks

by default both markdown and textile treat inline HTML 'as is' and leave it alone. for our use-case this is not acceptable. therefore we still need to implement some sort of tidying (or preferably just escaping) of any HTML that's entered.

Progress log

2006-04-25
Research and Discussion, especially with Benjamin Saller and Martin Aspeli
2006-04-26
first 'vertical prototype' on separate branches for ATContentTypes, PortalTransforms and MimetypesRegistry.
2006-09-12
picked up development at the St.-Augustin-Sprint. Cut new branches for the Products mentioned above and created initial version of the review bundle.
2006-09-13
migrated the old changes of ATContentTypes, PortalTransforms and MimetypesRegistry to the new branches.
Added necessary site properties in CMFPlone's default profile plus migration and test of those migrations.
Added tests for the merged util methods in Archetypes. Implemented necessary changes to Archetype's Field.py and the template that renders the format selection widget.
2006-09-14
Debugged yesterday's tests using ATSiteTestCase and ATDocument instead of Archetypes Dummy types, since they broke the tests. Performed additional clicktests in demo instance without encountering any errors ;-)
2006-09-15
Added control panel, migration, migration tests. Some minor refactoring in Archetypes.utils, general cleanup and submitted the bundle for review.

Participants

Tom Lazar

Comments (7)

Alex Limi Aug 23, 2006 10:33 PM
http://plone.org/products/plone/roadmap/172

This is another markup type (although implemented as a filter, so can work on top of all the others), so should be available in the types/format selection.
Anton Tychina Aug 20, 2007 09:17 AM
Transforming to HTML from other markup formats don't works on my Plone 3.0 installation (particularly i've tried Textile and Markdown). e.g. *test* is rendred as it is (*test*) and not in the bold face. Please help me! BTW i've installed textile lib prior to testing.
Tom Lazar Aug 20, 2007 11:14 AM
I just tested on 3.0 final instance and it works as advertised. perhaps you were editing with kupu? for non-html markup to work you must edit *without* kupu. Feel free to reply to this comment, as i'm being notified on replies and will be able to follow up promptly.
Anton Tychina Aug 20, 2007 12:21 PM
Sure i edit it without kupu (have clicked on the link 'edit without visual editor'). I downloaded and installed plone couple of days ago so probably we're having the same versions. How can i figure out what is going wrong?
Tom Lazar Aug 20, 2007 12:40 PM
well, in that case the log file would be an obvious candidate. anything going on there?
Andrew Patterson Mar 13, 2008 05:41 PM
If the markdown module is not installed into your copy of python then it will fail within plone without giving any error message. You will just see the markdown passed straight through.
Tom Lazar Mar 16, 2008 04:33 PM
That was pretty much a design decision at the time. The alternative (if I had done nothing in this regard) would be that it would raise an exception. I guess, ultimately, it would be best to pass the un-transformed text (as it is done now) which at least still allows the reader to get at the contents (especially in such non-invasive formats such as textile, markdown, rest etc.) but still display an explicit portal message explaining, which python module is missing.

perhaps something for plone 3.2...