Purple Numbers

This can be done with a filter on the_content through my-hacks.php without digging deep into the code, though it’ll be kinda annoying to debug and have to work on regexp magic.
There’s the question of how should the ids be generated for the front page, though.

Unfortunately I don’t see how the MT plugin designers answered this question because they didn’t – their test blog with purple numbers doesn’t have anything on the front page. ??

Looking at the abovementioned implementation, I can’t make heads or tails of whether it follows any logically defined standard when making up unique block IDs. Are they chronological? Or by post number? When should it use letters and when numbers should be used, and why? I can’t seem to find anything clear on this on the Purple site itself either.
Otherwise it seems to be relatively easy to do:
1. Parse the post for tags with preg_match for /<.+>/ pattern.
For each of these:
2.1. If it’s a known block open tag, generate id, stick an anchor after the tag, push the id and the tag on the stack.
2.2. If it’s a block close tag, pop the id and tag off the stack. If the tags don’t match, whine, otherwise make a purple link before the tag.
3. If we’re done and there’s anything left on the stack, whine. Otherwise reassemble the whole thing and return it.
There’ll be debug problems because there’s quite a few ways to make this kind of code behave unexpectedly, but this is just a debug time issue – feed it an average sized blog and keep kicking it until it’s consistent enough.
The question is, how to generate IDs. If I had a concise description of how it should be done, I could probably do it, though since I don’t have any use for such a module, my enthusiasm would be kinda slim.

LOL “Keep kicking it until it’s consistent enough.” Sadly that’s the hardest part. Here’s how I planned on defining the id:
<pre>$purp_id = 'id-'.the_ID().'-p-'.$j;</pre>
That variable $j was just an incrementing number for each block. Pretty straight-forward.
My question: where does WP insert the paragraph tags. This is driving me nuts as the my-hacks file recieves new-lines, yet WP outputs paragraphs. my-hacks is the last step, no?

Actually, yes, calling the filter from my-hacks is the last step in the_content, right before echoing.
Very odd.

The magical paragraph tags, eh?
Ah, found it! Look for a funcion wpautop in your functions.php. How that actually gets into your code is through an add_filter in your vars.php. Tricksy hobbits.

Aha! vars.php gets included after functions.php (and thus, my-hacks.php) in the wp-settings.php, so the wpautop gets added into the filter chain only after the user functions.
How evil of them. ??
Moving the vars.php include up should fix the issue, though.

Someone might learn something from reading this. ??
Just tried this – if you put all the code in a file and include it in index.php right after require(‘wp-blog-header.php’); it executes the filters defined in there last in the chain, i.e. after the paragraph tags are created.
Looks like this solves the problem.

Someone might learn something from reading this. ??

You folks are amazing. I’ve definitely learned a bit here, and thanks for chewing this over–WP’s going to be on the top of by list when it comes time to switch.

Hello. I’m the developer the MovableType PurpleNumbers plugin. I’m frustrated with MovableType’s migration to corporate-hood and remembered WordPress. If I move I’m likely to try porting all the functionality of the plugin to WordPress.
What makes the plugin different from a simple regular expression parser that adds id attributes and purple hrefs is that the content is maintain in a special form (PurpleWiki wikitext) that can be parsed to a tree of nodes by the PurpleWiki libraries. Anytime a node is found without a purple number, one can be added and saved.
Therefore, content that tends to change, such as a blog page that updates, or a wiki page, is kept well purpled, even when content is reordered.
There’s a great deal of information about purple numbers in the purple category on my blog. If you have any questions please feel free to leave a comment there or email me.
To note some things from the discussion above:

• The BlueOxen and Glacial Erratics implementation of the plugin are the same. I’m one of the primary authors of PurpleWiki and implemented the MovableType plugin to see if it was possible. Once I determined it was, I then adjusted the purple numbers implementation to allow transclusion between the blog and the wiki. There’s work in progress now that will allow transclusion between any blog and any wiki, along with any other content that has been numbered in the purple way.
• IDs on the front page. If the ids (we call them NIDs) are being generated from a common sequence rather than per page, it is possible to put the same nids on the front page as the archive page, and as the link under both have the URL of the archive page. This ensures that the NID always points to the permanent location of the content, even if it is being displayed somewhere else.
• NIDs should really be generated from a sequence rather than per page. It makes all the fun with transclusion and the like possible.
• XML and XLink would be the way to go if there were sufficient browser support and a good way to create the docs.
• In the PurpleWiki parser, when entering a pre section, each section separate by a blank line gets a purple number. This is in part because of the system using wikitext, which is not going to be case in all implementations.
• I wrote a quick hack to put purplenumbers on any html page that can run javascript. It’s not ideal because the numbers are ordered from top to bottom, not resistant to change in the document, and only unique for that single page. But it is still fun. Get more info on this.

I implemented Stevarino’s Purple Numbers hack as a 1.2+ plugin. It’s located here.

I’m trying to get this working with comments as well, but am runnign into a problem.
It appears that the comment text does not get wrapped in p tags (or other tags) until a later point – later than when a post does. Therefore, the logic the plugin uses is not able to apply the filter properly.
A post has the tags already in place when the plugin filter is applied; the comment does not.
It kinda looks like the plugin filter is getting called prior to the statement in the function call to comment_text() in wp-comments.php.
Any thoughts?

PurpleNumbers v1.0 is now available.

• Stabilized the identification scheme
• Adds granularity to both posts and comments

Comments on my weblog welcome.