I'm putting this page here (under Test) because I couldn't figure out how to upload to the WTF group...:

This version of WTF is a total mess, but it almost-successfully roundtrips from markup to the whizzy editor and back to markup. (There are still some issues with vspaces and newlines and stuff that will take fine-tuning and I've only tested it on a sample of about 5 or 10 types of markup.)

The basic idea is that we divide all Markup rules into 1 of 2 sets: (1) those that are editable (boldface, tables, etc. - whizzy will deal with them without problems) and (2) all the rest (whizzy doesn't know how to deal with these). We build a markup rule table with all the rules from (2) but instead of doing their usual replacement we replace them with <pre class=pmwikimarkup>THE MARKUP ITSELF</pre> and then go ahead and Keep() the whole thing. With this markup table we run MarkupToHTML?() and save the result. Then we unset that markup table and create a new markup table with those in (1), but with the normal replacement this time. We run MarkupToHTML?() on the text that already had the Keep() done it above.

The resulting text has the <pre ...>...</pre> around all the non-editable sections of markup. We put this into the textbox and let whizzy do its thing.

When we save we make sure that ROEPatterns? are processed (this happens by default) and we make sure that ConvertHTML? has been installed. This recipe has a bunch of ROEPattern? rules which convert all the HTML back into markup and then it gets saved on the page.

Rather than using ?action=edit to edit via whizzy I've used ?action=whiz. This lets expert authors ?action=edit the page and continue with markup while novice authors can ?action=whiz a page and wysiwyg it.

It's not done, but here's Δ a copy... (Note that the code is about as messy as it can be, brutishly copied from everybody all over the place -- purely a prototype... no, not even a prototype, a proof-of-concept is what it is)

If it doesn't work for some reason it may be that I modified pmwiki.php or ConvertHTML?() or something -- let me know what errors you're getting... —Peter Bowers April 03, 2011, at 05:36 PM


  • I now have it doing a "round-trip" pretty exactly on a minimized set of markup.
    • Supported markup:
      • Advanced tables (simple tables get converted to advanced table)
      • Bold, italics (double-single-quotes and triple-single-quotes)
      • Headers
    • Exceptions:
      • Headers with an empty line after them in source will be replaced with headers with no empty line after them.
        • Has to do with the !vspace rule -- when I disable that rule this problem goes away but all sorts of other problems appear in MarkupToHTML?()
      • Table cells will all receive the attribute valign="top" if they did not have some valign previously
  • Non-supported markup gets surrounded with the <pre ...>...</pre>.
    • Tested markup:
      • Links
      • (:pagelist ...:)
  • See Attach:wtf2.txt and Attach:convert-html2.txt
    • Place both files (renamed to php extensions) in your cookbook directory and include_once("..<yada-yada>../wtf2.php"); in your config.php

The following source will survive a perfect round-trip through the whizzywig editor and back into this exact source:

[[{$FullName}?action=whiz|whiz it!]]

!! My 2nd-level header
!! header2
!!! contiguous header3
!! continuous header2
(:table border='1':)
(:cellnr valign='top':)cell1
(:cell valign='top':)cell2
(:cellnr valign='top':)row2col1
(:cell valign='top':)cell2

(:pagelist group=Test:)

'''this is bold''' and ''this is italics''

Hello, '''this''' is a ''test''!

Just added this to a site for SandBox? testing. Remember to keep it within the markup I specified above... Use ?action=whiz to edit with whizzywig, ?action=edit to edit normally...

Here's the site.

After many months of no action I'm just glancing through this again. While ROEPatterns? provides a quick-and-easy conversion, I'm afraid that to be really successful there will have to be a reverse-markup table which operates similarly to the normal markup table. The idea is that there would be a reverse-markup rule for any markup that can be round-tripped. (There may have to be others in the table as well, just to clean things up.) Then anything that is in the original markup table (which would include custom markup) that doesn't have a corresponding entry in the reverse-markup table would be placed in the <pre ...>...</pre> blocks.


This is really tempting to try, but I see Robbie the Robot waving his arms, stating Danger Will Robinson, Danger! I do have suggestion/question. Has it ever been considered to use something like this as a simplified entry mechanism? What I'm thinking is that instead of editing the entire page, with all of the associated risks, that the recipe actually only would give you a "button" or link which would could be added to an existing page, and when clicked, would give the end user the "WYSIWYM" interface, but only with the easy to deal with, and working markup for a "section" of the page, like SectionEdit. The users would then be blissfully unaware of the wiki code, and the complex issues with all of the other types of markup/cookboosk wouldn't have to be dealt with. Way, way beyond my skill set, but I think it would be much simpler than trying to deal with every possible type of markup, and the potential for page corruption. Thanks for your efforts!!!!

 0: 00.00 00.00 config start
 1: 00.01 00.01 config end
 2: 00.22 00.21 MarkupToHTML begin
 3: 00.24 00.23 ReadApprovedUrls SiteAdmin.ApprovedUrls begin
 4: 00.24 00.23 ReadApprovedUrls SiteAdmin.ApprovedUrls end
 5: 00.32 00.29 MarkupToHTML end
 6: 00.32 00.30 MarkupToHTML begin
 7: 00.34 00.31 MarkupToHTML end
 8: 00.34 00.31 MarkupToHTML begin
 9: 00.34 00.31 MarkupToHTML end
10: 00.34 00.31 now
Peak memory: 3,728,304 bytes