arbitrary list

  • Is written in a compiled language/is not written in an interpreted language
    • I like working with the C#, I’m very familiar with working with C#, but it can slow things down
    • “Do it live!” is not possible. Which can be good, if there’s no version control.
  • non-wiki content
  • no pagelists
  • HTML markup
  • Internal Code
  • strike-out markup is the common double-hyphen --. This trips me up time and time again.
    • I really do not like having to manually code —
    • I really do not like having to manually change to a single-dash.
  • Docs suggest that flat-file storage does not scale well.
    • PmWiki scales quite well with flat-files.



non-wiki content

A number of content-providing “pages” [such as group-headers, navigation, etc] are not wikified -- they have to be edited through the admin console, and do not retain version information. they cannot be included, etc. ugh ugh ugh.
These pages are edited through an admin interface.
The admin interface is not wikified -- so is not [as] easily customizable/extensible.
This is all on the web, hooray, but since you can’t apply wiki markup, version control, etc etc etc it seems a huge blindspot. The wiki should eat its own dogfood, and wikify itself.
If the wiki engine is not strong enough to support itself, it is not strong enough.


[and on some level, I might suggest that Screwturn wiki is NOT strong enough for external use. I would certainly rather install php on a MS-stack and run PmWiki for a public website than run Screwturn wiki; however, this is mostly due to accepting any and all HTML markup.]



No Pagelists

PageLists do not exist -- man, I miss them from PmWiki.
I wrote a small plugin to give me some of this functionality, but stopped working on it once my work-cycle-ramped up last year.
Would be nice to revisit.


See more notes at PageListProvider


HTML markup

In addition to (their flavor of) wiki markup, Screwturn accepts (all?) arbitrary (X?)HTML markup.


Which makes me nervous.


In an open wiki, malicious code could be inserted.


I have confirmed that at least some arbitrary javascript can be executed; I doubt there’s anything that would prohibit a subset.
There is a config option to disallow script-tags; but STW ships with this vulnerability by default.


TODO: check out iframes, etc.
TODO: angle-brackets inside of non-formatted text
WORKAROUND: bracket inside of no-wiki-no-html tag




does not execute

<script type="text/javascript" language="javascript">

  document.write('Hello World!');





does execute

<script type="text/javascript" language="javascript">

  alert('hello there!');
  document.write('Hello World!');




Executes, and blocks page from completely rendering until script has executed.




from PmWiki.PmWikiPhilosophy


More notes @ WikiAsConcept


I have entered this as an issue on codeplex



Line breaks and HTML tables

seriously. despite wiki markup, ScrewTurnWiki uses (X)HTML table markup for tables.
Which would make sense for XHTML markup




When the “Process single line breaks in content (experimental)” option is ON in Administration >> Configuration, the formatted throws a huge number of <br /> tags before the beginning of the table. IF the table is “below the fold”, it looks like it doesn’t even exist. Ugh.


Known issue:


Internal Code

From what I’ve seen, the code relies on return boolean true/false for method pass/fail instead of (the modern way? of) throwing exceptions. Perhaps its an indication of my naivety that I was shocked by this.


Also, the “root” namespace/group is rendered as <root>. but is internally represented as null.




Every piece of code that checks for a namespace, has to have an edge-case that checks if the namespace is null EACH AND EVERY TIME, because instead of signifying a code error, it signified the default namespace.




A developer communication confirmed that this was, indeed “by design.”
I would have to add “for certain limited definitions of the term ‘’design’.”