Category: Wiki Syntax (text area, parser, external wiki, etc)

Wiki Syntax (text area, parser, external wiki, etc)
Show subcategories objects

Name Type
"internal link" button doesn't work -- "local.php not found"
the button "insert internal link" (on the WYSIWYG-editor) doesn't work.

it opens a new window "local.php not found — This is normal if you have not run the tiki installer yet".

(but i run the tiki installer)
tracker item
"No route found" error when save same wiki pages or configuration changes
tracker item
(2.2) Invalid offset in lib/tikilib.php : 6193 (when dealing with cached pages)
This showed up after upgrading from 1.9.11 to 2.2

When accessing Wiki pages with external links (mixed cacheing and nocache), with PHP error reporting on, notified of an invalid offset in tikilib:6193.
tracker item
[mailto:text|text] doesn't have antispam protection
In 2.0 a new email {img src=pics/icons/email.png } syntax was added in quickatgs

{img src=images/code.png}%%% {CODE()} [mailto:text|text] {CODE}

But this prevents the spam protection code from working
tracker item
Put a maketoc in a page wich contains TAB plugin, and the maketoc produces a table of content of all that is inside TABS, but when you click on an item in the toc, we need to have the right tab active.
It could be great that the clic on the toc would active the concerned tab

I hop I'm clear, I don't know if it's a bug or a feature request, so I put the entry as a request.



PS : e.g. : http://code.renaudrubiano.com/tiki-6.1/tiki-index.php?page=test#Lorem_ipsum_dolor_sit_amet
tracker item
This is best explained with an example:

Paragraphs are parsed

just fine here


but now

paragraphs and

line breaks aren't working!

This only happens for tag=ul, not even for tag=ol.

This happens regardless whether wiki paragraph formatting is enabled and regardless of whatever is inside the ~np~{TAG(tag=ul)}~/np~, even ~np~{TAG(tag=li)}~/np~'s.
tracker item
Sitemap.xml &pagenum=2 -v- &pagenum=2
tracker item
<b class="text-danger lead">Something smells like red herring here...</b>
tracker item
<X> strikes again! Please kill it!
tracker item
~ tags not rendering propery
tracker item
~tc~ being processed inside ~np~ and {CODE()} on doc.tiki.org (16.3svn)
tracker item
12.x: page alias links lost if full wysiwyg and wiki syntax
tracker item
tracker item
tracker item
HTML Purifier out of date
Tikiwiki HTML Purifier version is 2.1.3.
Current version is 3.1.1 or 2.1.5.

There is risk of security attacks if not updated.
tracker item
tracker item
Wiki tag {img src=show_image.php?id= } stops working and does not load images from image gallery.
- Upload images to an image gallery, store in database
- create wiki page with tag {img src=show_image.php?id= }
- the images show for a while, but suddenly they do not show anymore
tracker item
Search for javascript looks for ja&lt;x&gt;vascript
Search for javascript in 2.0 using search box performs search for "j-a-<-x->-s-c-r-i-p-t". Happens on tikiwiki.org.


I have a TikiWiki site which requires being able to search text which includes web terms such as j-a-v-a-s-c-r-i-p-t but can't do such a search.

Someone said on IRC this is due to a protective input filter which is altering dangerous text input.
tracker item
table with {toc} does not work...
The following code does not produce a table with one row with an image on the left and a toc on the right:

{img src=images/code.png}%%% {CODE()}
||::{img src=show_image.php?name=valmuer-henrikfalk.png }::|{toc type=fancy }||

The result is two rows with an ugly looking toc.

Worked fine with version 1.9.11

tracker item
Parsing WikiWords on internal links with '-' in them are parsed incorrectly
Links of the form: ''~40~~40~PageName | Text-With-A-Dash And Spaces~41~~41~''
Parse to give: ''Text-With-A-Dash? And Spaces?''

such that:

Text-With-A-Dash -> page=Text-With-A-Dash
And Spaces -> page=PageName

(aka, there are two links to different pages)

This is inconsistent as: ''~40~~40~PageName | Text-With-Dashes~41~~41~''
parses to: ''Text-With-Dashes?''

The same problem occurs with underscores instead (_)of dashes (-) and using |# making things even worse.

The docs don't mention anything about -,_ being special characters when parsing link descriptions; nor should they be.
tracker item
External wiki links are mistakenly identified as wanted pages in WANTED plugin
External wiki links are mistakenly identified as wanted pages


tracker item
tracker item
tracker item
WYSIWYG doesn't create tables with Wiki syntax
If I create a table using the WYSIWYG Editor and click on the __Source__ button, the generated code is using HTML code like this:


Instead of the real Wiki Syntax for tables ([http://doc.tiki.org/Wiki-Syntax+Tables]).

I guess a "HTML->Wiki Syntax Translation" setting must be missing.

As an example, I found out a MediaWiki WYSIWYG CKEditor that does this same translation just fine. Maybe you could check out the code:

[http://www.mediawiki.org/wiki/Extension:WYSIWYG|Extension Homepage]
[http://smwdemo.ontoprise.com/index.php/WYSIWYG_Sandbox|Online demo]

Thanks a lot!
tracker item
6.4svn regression: Maketoc shown twice in newsletter sent from wiki page template
In these last month of june or july 2011, some regression seems to have been introduced in proposals/6x, which produces that maketoc create the output twice, when sending a newsletter from a wiki page template.
tracker item
4-bytestring (most Emoji) Causes Wiki Cutoffs
tracker item
Non-parsed wiki feature (np) doesn't work correctly anymore in plugins

After upgrading my web site from tiki 7.0 to 7.2, I've noticed that the non-parsed wiki feature in the wiki pages is not working correctly anymore.
Indeed, from the tests I've done, it seems that in case of multiple use of the non-parsed wiki feature on the same line, only the last one is taken into account.

For exemple, for the following wiki text, only the second ~np~--css~/np~ is taken into account, the first one not so the text is striked through.

***use the ~np~--css~/np~ option (ex: ~np~--css~/np~ test)


Ticket update:

Note that the problem occurs mainly in fancytables.
I've enabled "Allow HTML" for the problematic pages. That also corrected the problem with non-parsed wiki syntax. (:eek:)
tracker item
5.0 & tw.o: Fullscreen Edit doesn't stay for than a few seconds on
The full screen button in the new interface at Tiki5 for wiki page edition doesn't keep the ful screen mode more than a few seconds.

Reproduced with Google Chrome 5.0.x and Firefox 3.6.6 on GNU/Linux.

Example here:
tracker item
5.0rc2: content duplicated at saving time (seems related to usage of hidden headings)
This has happened to me seldom on different tikis (3.x, 4.x and nowadadays, even 5x!) on different servers, and it's very annoying for users or admins, since after you make a simple edit to some page, for some reason, it gets the content duplicated after saving your small edit. And it can be repeated 3 times, if you edit again, 4 time if edit again,. ..... I could only avoid it by rollbaking to the last version whithout those duplications.

Confirmed that this bug (related to the collapsible headings) is not fixed either yet in 5.0rc2. It seems to show up in some pages were collapsible headings; I mean:



Reproduced recently here:

I just editted the
{rss id=1}

to change it for
{rss id=1:2}

as far as I remember, after a few previews and changes in the content before saving.

Then, the content was saved twice.

See the diff above and the resulting page:

This site is using tiki5.0rc2 , no ajax, and wysiwyg editor enabled, even if not used on that page.

I can provide admin access to that site to any coder willing to check this issue.

Initially reported as a comment to this other similar bug report:
tracker item
Add preview button to tracker item submissions (useful for wiki syntax)
I could be nice to have the "preview" button at tracker item submission time, to preview the parsing of wiki syntax, and to avoid submitting and editting later on for simple wiki syntax errors... (It happened to me, for instance, with bug report:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=184&show=view&status=op&trackerId=5&sort_mode=f_41_desc&filterfield=54 )
tracker item
Add TITLE attribute to external links
When creating a wiki link ~np~((foo)))~/np~, Tiki uses the target pages's ''description'' as the the link's TITLE attribute. It would be nice for external links to also have a TITLE attribute. Tiki could use the link's description, or a generic text. For example:

~np~[http://foo.com|my link]~/np~ would become:
<a href="http://foo.com" title="External link: my link">.....


~np~[http://foo.com]~/np~ would become:
<a href="http://foo.com" title="External link">.....
tracker item
Adding images to blog posts is no way as intuitive as it should be
1- "Upload image for this post" is not offered at first post. Only after I save and come back to edit?

Html is offered:
{img src=images/code.png}%%% {CODE()}
<img src='tiki-view_blog_post_image.php?imgId=44' border='0' alt='image' />

It should be wiki syntax:
{img src=images/code.png}%%% {CODE()}
{img src=tiki-view_blog_post_image.php?imgId=44 }

Related: [tiki-view_tracker_item.php?itemId=1492|It's too difficult to re-use image gallery images in wiki pages, trackers, etc]
tracker item
Grey Screen adding Tiki-Plugin looks wrong
tracker item
Adding YAML to GeSHi - Generic Syntax Highlighter for use in profiles
[http://profiles.tikiwiki.org|Profiles] are cool
[http://www.yaml.org/|YAML] is cool
[http://qbnz.com/highlighter/|GeSHi] is cool.
[http://doc.tikiwiki.org/PluginCODE|The CODE plugin] is cool.

Now, when making profiles using YAML, it would be nice to have GeSHi Syntax Highlighter in the CODE/YAML/Profiles definitions.

tracker item
Administration, Features, Wiki - Picture upload problem
Administration, Features, Wiki

I can enable the 'Pictures:' feature in the 'Wiki Features', however when I then edit a page the 'Upload' feature does not appear.

I found if i remove the WYSIWYG editor feature, the Picture and File Upload becomes available when editing a page.

tracker item
after upgrade from 9.x to 12.x wiki pages with html code are reopened wrongly with wysiywg editor and no way to switch to normal through UI
tracker item
Align=center inside {img} tag breaks layout
See http://doc.tikiwiki.org/tiki-pagehistory.php?page=File%20Gallery%20for%20Images&preview=10

If you use align=center inside a ~np~{img}~/np~ the image will be displayed floating in middle of the text. This is a regression, align=center used to work well in previous versions.
tracker item
Allow more characters in external wiki page names
The current wiki syntax does not allow commas when specifying the page name for an external wiki link. This is a problem for example when trying to setup an external wiki link to a list of Bugzilla bugs. In "Admin external wikis" I can create this entry
|| __Name__ | __Extwiki__
buglist | https://bugzilla.mozilla.org/buglist.cgi?bug_id=$page||
But using ~pp~((buglist:1000,1001))~/pp~ on a wiki page does not work.
tracker item
Anchor are lost after parsing
Anchor are lost after parsing. Tested with WYSIWYG and with normal editor.

{img src=images/code.png}%%% {CODE()}
<a name="myAnchor01">bla bla</a>

after preview or saving
{img src=images/code.png}%%% {CODE()}
<a>bla bla</a>
tracker item
Anchor links are shown all the time (instead of showing on mouseover)
tracker item
Auto-links in RemarksBoxPlugin broken (regression)
tracker item
Autolinks and italic clashes
With autolinks on, if I do:

~np~''Taken from http://climatechange.org''~/np~

the rest of the page becomes italic (the auto conversion of link breaks the closing italic tag.
tracker item
Automatic paragraph deindentation
Cutting and pasting text often involves text which has paragraphs which begin with indented lines. These could be recognized by the editors and converted into paragraphs.

If text area feature "paragraph deindent" is turned on, a line which begins with two or more spaces should be converted into the start of a paragraph. In the normal editor, this text would be moved to the start of the line and a single blank line would appear as a paragraph separator. Note that multiple blank lines before the paragraph should be compressed to a single blank line. Text with indented paragraphs often does not have a blank line between paragraphs, so the code needs to ensure that a paragraph marker exists.
tracker item
Behavior of heading anchor icons broken
tracker item
Better access for wikiplugin on the wiki editor
tracker item
Better table editor: Something like tracker inline edit but for wiki tables
Please see: ((tw:CMS Landscape)) and ((tw:Wiki landscape)) and try to edit those pages without getting lost.

Now you understand what we need :-)

Also: https://doc.tiki.org/Unified+Index

This looks cool:
tracker item
br html tags displayed in clear with nested plugins: split & tabs
tracker item
Broken links in the Wiki, if there is a comma in the URL
If there is a comma in the URL (testet in the Wiki-Module), the link isn't complete clickable.

Only the part before the comma is linked. Everything after the comma in the URL is shown as normal text in the TikiWiki.

I know, commas should not be part of an URL, but there are many webages out there, how have this.

This bug is testet on TikiWiki 2.2 and 3.0

Here an example of a broken link:

But when you use "external Link Icon" with ~091~ Link~124~ Descripton ~093~ That will work.

tracker item
Browser Tab Adapts Name of H5P App in Wiki Page
tracker item
Calendar links ignored in Wiki
Calendar can not be linked to from a Wiki page. The Wiki Syntax parser for URLs does not recognize Calendar URLs, so they do not get linked. Apparently the brackets in such URLs cause problems: tiki-calendar.php?calIds[]=1
tracker item
can not embed svg images in wiki page
I can't add an SVG image.
Even with HTML enabled, it will add an tag into my <object> tag preventing me from using SVG images.

With SVG already being an important element on the web, this is unexcuseable and needs to be fixed asap.
tracker item
Can't seem to color external links in wiki pages
If you write in a wiki page the following code:

Your link will not be colored as it should.

This has been tested on 1.9.7 and

It should work as with wiki links.
tracker item
Can't write parentheses inside the displayed text of a wiki link
If you write this:
~np~((HomePage|This (example) doesn't work))~/np~
It gets displayed as is instead of having a link with parentheses in its text.
The bug exists on 1.9.7 and at least.

This was working well with 1.8.x
tracker item
Cannot insert pretty tracker “metadata” into trackerlist
tracker item
Cannot save my changes of a wiki-page
Sorry I cannot find "wiki-pages" to check in the report-a-bug-form.

1. I edit a wiki page
2. I move the mouse over the save button
3.! I get a help-cursor and the text in the textarea scrolls to the very bottom
4.! I click on save, but nothing happens

I got this behavior REV 24514 and on your REV 24503

I get the same behavior on Firefox, Chrome and WinXP-Safari.

best regards

tracker item
Cannot save page with long ~pp~ block
I am using tikiwiki 1.9.4 together with xampp 1.5.3a for windows. When I try to save a wiki page with a large ~pp~ block like:


the page cannot be saved. If I split the block into:


things work as expected.

The page can be previewed but not saved so I suspect it has something to do with the database.
tracker item
change syntax on tracker urls to avoid square brackerts (conflict with wiki syntax)
See the problem in action:
I copied an url of a tracker item:

onto another tracker item report, but adding wiki syntax:
[http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=97&show=view&status=op&trackerId=5&sort_mode=f_41_desc&filterfield=26&filtervalue[26]=check|see tracker item]

There is some trouble with __~np~&filtervalue[26]=check~/np~__ form the url when used as external link between square brackets.
tracker item
Changing (modernizing) Tiki smileys (we should support Emoji)
tracker item
Character substitutions in page names, search engine, usernames, etc.
Since wiki page names should avoid special characters, we'll need to think about maybe using character substitutions in page names (a instead of à, _ instead of ') and use the description field for the exact format.

Please coordinate here: ((Character substitutions))
tracker item
CKEditor breaks links to wiki pages
The symptoms are:
- backlinks work sometimes only
- when deleting a page it does not always become a wanted page
- others ???

The result is:
- unpredictable behavior
- negative impact on the user acceptance

The problem is, that the syntax of the links change:
1) Type ~np~((Page 1))~/np~ in the WYSIWYG mode and save
-> ~np~((Page 1))~/np~
2) save again in WYSIWYG mode
-> ~np~<a class="wiki" href="tiki-index.php?page=Page+1" title="Page 1">Page 1</a>~/np~
3) save again in WIKI mode
-> ~np~[tiki-index.php?page=Page+1|Page 1]~/np~
4) save again in WYSIWYG mode
-> ~np~<a class="wiki" href="tiki-index.php?page=Page+1">Page 1</a>~/np~

This makes 3 1/2 different representations of a link to 'Page 1'
tracker item
CODE Plugin "eats" code, especially HTML
tracker item
CodeMirror latest 12.x : Line numbering hides everything and puts huge line breaks
tracker item
Color popup in Wiki editor is broken
The Foreground Color popup in the Wiki editor has broken in the last week, both on my site and right here on dev.tikiwiki.org. Instead of bringing up a box of colors for selection, it brings up a black line.

I suspect that the vertical size of the box was corrupted in a recent update.
tracker item
Commas stripped out of wiki pages after editing/saving/previewing.
When editing a page on dev.tw.o, I will have proper grammar and punctuation, but after I save it, it appears that all of my commas "," are stripped out in the display. When I go to edit (or even a preview from an edit), the commas also disappear from the edit window.

While not really a high priority, bad, this will crash the app bug, I think it's pretty important for someone who typed in text with proper grammar to have that show up.

*** Also noticing in the tracker, that when I submitted this ticket I had selected something in the Data Type, Feature, and Version sections, but they didn't save, as well as Area and Related Project. ****
tracker item
Content is displayed outside the remarksbox if I have a carriage return in a list
tracker item
CSS: Multilevel style numbering for ordered lists broken in 19.x
tracker item
dev.tiki.org 13.x HTML tags are showing
tracker item
Diff: notification e-mail with HTML plugin in diff shows nothing
tracker item
DIrectory - allow URI File:/// - do not default to http://
I want to use a personal WiKi for all information about a personal project.

It would be convenient to have links to local or network hard disc files in the Directory.

There are other URIs (https://) that would also be useful so the limit to http:// is unhelpful.
tracker item
Plugin parsing breaks when nested more than 7 times
tracker item
Do not confuse a series of stars (*********) with an intentional bullet point list
~np~************~/np~ can be used a seperator in an email

Typcally, if there is a large number of stars (ex.: >10) and/or there is no text after, we shouldn't convert to bullets.
tracker item
Drop Down Spoilers
tracker item
Dynamic variables broken in 1.10?
The dynamic variable syntax (~np~%dynamic_variable%~/np~) displays as plain text in my 1.10 installations, rather than functioning as designed.
tracker item
Edit textarea problems in Opera
In Opera (no need to mention version number; every Opera user uses the lastest version ;-) ), in the last day or so the edit textareas in branch 6 have been missing or misplaced, for wiki pages and trackers, that I've noticed so far. (Forum post forms are ok.) On the wiki edit page, the edit textarea is far down from the toolbar. Sometimes clicking on fullscreen edit and back again will bring it up to the toolbar. On the dev.t.o bug-submitting tracker form, the textareas for description and solution don't appear at all. I clicked on fullscreen editing and back, and a textarea appeared but it seems to be the solution textarea, not the one for the bug description. This affects the regular wiki editor; I didn't check yet about the wysiwyg editor.
tracker item
Editing Tracker TPL Files Through Tiki Edit Interface Inserts "" into TPL and Causes Error
Using the Tiki's built-in TPL file editor to change a title on a TPL page (e.g. "Admin Tracker" to "Administer Reports" for "tiki-admin_tracker.tpl" file) causes insertion of "" character sequence at several places throughout the modified "tiki-admin_tracker.tpl" file. The original "tiki-admin_tracker.tpl" is unmodified. The modified "tiki-admin_tracker.tpl" file contains "" in such places as "javascript" (rather than "javascript"), which breaks the links on the Admin Tracker tabs.
tracker item
em dash wiki syntax not functioning correctly
In 3.x, the emdash wiki syntax is not working.

In the documentation and previous releases, the following should be represented as an em dash ~--~ but it is not. It is being interpreted as strike out text.

The issue seems to appear when there is more than one em dash in a document ~--~ and seems to be linked to the last tilde.

This was posted on the discussion forums and a suggestion was made that there needed to be a space between the tildes and the dashes ~ -- ~ like so but it does not seem to work.

tracker item
Email-style wiki parsing, for webmail and for copy-paste of email conversation in a wiki page
The title says it all!
tracker item
External link don’t open in a new tab/window when in a template called by a trackerlist plugin
tracker item
Exit from an update item modal in the plugin List goes to undefined page instead of staying in the page
tracker item
Expose more variables via Wiki Argument Variables
tracker item
External link icon should be a CSS class
In tikilib.php, the external link icon is hardcoded:
{CODE(wrap="1",colors="php")} if ($prefs['feature_wiki_ext_icon'] == 'y' && !$options['suppress_icons']) {
$ext_icon = "<img border=\"0\" class=\"externallink\" src=\"img/icons/external_link.gif\" alt=\" (external link)\" />";

That is not good if you want that icon to be different.
You have to overwrite img/icons/external_link.gif with your own, and remember to re-overwrite it when updated to a new Tiki.

It would be better to either allow the user/admin to give a link to an alternative icon, or even better: put it in CSS, so that it can be overwritten in themes.

A quick fix would be to change line 5806 and line 6245 from this:
{CODE(wrap="1",colors="php")}$ext_icon = "<img border=\"0\" class=\"externallink\" src=\"img/icons/external_link.gif\" alt=\" (external link)\" />";{CODE}
to this:
{CODE(wrap="1",colors="php")}$ext_icon = "<span class=\"externallink\">   </span>";
And then put a CSS class in design.css or other appropriate css file, so that it can be overridden by theme css:
background: url(img/icons/external_link.gif) no-repeat;
tracker item
External Link icon/option missing from wiki page edit toolbar and Admin Toolbar page after 48107
tracker item
External wiki links title don't work
The title for External wiki links in not parsed, for instance
~pp~ ((wp:Link|Title)) ~/pp~
will display __Link__ instead of __Title__

We need this for *.tikiwiki.org as well
{img src=images/code.png}%%% {CODE()}
((dev:EditUIRevamp|Improve the content editing interface))
((dev:AdminUIRevamp|Improve the admin interface))
tracker item
External Wiki: optional micro icon for link, title (mouse-over), and option to open new window
Say I need to make a link such as:
{img src=images/code.png}%%% {CODE()}
[http://en.wikipedia.org/wiki/Argument_map|Argument map]

I could use an ((doc:external wiki)) link which is like this:

{img src=images/code.png}%%% {CODE()}
((wp:Argument map))

Even nicer would be an image (instead of {img src=img/icons/external_link.gif}) so the visitor knows he'll be sent to Wikipedia.

Also, would need:
*optional title: to explain what this site is about. (ex.: this is a sister community)
*option to open new window
these would be set centrally and you could override.

Perhaps the direction to take is to build with ((doc:plugin alias))
tracker item
external wikilink can interfere with internal wikilinks in a very odd way (parser bug)
This is a very odd bug. If you have an external link -+~np~[x|y]~/np~+- somewhere on the page where x and y can be anything (even including whitespace), any internal links of the form -+~np~((...x|y...))~/np~+- or -+~np~((...x|y...|...))~/np~+- where the "..." can be anything (even including whitespace) are screwed up. Copy and paste the following examples into a page to see.


moved example to comments because it was breaking trackerlist reports
tracker item
Facilitate links and syntax
There are many pages within t.o that have spaces. On the other hand, the WikiSyntax historically uses WikiWords. I also see that tiki supports aliases for pages. This led me to the following suggestion:

- Propose to render WikiWords as "Wiki Words" in the page. This makes it easier to read. Obviously this mean one control more ...
- When parsing a page, and there is no page for a specific WikiWord, look for the page 'Wiki Word' (adding a space before each capital).

Advantage : this would allow people coming from other wikis to make links with WikiWords, even for pages like ((Wiki Plugins)), without the need for clumsy parenthesis everywhere.
tracker item
Fade plugin should deal with line breaks + deal with empty body
New fade plugin is cool.

#If body is empty, plugin should not be clickable
#However, if there are line breaks in the body, the are no longer in the fade.
#Also, should have a setting, default to y for little icons:
{img src=images/code.png}%%% {CODE()}
[-] [+]

tracker item
Fail to set default value to user defined variable
tracker item
First item in numbered Headings (for maketoc and auto-toc) does not get a number
tracker item
font colour and background colour drop downs 'empty' in wiki editor
tracker item
Formatting of empty Lines in Wiki-Pages is not handled properly
A blank line out of a paragraph should not start a new paragraph (as in 4.2). If feature_wiki_paragraph_formatting_add_br is on, an empty line is created on top of the new paragraph.
It comes from lib/tikilib.php line 6838ff
} elseif (!$in_paragraph && !$contains_block) {
// If not in paragraph, first non-blank line; start a paragraph; if not start of div created by plugins
$data .= "<p>";

in the comment it is stated that the paragraph should only begin at first NON-BLANK line
tracker item
Full screen edit button visible in quicktags, even if option is disabled
The Full Screen edit button is visible in my quicktags list, even though I have the __Allow fullscreen edit__ option disabled.
tracker item
Generate footnotes at the bottom of a wiki page
Like Wikipedia

In a more advanced form, the references could be kept in trackers, as Tiki would be a
[http://info.tikiwiki.org/Use+Cases#Bibliography_D_|Bibliography Management System].

[wish1769|Bibliography management system (references)]
tracker item
Generate valid RSS feeds from wiki pages, useful for ad serving and remote management of content, like a site footer
This is an RSS feed:

It's not the traditional way of using RSS but it can be very useful :-) It permits us to get up to date info (Ex.: number of devs, number of downloads, etc.) from SourceForge, using RSS. We can then publish on http://info.tikiwiki.org/

This idea could be used for serving ads.

This is also in the same idea as:

Two immediate uses
# Manage the footer of all *.tikiwiki.org sites from one place
# Permit to push news & calls to action (Current version of Tiki, vote for Tiki in an Award, new release, etc)

Tiki5 as of now:

Tiki4 as of now:

{wish id=1396}

tracker item
Get maketoc working in WYSIWYG edited pages.
Not totally sure if this is feature request, bug, or lack of knowledge. Basically I need some way of supporting maketoc with WYSIWYG pages.
tracker item
Greater than three hyphens in pages does not give you a horizontal rule
~np~When using three hyphens (---) you get a horizontal rule in v3.0 Beta 3, but if you use more than three hyphens (i.e. ---- ----- or ---------), you will not get a horizontal rule on the page. Greater than three hyphens was valid in version 2.x of TikiWiki to create a horizontal rule.~/np~
tracker item
Handling [[Text] in Trunk does not produce [Text] but a link in 6.0 trunk
I got a strange problem when writing a text in square brackets (in trunk):

~np~[[These brackets] should stay~/np~

should result in the output
~np~[These brackets] should stay~/np~
but they produce
~np~<a class="wiki" href="These brackets" rel="">These brackets</a> should stay~/np~
It works as expected in 5.0
tracker item
Headings in included pages end collapsible sections in parent page
tracker item
horizontal rule "- - -" does not work with more than three hyphens ("-")
When creating a horizontal rule previous version of Tiki wiki 2.x allow you to use multiple hyphens (>3).

~np~i.e. "---------------" in 2.x version would produce the same horizonttal rule as: "---"~/np~

~np~In 3.0 Beta 3 the only valid horizontal rule creator is three hyphens (---), not more than three hyphens.~/np~
tracker item
H5P Collage Flies out of Constrained Area in Cached Wiki Page
tracker item
html in tiki page
I try to submit a wiki page with html text.
The submit never finish and I have a message :

Fatal error: require_once() [function.require]: Failed opening required 'lib/htmlpurifier/HTMLPurifier.auto.php' (include_path='/htdocs/public/www/lib/pear:.:/usr/local/lib/php:/htdocs/public/www/lib/core/lib:/htdocs/public/www/') in /htdocs/public/www/lib/htmlpurifier_tiki/HTMLPurifier.tiki.php on line 19

I don't understand because all php page are ok.

tracker item
if use a chinese character in a page's name, can't use (()) to refer to that page.
just like this ((text中文))

it can't be parsed correctly as a page referer.
tracker item
If you edit via an Edit Section button, you don't see a Switch Editor button when editing
If you click on an Edit Section button, the Switch Editor button is not available when you are editing.
tracker item
Images Will Not Show Side by Side with Captions
tracker item
Implement RFCWiki 4.13.1 Block Indent
Tiki's wiki syntax provides no equivalent of the HTML blockquote tags. Most (if not all) of the major literary stylebooks require that quotations longer than 2 lines be set forth as a separate paragraph indented ''on both sides'' and single spaced. In the judicial setting, this is universally required by court rules.

The [http://tikiwiki.org/tiki-index.php?page=RFCWiki|RFCWiki draft] specifies support for this syntax feature in section 4.13.1 as follows:

A block indent is created by using the minus (-) with the greater character (>) at the beginning of the line. The number of minus characters defines the indentation.

-> Block indent level 1
--> Block indent level 2

The material quoted above should, of course, be blockquoted. :-)

This may seem surprising, but this is a very important feature to us. We are preparing an integrated free and open source solution for law offices. We want to use Tiki as one foundation of that solution. But legal professionals are going to howl if they can't have their indented quotations.
tracker item
Indent Syntax like MedaWiki with leading colon (“:”)
No indent
: One indent
:: Two indents

Please see:
tracker item
Object Link tool broken (hangs forever or does not insert link)
tracker item
insufficient wiki parser/validator (Invalid URI supplied)
tracker item
Internal Server Error 500 on preview or save
I posted this on the Features/Usability forum pn tw.o, but it seems to be coming down to a bug or a setting.

We've been wrestling with Internal Server Error 500 for several months. We are transferring the content of a static HTML site to a TW site.

At first, we thought it had to do with the length of documents or reserved words or special characters. All of that may still be true, but what I find after exploring the Web a little is that it has to do with script failure. Apache thinks something is screwy in the content being fed to it.

Most recently, I tried to get the TW sql module to work. I set up the DSN per the instructions on doc.tw.o , assigned permissions to a group,then created a test page. I inserted one line,


then hit Preview and got Error 500 immediately. (Obviously, I've substituted words for characters like the curly brace and space. I did that so I wouldn't get Error 500 when I up load this message. And, yes, I know "up load" is one word, but if I use one word, it is likely to fail.)

We have previously gotten the Error 500 message when words like 'up load' and 'se lect' (as noted above) were in the text of the page. When those words are removed or altered, the page up loads.

It tends to happen more often when pages are long (that may be psychological. You remember the BIG failures.) which, of course, just means the odds are greater that a reserved word is used, if that's the case.

When I tried to up load the above example to tw.o, it failed three times until I had all the curly braces and suspect words broken up. I know others are having this same issue. Here's chibaguy from tw.o on his experience up loading in response to my message. (I've edited for brevity)
chibaguy on Fri 16 Nov, 2007 08:08 CET

I tried once to reply to your post and got the 500 error when I had "se lect" in the text (with no space), and then the submit went smoothly when the space was added. A few minutes later I submitted that test post, with "se lect" intact and it also went fine. Meanwhile I found 469 instances of the word at this site, including in wiki pages and forum posts, so obviously a lot of the time having "reserved words" in posts doesn't stop the submit.
I've also gotten the 500 error here trying to submit a post, once in a while, but waited a little while and then could submit exactly the same post with no error.
I rarely get the error at other Tiki sites I use pretty intensively, but am not sure if my pattern of use just avoids the pitfalls.

-- Gary

ricks99 on tw.o leapt on the cut and paste scenario, offering that it might be a text encoding conflict. I've had it fail, as above, with directly entered content as well as pasted content. I'm on a Mac and our host is using *nix.

Note that I'm not saying some text encoding issue isn't a part of it. In fact, I kind of suspect there is more than one culprit.

When I get one of these errors, I start reducing the up load by halves, previwing a portion at a time, until I get failure. Once I get failure, I always get failure.

We've up loaded (copy/paste) pages of documents in which one line would cause the failure. Removing the one line makes it OK. Taking the suspect portion and the remaining text and putting it into a comment page works, too.

My suspicion is that there may be a combination of "suspect" words that crosses a threshold and drops the error message on us. Maybe there's a setup issue?

I'd really like to use the SQL plugin. It would solve several problems for us. Thanks,



This is the third in a series of "HOW DOES IT WORK" articles describing the various systems of the TD Vixens. The first two described the engine cooling and coach heating systems. This article will describe the engine fuel system.

By Tom Picking

When I first got my Vixen it was hard to start. The problem got worse until I was afraid to go anywhere. I spent several weeks studying the system and talking to other owners about what might be wrong. I tried many "fixes" hoping they would solve the problem but nothing helped. I learned a lot about the system over those weeks with the help of several people and only after fully understanding "HOW IT WORKS" was I able to find and correct the problem. VIN 0050 is stock with 110,000 miles and starts easily even after being idle for weeks. Yours should, too!

The BMW engine's Bosch fuel injection pump, in my opinion, is a work of art! It is completely mechanical using no electricity (except for the fuel shut off valve) or electronics. It is a very complex system and adjustment or repair of the fuel injection pump should be left to professionals. But if we understand howthe total system works, we should be able to determine if the problem is in the pump or some other component of the system that we can fix ourselves.

In order for a diesel engine to start and run it needs three things: Air, fuel, and heat. It is also very important to make sure that no air can mix with the fuel until the fuel gets into the combustion chamber.

When the starter cranks the engine, air is sucked in and compressed by the pistons. When air is compressed, it gets very hot, hot enough to ignite fuel if it is present. On very cold days the engine and the air being drawn in are much colder making it difficult for the air to reach the temperature required for ignition. This is where glow plugs come in. They are actually small electrical heaters inside each combustion chamber. They look something like a spark "plug" and when turned on they get so hot they actually "glow". The glow plugs only come on during the initial start up sequence and the amount of time you should wait before trying to start the engine is determined by the engine electronics based on the temperature of the engine. Maximum ON time is about 15 seconds. The "WAIT TO START" light on the dash indicates the glow plugs are being commanded on and the engine should not be cranked till they have had a chance to do their job. If the glow plugs are not working, the engine will still start (except on very cold days) but only with increased cranking times.

Air in the fuel before it is injected into the engine is a bad thing. The injector pump must be able to develop very high pressure in order to force the fuel into the combustion chamber and if air is mixed with the fuel, this high pressure cannot be achieved.

The injector pump is actually two pumps in one. The first is a low pressure priming pump that floods the primarypump chamber. Any air in this chamber is forced out of a drain line at the top of the chamber along with excess fuel flow from the priming pump. This drainline is common with the drain lines connected to the injectors in each cylinder. If any of these lines leak while the engine is off air will enter the system and fuel will drain backward through the fuel line and empty the primary chamber of the injector pump. The result is hard starting (delayed while the priming pump is filling the primary chamber) but otherwise a normal-running engine.

If there is a leak in the fuel line or the fuel filter between the injector pump and the fuel tank, air will be drawn in by the suction of the injector pump and, depending on the amount of air, the engine may start but will not run correctly under load or high speed. As reported by Charles Rausch (TD 0106) in December's issue of Fox Prints, this same symptom can be experienced if there is a severe restriction in the fuel line such as a clogged fuel filter or a clogged fuel tank filler cap air breather vent.

You can inspect the fuel entering the pump by checking the clear (after 12 years mine is yellow) plastic line connecting the fuel filter and the pump. If you see bubbles in this line while the engine is running or cranking there is a fuel line problem. If you see a large bubble in the line after the engine has been off for several minutes, this is an indication of a drain line problem and that fuel is draining backwards through the fuel line to the tank. If you tap the line, with an indication of air in it, you can watch which side the air bubbles up. That will cut the investigation in half.

Between the tank and the injector pump is a fuel filter. The stock filter has a special manual priming pump built into the head of the filter. Turning the selector head of the filter pump to "RUN" bypasses the internal check valve and makes it easier for the engine injector pump to draw fuel. Turning the head of the filter pump to "PUMP" allows manual operation. The engine will run just fine with the filter pump selected to either position if all the rest of the system is in good condition. Diesel fuel is notorious for dirt and water. The fuel filter is your protection against dirty fuel.

After I learned all of the above, my Vixen still would not start! The problem was that it was not getting fuel because of an electrical problem!

The ignition switch mounted on the steering column (a standard GM part) has several electrical contacts that perform various functions depending on the position of the key in the ignition. One of the functions is to energize the fuel shutoff solenoid valve that allows the flow of fuel to the injector pump. One of the first things I did was to check the voltage to the solenoid valve with the key in the ON position, it was OK. What I didn't realize until several weeks later is that a different set of contacts energize this valve when the key is in the START position. These contacts were defective and when the key was in START and the engine was cranking, the solenoid valve was off and no fuel was available!!!!! This condition can be measured with a voltmeter which eliminates the guess work. A new ignition switch solved the problem.

tracker item
internal wikilinks inside tables are very buggy (parser bugs)
There are lots of possibly-related bugs here and they're all related to internal wikilinks within tables and a certain lack of whitespace, so I'll just list examples (copy and paste this into a page):

!!-Examples (warning: wide)
works fine

~np~<td class="wikicell">foo</td><td class="wikicell">bar<a href="tiki-editpage.php?page=foo%FF298432%FFbar" title="Create page: foo%FF298432%FFbar" class="wiki wikinew">?</a></td>~/np~

!!!~np~||((foo t))|((bar t))||~/np~
||((foo t))|((bar t))||
~np~same problem as ||((foo))|((bar))||~/np~

~np~<td class="wikicell" colspan="2">baz<a href="tiki-editpage.php?page=foo%FF298432%FFbar" title="Create page: foo%FF298432%FFbar" class="wiki wikinew">?</a></td>~/np~

!!!~np~||((foo t))|((bar t|baz t))||~/np~
||((foo t))|((bar t|baz t))||
~np~same problem as ||((foo))|((bar|baz))||~/np~

~np~<td class="wikicell">boo</td><td class="wikicell" colspan="3">bar<a href="tiki-editpage.php?page=foo" title="Create page: foo" class="wiki wikinew">?</a></td>~/np~

!!!~np~||((foo t|boo t))|((bar t|baz t))||~/np~
||((foo t|boo t))|((bar t|baz t))||
~np~same problem as ||((foo|boo))|((bar|baz))||~/np~

works fine

~np~same problem as ||((foo))|((bar|baz)||~/np~

||text|((foo t))|((bar t|baz t))||
~np~same problem as ||((foo))|((bar|baz)||~/np~

~np~nospace disappeared! <td class="wikicell">text</td><td class="wikicell" colspan="3">baz<a href="tiki-editpage.php?page=foo%FF290656%FFbar" title="Create page: foo%FF290656%FFbar" class="wiki wikinew">?</a></td>~/np~

!!!~np~||text|((foo t))|nospace|((bar t|baz t))||~/np~
||text|((foo t))|nospace|((bar t|baz t))||
~np~same problem as ||text|((foo))|nospace|((bar|baz))||~/np~

~np~same problem as ||((foo|boo))|((bar|baz))||~/np~

!!!~np~||text|((foo t|boo t))|nospace|((bar t|baz t))||~/np~
||text|((foo t|boo t))|nospace|((bar t|baz t))||
~np~same problem as ||((foo|boo))|((bar|baz))||~/np~

!!!~np~||text|((foo))|has space|((bar|baz))||~/np~
||text|((foo))|has space|((bar|baz))||
works fine

!!!~np~||text|((foo|boo))|has space|((bar|baz))||~/np~
||text|((foo|boo))|has space|((bar|baz))||
works fine

I think the code responsible for this just needs a total rewrite.
tracker item
InterTiki backlinks / SisterWiki / Extend External Wiki feature
((doc:InterTiki)) permits to share login, preferences and groups between various Tiki sites.

We need the Sister Wiki too!
Continue discussion here: ((Sister Wiki))

((doc:backlinks)) are very cool. But what about backlinks from other sites?

We could use list from:

[wish2086|Backlinks between trackers and wiki pages (and maybe forums)]
[wish1768|Tracker plugin to get title and make link to tracker item]
tracker item
Invalid XHTML for id attribute in headings
Tiki automatically includes the "id" attribute for headings. For example:

!my heading

<h1 id="my_heading">my heading</h1>

By default, the value of __id__ is the text of the heading. However, as per the XHTML specification, __id__ ''must'' begin with a letter -- not a digit.

Therefore, if I have:

!2009 Highlights

Tiki generates:
<h1 id="2009_Highlights>my heading</h1>

Which is invalid.

See http://validator.w3.org for details.
tracker item
After Upgrading 6.3 -> 8.0rc1 split shows ~lt~br /~gt~ instead of linebreaks
I updated a copy of our wiki to 8.0rc1 to have a look whats new

but the first thing i saw was that all line breaks in the heavily used split-plugin were actually displayed as ~lt~br /~gt~ instead of being actual line breaks
tracker item
After Upgrading 6.3 -> 8.0rc1 split shows ~lt~br /~gt~ instead of linebreaks
I updated a copy of our wiki to 8.0rc1 to have a look whats new and just wanted to tell you the first problem i immediately saw:

but the first thing i saw was that all line breaks in the heavily used split-plugin were actually displayed as ~lt~br /~gt~ instead of being actual line breaks
tracker item
In Tiki 2.4 the syntax below work:

~np~{img src="img/wiki_up/cabeçalho" }~/np~

In Tiki 6.4 and trunk it doesn't (I haven't tested with other versions).

The problem is the special character "ç" in the image file name.

This bug was introduced in r22212 (http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki?view=revision&revision=22212). If you remove the call to htmlentities() the problem is solved but I'm assuming this function is there for a reason.
tracker item
Don't work page name display stripper ::
When I setup page name display stripper as __::__ don,t work wiki link wishout |

lib\parser.lib line 1705
// Center text
if ($prefs['feature_use_three_colon_centertag'] == 'y') {
$data = preg_replace("/:::(.+?):::/", "<div style=\"text-align: center;\">$1</div>", $data);
} else {
$data = preg_replace("/::(.+?)::/", "<div style=\"text-align: center;\">$1</div>", $data);

This code replase __::__ on "<div style=\"text-align: center;\">$1</div>"

tracker item
@user wiki syntax
Related to {wish id=1409}, it would be nice to have a syntax to leave messages to people or groups on wiki pages
* It could send an alert

tracker item
Screencast & Copy-Pasting an image
Discussed on wiki pages:
* ((Screencast))
* ((Copy-Pasting an image))
tracker item
Review all HTML5 tags and consider support for missing tags like ABBR and ACRONYM

This is already possible via ((doc:PluginTag)) but dedicated plugins could be cleaner/simpler in certain cases
tracker item
"Change" and "Save" buttons are missing when typing a "new wiki page" name with forbidden chars (such as &) and proceeding to the editor-page for this site.
After clicking "create new wiki page", i typed a name for this site containing a forbidden char (in this case "&"). I prompted this entry (not knowing this char is forbidden) to add content to this page.

the "invalid character" field popped up and forced me to rename the page. looked similar to the normal "rename page" input, but without a button to "save" the change.

unfortunately, the save button was also missing in the editor field for my new page and "previewing" the new site didn't change anything in this behaviour.

so in the end - content as well as the page were lost.

please add "save" buttons to this areas.
tracker item
PluginTabs does not show edit button of other Plugins used inside a tab
Any other Plugin used within PluginTabs doesn't show the edit button. It is not possible to edit them itself like it was before.
For Example, Tab1 with CODE and Tab2 with FANCYTABLE:

{TABS(tabs="code|fancytable|box" toggle="y")}
tracker item
PluginFancyTable has display problems when using plugins inside
several problems in Fancytable:
1. Field separator '|' (pipe) is not working with plugins. (must use '~|~' to get it work)
2. any plugin which is used in fancytable is looking fine when only one line is in. When you add a second line, you will get a lot of html viewed.

here is an example i used to figure out these problems:
{FANCYTABLE(head="code|box" colwidths="50%|50%")}{CODE(caption="code with 1 line" colors="sql")}select sysdate from dual;{CODE}~|~{BOX(title="box with 1 line")}1st line in a box{BOX}
{CODE(caption="code with 2 lines" colors="sql")}select sysdate from dual;
select sysdate from dual;{CODE}~|~{BOX(title="box with 2 lines")}1st line in a box
2nd line in a box{BOX}{FANCYTABLE}
tracker item
Wiki Page Source presented inconsistently in Source & Compare frames v6.7
In the source of a wiki page (current or prior version) double quote marks appear as a single character "

However, when viewing the same source in version compare mode, those same double quote marks are shown as the html & quot ; (spaces added to prevent any translation)

Look at the source line beginning ~np~__Spouse1:__~/np~ in the attached screen shots.

TRP-Compare-v4-5 used the following url [http://thereevesproject.org/data/tiki-pagehistory.php?page=Heard_Robert_Brookes_2236&history_offset=0&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=5&oldver=4&paginate=on&history_pagesize=25&source=5]

TRP-Compare-v4-0 came from [http://thereevesproject.org/data/tiki-pagehistory.php?page=Heard_Robert_Brookes_2236&history_offset=0&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=0&oldver=4&paginate=on&history_pagesize=25&source=0]

Sorry, but these pages will not be accessible as our site isn't available at that level of permission to non members, but I thought I should include them to point at the problematic screens.

NB All the changes to this page now being viewed were made several months ago using v4.3

Perhaps related to existing item HTML line break tags displayed in page source histories [http://dev.tiki.org/item3883], which are evident if the source of other than the current version is displayed and compared.

But note the line break tags are not displayed in the source comparison part of the screen where the & quot is found.

These inconsistencies are confusing, but not show stoppers in our upgrade to 6.7



This issue is obviously wider than the instance I've described above. We now have an example of & quot ; (without the spaces) appearing on a rendered page - look at child 5 Elizabeth on page [http://thereevesproject.org/data/tiki-index.php?page=Reeves_William_3054] which is publicly visible. The source of that page clearly shows double quote marks not html as follows ...
{CODE()}__Probable children of William Reeves and Anne Terrill__:
#((Reeves_Sylvia_3219|Sylvia Reeves)), b. 1792, m. Allan Burton before 1810
#((Reeves_Jennie_3218|Jennie Reeves)), b. c1794, m. Rev. Hardin Burton on 6 Dec 1815
#((Reeves_John_3282|John Reeves)), b. c1796
#((Reeves_Obedience_3217|Obedience Reeves)), b. c1796, m. William Buchanan Burton on 25 Oct 1814
#((Reeves_Elizabeth_3287|Elizabeth "Betsy" Reeves)), b. c1801, m. John Barton on 16 Apr 1822 in Grayson VA
#((Reeves_Anne_3299|Anne Reeves)), b. c1803, m. Terrell Cox
#((Reeves_Terrill_3283|Terrell Reeves)), b. c1807
#((Reeves_Lenoir_3284|Lenoir Reeves)), b. 1808
#((Reeves_Albert_3302|Albert Reeves)), b. c1813
#((Reeves_Gaston_3286|Gaston Reeves)), b. c1814
#((Reeves_William_3285|William Reeves)), b. c1818
#((Reeves_Timothy_3303|Timothy Reeves)), b. 1821
#Unknown Female born after 1820{CODE}

Let me know if this is a discrete issue and whether I should raise a separate ticket for it.


tracker item
Tables of Contents (maketoc) can be broken when headings call plugins (such as ANAME and FOOTNOTE)
Calling plugins in headings in pages where maketoc is used can cause breakage. For example, this happens when calling the ANAME or FOOTNOTE plugins.

! Effect on ANAME
Although Tiki generates anchors for all headings automatically, I find using ANAME is a great way of creating manageable and easily memorable Anchors for otherwise unwieldy headings
If a heading within a tiki page is coded as follows
{CODE(caption="1. Tiki Source Code snippet" wrap=1)}
!! Fourth and Even More Forgetful Heading{ANAME()}Quick4{ANAME}
{CODE}then Tiki generates the following HTML code
{CODE(caption="2. Generated HTML snippet" wrap=1)}
<h3 class="showhide_heading" id="Fourth_and_Even_More_Forgetful_Heading"> Fourth and Even More Forgetful Heading<a id="Quick4"></a></h3>
{CODE}which can be exploited by
{CODE(caption="3. Tiki Source Code snippet" wrap=1)}
{ALINK(aname=Quick4)}Link to Fourth Heading by its Quick4 Anchor{ALINK}
{CODE}All the above works flawlessly.

However, add MAKETOC to the page above the source line where ANAME is last used and it breaks the ANAME anchor(s). For this example, the maketoc is restricted to level 2 headings only as ~np~{maketoc levels="2"}~/np~ which makes the generated HTML a little more compact.
Tiki generates the following HTML in response to the inclusion of maketoc
{CODE(caption="Generated HTML for maketoc snippet 3" wrap=1)}
<ul><li><a href='#First_Level_Two_Heading' class='link'> First Level Two Heading</a>
</li><li><a href='#Second_Long_and_Equally_Unmemorable_Heading' class='link'> Second Long and Equally Unmemorable Heading</a>
</li><li><a href='#Third_Painfully_Difficult_Heading' class='link'> Third Painfully Difficult Heading</a>
</li><li><a href='#Fourth_and_Even_More_Forgetful_Heading' class='link'> Fourth and Even More Forgetful Heading<a id="Quick4"></a></a>
</li><li><a href='#Fifth_Long_and_Not_Very_Memorable_Heading' class='link'> Fifth Long and Not Very Memorable Heading</a>
</li></ul></li></ul><!--toc--></div><br />
{CODE}Note how the entry for the Fourth Paragraph has the anchor "Quick4" associated with it. The HTML code generated for the Fourth Paragraph heading remains identical.

The effect of this is that the tiki anchor Quick4 is now incorrectly linked to the TOC entry, being the first instance of HTML ANCHOR within the HTML file.

If the MAKETOC plugin is included below the ANAME, then the ANAME works as intended, since that is the first occurrence of the generated HTML ANCHOR statement.

I have a couple of test pages which illustrate this issue, if they are of any use in your testing.

! Effect on FOOTNOTE
Calling FOOTNOTE returns an HTML A element with an id, so using that same identifier twice causes invalid HTML. Additionally, since browsers favor the first element using the identifier in such cases, the TOC's instance wins if ~np~{maketoc}~/np~ precedes headings, which is not what we want.

! Cause
Plugin calls are executed in parse_first(). (Calls to plugins in "html" format are replaced by alphanumeric fingerprints.) After, parse_data_process_maketoc() is called and expands "~np~{maketoc}~/np~" to headings, so that each plugin call in a heading in the TOC has its result (or fingerprint) twice in the source. (After, replace_preparse() replaces fingerprints with the result of plugin functions (stored during parse_first's execution).)

This issue happens because maketoc therefore causes a plugin call's result to be repeated in the TOC (instead of possibly executed again specifically for TOC-s), which has 2 problems:
* plugins don't expect their output included twice in the page, so some (such as ANAME) may use HTML's id attribute in a manner incompatible with maketoc, causing invalid HTML
* plugins don't expect their output to be included in an HTML A element, so some (such as FOOTNOTE) for example generate links themselves, again causing invalid HTML
tracker item


The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Articles & Submissions
BigBlueButton audio/video/chat/screensharing
Browser Compatibility
Communication Center
Contacts Address book
Contact us
Content template
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Draw -superseded by Diagram
Dynamic Content
Dynamic Variable
External Authentication
Featured links
Feeds (RSS)
File Gallery
Friendship Network (Community)
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Inter-User Messages
Kaltura video management
Live Support
Logs (system & action)
Lost edit protection
Meta Tag
Missing features
Visual Mapping
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Performance Speed / Load / Compression / Cache
Revision Approval
Search engine optimization (SEO)
Semantic links
Shopping Cart
Site Identity
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Staging and Approval
Syntax Highlighter (Codemirror)
Tell a Friend
Terms and Conditions
Token Access
Toolbar (Quicktags)
User Administration
User Files
User Menu
Webmail and Groupmail
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives

Useful Tools