How hard would it be to integrate a Purple Number implementation into WordPress posts? Purple numbers use html anchors to automatically provide block-level addressability (permalinks for paragraphs). They get their name from the unobtrusive light purple displayed link from which they derive their name.
There are already MovableType plugins, but I’m looking into moving over from MT to something else. I love the fact that WP is devoted to standards compliance (and I spent far too much time fiddling with my MT templates just to get them to validate), and the lively hacks community here looks promising. Any thoughts?
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:
$purp_id = 'id-'.the_ID().'-p-'.$j;</pre>
$jwas 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-hacksfile recieves new-lines, yet WP outputs paragraphs.
my-hacksis the last step, no?
Actually, yes, calling the filter from my-hacks is the last step in the_content, right before echoing.
The magical paragraph tags, eh?
Ah, found it! Look for a funcion
functions.php. How that actually gets into your code is through an
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 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
ptags (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
- You must be logged in to reply to this topic.