This post is for viewing/testing the PmWiki Markup plugin I’m working on.

NOTHING TO SEE HERE… MOVE ALONG.

The test-area is bracketed with two wp-geshi blocks, with no intervening spaces in the source-markup. This should allow for top and bottom-border testing.

NOTE: wpautop is turned OFF (as it interferes with the (:markup:)...(:markupend:) output).

NOTE: ordered lists had no default formatting under my blog css

public void main(string[] args) {

  //TODO: implement

}

(:source lang=csharp:)
public void main(string[] args) {

  //TODO: implement

}
(:sourceend:)

LinkWikiWords ShouldBe Off

[[SpaceWikiWords]] should be off.

* whatever
** no, seriously
* second main item
* third
** indent
*** indent further
** not as far
* fourth

# whatever
## no, seriously
# second main item
# third
## indent
### indent further
## not as far
# fourth

->[[http://www.google.com|search]]

XraysMonaLisa

>>clip lrindent<<
This is some clip text
>><<

(:comment the below is not rendered due to lack of permissions. hooray!:)
(:include SiteAdmin/AuthUser:)

(:include PrantedMutter/Ort:)

clip lrindent

>>clip lrindent<< This is some clip text >><< 

tags: cell, insite , markup, plugins, pmwiki, wordpress
comments: 2 comments

So, I implemented the custom-action in PmWiki last night, and updated the WordPress plugin to match.

This is much, much better, as there is no longer a mostly-duplicated, hacked version of PmWiki floating around.

I still have to handle CSS issues, and interaction with other markup.

I’m looking at the WP-GeSHi-Highlight plugin which has some great notes on avoiding such issues:

– WP-GeSHi-Highlight filters&replaces code snippets as early as possible. The
highlighted code is inserted as late as possible. Hence, interference with
other plugins is minimized.
– If it does not find any code snippet, it does not waste performance by
senseless inclusion of highlighter libraries etc. And it does not send its
css code to the user if not necessary (others do).

This is how the plugin works for all page requests
==================================================
I) “template_redirect hook”:

1) The user has sent his request. WordPress has set up its `$wp_query` object.
`$wp_query` has information about all the content potentially shown to the
user.
2) This plugin iterates over this content, i.e. over each post, including each
(approved) comment belonging to this post.
3) While iterating over the post and comment texts, occurrences of the pattern
<pre args> CODE </pre>
are searched.
4) If one such occurrence is found, the information (args and CODE basically)
is stored safely in a global variable, together with a “match index”.
5) Furthermore, the occurrence of <pre args> CODE </pre> in the original
content (post/comment text) is deleted and replaced by a unique identifier
containing the corresponding “match index”. Therefore, the content cannot be
altered by any other wordpress plugin afterwords.
6) Now GeSHi iterates over all code snippets. For each, it generates HTML code
that highlights the snippet according to the given programming language
(with or without line numbers).
7) Additionally, GeSHi generates optimized CSS code for each snippet. All CSS
code generated by GeSHi ends up in one string.
8) For each code snippet, highlighted HTML code AND the corresponding match
index is stored safely in a global variable.

tags: binary, insite , plugins, pmwiki, wordpress
comments: no comments

I have a rough-draft version of pm-wiki markup working here in WordPress!


[pmwiki]
!! This is a heading
This is some text

!! This is another heading
Wikipedia:PmWiki
[[http://www.google.com|search link]

[/pmwiki]


generates:

This is a heading

This is some text

 

This is another heading

Wikipedia:PmWiki – Intermap example

search link

 

This is accomplished with a WordPress plugin modeled on FsWiki, and a hacked version of PmWiki that doesn’t perform a page-directive (view) by default, allowing the front-end script to pass text to the markup function.

It is far from perfect — the CSS is wonky*, and I’m sure the PmWiki integration is g-dawful; I need to look into page-directives, see if adding a custom directive is the direction I need to go. Plus, the WP plugin ignores the code-directive, so I had to fudge it to get the example above.

But as a proof-of-concept that was started at 11pm, it only took 1.5 hours.

See original notes.

* The CSS is wonky for this entire blog. I’m no CSS-guru, but I seem to understand it a lot better today than when I pieced this thing together. Just look at how the blockquotes are padded weirdly….

UPDATE: A custom action is the direction I need to take.

tags: binary, insite , plugins, pmwiki, wordpress
comments: no comments