Wiki: Table of Contents for articles
Development and Programming
UPDATE: This hack has been supplanted by the friendlier Wiki Table of Contents plugin.
I presented this material at my development site, but thought I would share it here as well. First, a disclaimer:
This feature requires a hack to your back end files and as such cannot be supported by pMachine
Now that that’s out of the way, here’s how to add a Table of Contents section to your Wiki pages. Here is a live example.
First, if you are only allowing “safe HTML” in your Wiki preferences, you need to open core.typography.php and add <h4> tags to your list of safe HTML tags. Around lines 60-70, you’ll see the two arrays, adjust them like so:
var $safe_encode = array('b', 'i', 'u', 'em', 'strike', 'strong', 'pre', 'code', 'blockquote', 'h4');
var $safe_decode = array(
'b' => 'b',
'i' => 'i',
'u' => 'u',
'em' => 'em',
'strike' => 'strike',
'strong' => 'strong',
'pre' => 'pre',
'code' => 'code',
'blockquote' => 'blockquote',
'quote' => 'blockquote',
'QUOTE' => 'blockquote',
'h4' => 'h4'
);Then, open mod.wiki.php and around line 2408 you will see a bit of code that starts with (if a later update changes the line number, just do a find on the text below, minus the ‘…’):
$this->return_data = str_replace(array('{article}', '{content}')...Now, add this code immediately before that line.
// BEGIN HACK
// Purpose: add "Table of Contents" type features based on <h4> tags in the article
$toc ='<strong>Table of Contents</strong><ul id="toc" title="Table of Contents">'."\n";
preg_match_all('/<h4>(.*)<\/h4>/', $article, $matches);
foreach ($matches[1] as $match)
{
$article = preg_replace('/<h4>'.$match.'<\/h4>/', '<h4 id="'.$match.'">'.$match.'</h4>', $article);
$toc .= '<li><a href="#.$match.">'.$match.'</a></li>'."\n";
}
$toc .= "</ul>\n<hr>\n";
$article = preg_replace('/[]+__TOC__\s*[<\/p>]+[<br \>]+/', $toc, $article);
// END HACKThat’s it for the hack! Now all you need to do is simply use <h4> tags in your articles to create headers, and add “TOC” to the top of the article. The hack will create an unordered list that can be styled with CSS in your theme file, and will automatically add id’s to your <h4> tags to allow the links to jump to the appropriate spot on the page.
Two things that could be on this hack’s TODO list would be utilizing extensible hacking and turning this into an extension for better modularity, and using <h5> and <h6> to allow nested lists for sub-headings. And in case you’re wondering why I started with <h4>, <h1>-<h3> are already used by the default Wiki themes, so it won’t interfere with the most common installations.
Derek, your example links to http://koruproductions.com/ instead of http://ee.koruproductions.com.
I’m aware; I’m ashamed to say that I’m having problems getting the wiki to run from a subdomain, but I wanted to show a live example anyway as it helps show how it can be useful for those that don’t understand it by my description. I hope to have all of the necessary .htaccess worked out soon, but I’ve got so many crazy rules for my ee.koruproductions.com site already that I could never get it working. :red:
Edit: Turns out my .htaccess was fine all along, as was my path.php. But deleting and recreating my wiki template group fixed it. Random.
Please notice the update. I have converted this into a plugin that allows for your choice of formatting, and requires no hacking. (You still must put <h4> in the safe HTML array in core.typography.php if you have only safe HTML enabled.)
Fantastic!
edit
I added the h4 tag to the file above uploaded the EEtypography plugin and it isn’t working for me. I’ve left the settings to default and my wiki is set to wiki toc, am I screwing something up here? see example here
never mind - I found that you also need to add the h4 to the array (line 64) and not just the list (line 67-78)
alright this is breaking the code
[[Category:Teaching::Professional Development]]on this page and others.
Looks like an unrelated bug, Linguist, the colon next to the P is making a smiley and breaking your link.
Ok, the bug is actually not a bug, but a consequence of using the EE Typography plugin. It’s observing your Emoticon Preference setting, which is correct, but not good for the Wiki. You can either turn this off globally, or edit the EE Typography plugin. Immediately after the line
$TYPE = new Typography;add
$TYPE->parse_smileys = FALSE;This will affect any fields that you have set to use the EE Typography plugin, of course, but most likely that’s just going to be the Wiki, as it’s the same thing as selecting XHTML as the formatting type elsewhere.
THanks for the fix.
No problem; I went ahead and updated the plugin today. It has some new features as well as a bit easier implementation, including changing the default processing to EE’s built in XHTML sans smileys. The EE Typography plugin is just doing it’s job, so there’s no reason to change it. 😉
Hi Derek -
I purchased and installed your excellent TOC Plugin today, and it displays perfectly…except for the actual TOC…:)
You can see the output here.
I’ve set the Wiki preferences correctly, and not changed any default settings in the plug-in. I’ve tried both [ h4 ] and < h4 > formats (without spaces inside the brackets).
The [TOC] tag is parsing the title - ‘Table of Contents’ - and the hr, but isn’t picking up on the headings / subheadings.
Any ideas?
Thanks!
You’ve got some extra paragraph tags around the headings; what formatting plugin are you using for your articles? If you’re using EE’s built in XHTML, what build are you running?
The Wiki is set to use ‘Wiki Toc’, and the plug-in is set to ‘default’, so I guess that’s pulling the built in XHTML. I’m using Build# 20060620.
Les
Additional info: For HTML formatting, I’m using “Allow all HTML”, but get the same result with “Allow only safe HTML”.
Les
I registered to your site. Please activate the account and place my user in a group that has author privileges on the Wiki so I can see the exact text as entered.