Loading...
 

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
{maketoc} in a wiki page wich contain TABS plugin
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.

best,

Renaud

PS : e.g. : http://code.renaudrubiano.com/tiki-6.1/tiki-index.php?page=test#Lorem_ipsum_dolor_sit_amet
tracker item
{TAG(tag=ul)}...{TAG} screws up paragraphs and line breaks after plugin usage
This is best explained with an example:

~pp~
Paragraphs are parsed

just fine here

{TAG(tag=ul)}foo{TAG}

but now

paragraphs and

line breaks aren't working!
~/pp~

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
Koichi
Contributors
tracker item
Caldrac
Contributors
tracker item
snarlydwarf
Contributors
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
jonnybradley
Contributors
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.

http://tikiwiki.org/tiki-searchindex.php?highlight=javascript&search=

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
TikiWiki 2.0: Odd Tags get Inserted into HTML Code
This is actually related to two other bugs reported by SEWilco, and discussed in IRC:
http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=1910
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1911

On August 6, 2008, we upgraded to TikiWiki 2.0 using the latest and greatest code from SVN. Following this, I noticed one very odd behavior:

Basically, an 'x' bracketed by < and > is inserted randomly into various words whenever I went to edit / preview a page in the Wiki. It mainly happens on the words 'style' and 'mouseover' but I am sure there are many others affected similarly.

I did the following
1. Login to the Wiki
2. Click the "Edit" / pencil icon at the upper right hand corner of the home-page
3. Click the "preview" button

Here is a sample of the code that gets created (brackets removed )
''
table stxyle="width:100%;"
tr
td stxyle="width:43%;border: thin solid #000000; border-width: 1px 1px 1px 1px"
bTable of Contents/bbr
{maketoc}
/td
td stxyle="width:2%" /td
td stxyle="width:55%;vertical-align:top;border: thin solid #000000;background-color:#eaeaea; border-width: 1px 1px 1px 1px"''

I understand that this is done to prevent dangerous HTML insertion. However, allowing HTML to our site is essential, as it gives us a lot more flexibility in formatting than does the limited Wikitext markup.

Is there any workaround for this, or a proposed fix?
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 }||
{CODE}


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

http://profiles.tikiwiki.org/Admin

{WANTEDPAGES()}{WANTEDPAGES}
tracker item
Cyril
Contributors
tracker item
omstefanov
Contributors
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:

<table>
<tbody>
<tr>
<td></td>
</tr>
</tbody>
</table>

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://sourceforge.net/projects/halo-extension/files/SMWHalo%201.5.3_b36/MediaWiki%20extensions/wysiwyg-1.4.1_3.zip/download|Download]
[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
Hi,

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)

Regards,
Yannick

--------------------
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:
http://tikiwiki.org/tiki-editpage.php?page=TikiFestBarcelona2
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:
{CODE()}
!!-

!!!-

etc.
{CODE}

Reproduced recently here:
[http://r-help-es.ourproject.org/tiki-pagehistory.php?page=Bienvenidos&history_offset=0&diff_style=sidediff&diff_style=sidediff&show_all_versions=y&compare=Comparar&newver=0&oldver=18&tra_lang=ca&paginate=on&history_pagesize=25|r-help-es.ourproject.org]

I just editted the
{CODE()}
{rss id=1}
{CODE}

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

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:
http://r-help-es.ourproject.org/tiki-pagehistory.php?page=Bienvenidos&preview=19

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:
http://dev.tikiwiki.org/bug2727
tracker item
Accessibility warning caused by redundant link title on wiki links
tracker item
Add AJAX preview tab to more textareas
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">.....

and

~np~[http://foo.com]~/np~ would become:
<a href="http://foo.com" title="External link">.....
tracker item
Adding an indent (+) after a Autonumbered Headings (#) should not be require to keep the text properly formatted in the wiki syntax
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' />
{CODE}

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

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.

Reference:
http://sourceforge.net/tracker/index.php?func=detail&aid=1648006&group_id=114997&atid=670234
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
Ajax
wiki
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.

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

after preview or saving
{img src=images/code.png}%%% {CODE()}
<a>bla bla</a>
{CODE}
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
Autotoc broken for HTML headings
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:
http://twiki.org/cgi-bin/view/Plugins/EditTablePlugin
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:
http://this-is-a-testlink.com/foo,bar

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

TheDayAfter
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:
~np~[http://website.com|~~#FF0000:Site~~]~/np~

Your link will not be colored as it should.

This has been tested on 1.9.7 and 1.9.10.1

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 1.9.10.1 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
Thomas


tracker item
Cannot save page with long ~pp~ block (copy)
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:

~pp~
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
~/pp~

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

~pp~
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
~/pp~
~pp~
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
~/pp~

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:
{CODE()}
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
{CODE}

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:
Example:
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
Comments are rendered
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 contents in userdefined modules crashes tiki
If you define a {MODULE} - Tag in a dynamic content element and add the dynamic content to a user module ( with use of wiki parser ). Tiki shows a blank page.
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)\" />";
}{CODE}

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>";
{CODE}
And then put a CSS class in design.css or other appropriate css file, so that it can be overridden by theme css:
{CODE(wrap="1",colors="css")}.externallink
{
background: url(img/icons/external_link.gif) no-repeat;
}{CODE}
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))
{CODE}
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]
{CODE}

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

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

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.

!!Examples

moved example to comments because it was breaking trackerlist reports
tracker item
External Wikis; Bad name, badly documented and hard to find from the Control Panel area
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.
http://doc.tikiwiki.org/PluginFade

#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()}
[-] [+]
{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
Fix screwed up anchors in Tiki pages
tracker item
Fix the wiki syntax parser to exclude closing parenthesis from the external URLs links
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].


Related:
[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:
http://sourceforge.net/export/rss2_projsummary.php?group_id=64258


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.
http://en.wikipedia.org/wiki/Ad_serving

This is also in the same idea as:
http://dev.tikiwiki.org/Connect
http://tikiwiki.org/Viral+Tiki

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:
http://tikiwiki.org/tiki-index_raw.php?page=rsstest

Tiki4 as of now:
http://info.tikiwiki.org/tiki-index_raw.php?page=DeployWikiPageContentAsRSS



Related
{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
HTML rendered as code instead of displaying content properly
tracker item
HTMLpurifier no longer permits to use Paypal buttons (starting in Tiki4)
In Tiki 3.x, it worked fine.

Upon upgrade, when there is an edit, some of the HTML is stripped.


{CODE()}
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<input type="hidden" name="cmd" value="_s-xclick">
<input type="hidden" name="hosted_button_id" value="10235687">
<input type="image" src="https://www.paypal.com/fr_XC/i/btn/btn_paynowCC_LG.gif" border="0" name="submit" alt="PayPal - la solution de paiement en ligne la plus simple et la plus sécurisée !">
<img alt="" border="0" src="https://www.paypal.com/fr_XC/i/scr/pixel.gif" width="1" height="1">
</form>
{CODE}

This is caused by HTML Purifier (in Admin > Security)
tracker item
Dogfood; Issues with social network icons alignment on Safari at tiki.org
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.

Example:
-> 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
Improved include in wiki pages
tracker item
Incorrect handling of HTML data with CSS as style attributes in user modules
Creating a new user module with the following HTML content:

{img src=images/code.png}%%% {CODE()}
<a href="http://www.oneplusyou.com/bb/geek" style="background: url('http://www.oneplusyou.com/bb/css/img/quiz/geek_badge.jpg') no-repeat; display: block; width: 268px; height: 82px;">50% Geek</span></a>
{CODE}

As this seems to affect html or code parsing in tikiwiki in general I can't include the text here as it is shown to me (not even as CODE), so I'll describe:

TikiWiki parsers insert a html/xml open tag with name "x" between letters "r" and "l" of the word url used for background definition. This even happens here in the tracker when displayed in edit mode, but doesn't seem to affect html display. When used in user modules the image is not shown because the resulting code is reduced to:

{img src=images/code.png}%%% {CODE()}
<a href="http://www.oneplusyou.com/bb/geek" style="display: block; width: 268px; height: 82px;">50% Geek</a>
{CODE}

If TikiWiki supports style attributes and their content, then this should be fixed.

Thanks
tracker item
Indent Syntax like MedaWiki with leading colon (“:”)
No indent
: One indent
:: Two indents

Please see:
http://www.mediawiki.org/wiki/Help:Formatting
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,

OPEN CURLY BRACE SQL CLOSE CURLY BRACE (db=>memberlist) SE (NO SPACE)LECT count(*) FROM members OPEN CURLY BRACE SQL CLOSE CURLY BRACE,

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,

Bill

------

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
ENGINE FUEL & ELECTRICAL

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.
AIR AND HEAT

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 AND FUEL

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)
~pp~
!!!~np~||((foo))|text||~/np~
||((foo))|text||
works fine


!!!~np~||((foo))|((bar))||~/np~
||((foo))|((bar))||
~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~||((foo))|((bar|baz))||~/np~
||((foo))|((bar|baz))||
~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~||((foo|boo))|((bar|baz))||~/np~
||((foo|boo))|((bar|baz))||
~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~


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


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


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


!!!~np~||text|((foo))|nospace|((bar|baz))||~/np~
||text|((foo))|nospace|((bar|baz))||
~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~||text|((foo|boo))|nospace|((bar|baz))||~/np~
||text|((foo|boo))|nospace|((bar|baz))||
~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
~/pp~

!!
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!
http://www.wikimatrix.org/wiki/feature:SisterWiki
Continue discussion here: ((Sister Wiki))

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

We could use list from:
http://doc.tiki.org/External+Wikis


Related:
[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:

{CODE()}
!my heading
{CODE}

Becomes:
{CODE()}
<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:

{CODE()}
!2009 Highlights
{CODE}

Tiki generates:
{CODE()}
<h1 id="2009_Highlights>my heading</h1>
{CODE}

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
{img} plugin does not work if image file name has special characters
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
MEbneter
Contributors
tracker item
Review all HTML5 tags and consider support for missing tags like ABBR and ACRONYM
http://www.w3schools.com/tags/tag_abbr.asp
http://www.w3schools.com/tags/tag_acronym.asp


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")}
{CODE()}{CODE}
/////
{FANCYTABLE()}{FANCYTABLE}
/////
{BOX()}{BOX}
/////{TABS}
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

Martin

Update--

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.

Thx

Martin
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
Need a way to detect when two wiki pages have the same alias (because the redirect fails)
Conflict detection when page is saved would be nice too. Often happens when people are translating pages.


It should offer disambiguation page...

For example http://dev.tiki.org/Download gives an error but it does contain
{CODE()} (alias(Download)) {CODE}
As you can see here:
http://dev.tiki.org/tiki-pagehistory.php?page=Get+code&source=0

So the page is not found, but when you try to create, you get:
{img fileId="562"}

So clearly it exists...
tracker item
WYSIWYG doesn't save the new content in wiki pages
Editing a simple wiki page, converted into wysiwyg, added new content, saved page, and nothing of the new content is saved (old content is shown at save time and when visiting the page again)
tracker item
NP NoParse mark-up being dropped from source when subsequently editing
For example, if I include the following line in a wiki page
{CODE(wrap=1)}__~np~{toc maxdepth=4 shownum="1" structId="1" pagename="Test_003a"}~/np~__{CODE}
it is successfully saved and then rendered correctly.

If I view the source it is correctly held.

When I then came to edit the same page and view the SOURCE whilst within edit mode the non parse mark-up has disappeared.

Discovered whilst testing on http://demo.tiki.org/10x/ site
%%%
I have screen shots available if required.
%%% %%%
Please look at the source, since I'm struggling to get the code correctly shown here.%%% %%%The code plug-in closure follows the end of NP tag and end of bold mark-up, but that is not what is showing above.
%%%I see a similar issue with the CODE plugin on your documentation page at [http://doc.tiki.org/Wiki-Syntax+Text&structure=Tiki+User+Guide#noparse_-_not_parsing_WikiSyntax]
tracker item
Tiki exchange of document with others marked up languages and project management
For future versions 11 ? 12 ?

Hi,

There are several main marked up languages that we know well.

I think that it will be useful to be able to exchange (import, export) documents with other selected marked up languages.

!!I particularly think to two categories :

!!!1- The task and documents managers used by development tools : Eclipse-Mylin Aptana environment and Bugzilla

Remark :
About this category, I redact documents using textile to describe the developments integrated into projects and bugzilla.
This because I have near fifty elementary project developed since 4.0, stabilized at 8.3 and that I am preparing for 10.x. (They remain for most of them available and someones must be adapted - galleries particularly)

!!!2- The wikies
The problem is to exchange data with users of main wiki.

The need is to use the large capabilities of tikiwiki to hold projects management and documentation. But as it is not specialized it cannot be directly used.

!!There are several ways, this is completely opened :
1- Be compatible i/O with textile which is very closed from basic tiki marked up language. This for basic articles.
2- Develop a plugin using tikiwiki as marked up language for Mylin
3- Look farther with a full XSL XSL-Fo (note that with eclipse all marked up supported languages can be exported as XSL-

!!On the way, proposal
1- First : list of major marked up languages for wiki and task managers
2- Links import export existing from one to another
3- Choose the optimum
!!
Aim :
- Prepare use of tikiwiki in project management
- Be compatible with environments as Eclipse to with other project management tools

!!Reason(s)
- Tiki provides a lot of coherent and very useful tools to manage the content of projects (documents and detailed task management, studies) and groupware life and management which is the core of project management (the classical tools for planning are only in my mind a little part). __But it cannot be connected with specialized existing tools and information systems in various businesses. The problem and aim is to prune efficiently tikiwiki into these organizations.
__
Trebly
tracker item
colon in definition lists
When you are using definition list plugin, if you want to use a colon in the definition, there is no way to do this that I know of because the colon is used to separate the term from the definition. If you have a second colon on the line, the second colon and everything after it is cut off (not displayed).
tracker item
Ja lang wiki text broken (trunk)
Unless I'm missing some new admin change, Japanese wikitext support in trunk is broken. At both a 3.1 site upgraded to trunk, and a fresh install of trunk, Japanese text shows as either garbarge characters or question marks. (I know it's a long way until Tiki 4, but trunk is supposed to stay close to releasable.)
tracker item
koth
Contributors
tracker item
Last double quotes (") of a plugin is changed to right double quotation mark (R21) on Safari
tracker item
LDAP authentification sur LD
Hi All,

I’m working on the Tikiwiki 2.2 with a LDAP authentication.

In the login option, I see it is possible to automatically give someone access in the Tiki if this person is in LDAP directory.

My question is: Is it possible to define access with a Distribution List group and not with the entire LDAP directory?

On another note, do you know why “LDAP Member is DN” can not be set to “yes?”

Thanks for your response

tracker item
Level 7+ headings (beyond h6)
tracker item
Line Break (%%%) in tables
tracker item
Line breaks in wiki syntax for colors: regression or accidental feature?
Please see:
http://dev.tikiwiki.org/tiki-pagehistory.php?page=TikiTests&source=40

There is:
{CODE()}~~#FF0000:This is a great start! I think automated testing will be an important ingredient in the future, to keep TikiWiki stable.

That said, it seems to me that TikiTests still falls short of meeting many of my needs as a Test Driven Developer. I want to start ussing automated tests on Tiki ASAP, so let's figure out what's missing, and how to best support those needs.
~~{CODE}

This used to produce colored text. In a recent upgrade, it no longer does.

Is this a regression bug?
Or was this an accidental but never official feature?

Related:
{wish id=2496}
tracker item
Link syntax for pointing to pages on Wikipedia and other mainstream sites
I have started a blog using Tiki, where I talk about what I have learned over the years on Agile Software developement in a Research and Development context.

In the three weeks I have been doing this, I find myself pointing to Wikipedia pages over and over, whenever I need to refer to a specialized concept that my readers might not understand. The way I do it now is like this. Say I want to refer to the concept of Code Refactoring. Then I will write ~np~((code refactoring))~/np~. Then I will create a wiki page __code refactoring__, and put a redirect plugin on it, so that it forwards automatically to this page:

http://en.wikipedia.org/wiki/code_refactoring

Then, whenever I need to refer to code refactoring, I can just write ((code refactoring)).

It occurred to me that it might be useful to have a special wiki link syntax to make this easier. For example, I could write (wikipedia(code refactoring)), and this would be rendered as if I had typed: ~np~[http://en.wikipedia.org/wiki/code_refactoring|code refactoring]~/np~.

I can see other application of this concept for other well known sites that provide information about known entities. For example: (facebook(Marc Laport)) would point to this page:

http://en-gb.facebook.com/marc.laporte.name

tracker item
link_cache creates SQL error
From tiki-devel. This is a blocker in my view.

{QUOTE(replyto=)}>> A user added a link to a comment, and now any page that tries to show the link (e.g. the wiki page or the comments admin page) gives me a sql error. My code is up to date to about a week ago ‑ has this been spotted and fixed? A quick search didn't turn anything up for me.
>>
>>
> No, I can reproduce this on current trunk. Here's the stack trace:
>
>> * /var/www/tiki/trunk/tiki‑index.php : 0 ‑> {main}(array ( ))
>> * /var/www/tiki/trunk/tiki‑index.php : 427 ‑> runSetups(array ( ))
>> * /var/www/tiki/trunk/lib/wiki/renderlib.php : 89 ‑> setupPage(array ( ))
>> * /var/www/tiki/trunk/lib/wiki/renderlib.php : 310 ‑> get_parse(array
>> ( 'page' => '\'HomePage\'', 'canBeRefreshed' => 'FALSE', ))
>> * /var/www/tiki/trunk/lib/wiki/wikilib.php : 375 ‑> parse_data(array (
>> 'data' => '\'{BACKLINKS()}{BACKLINKS}\\r\\n((nouvel escape
>> test))\\r\\n((Home
>> ))\\r\\n{YOUTUBE(movie="http://www.youtube.com/watch?v=_wesmkqvUPI")}{YOUTUBE}\\r\\n!!{img
>> src=pics/icons/star.png alt="Star"} Get started.\\r\\nTo begin
>> configuring your site:\\r\\n{FANCYLIST()}\\r\\n1) Log in as the
>> __admin__ with password __admin__.\\r\\n2) Change the admin
>> password.\\r\\n3) Enable specific Tiki features.\\r\\n4) Configure the
>> features.\\r\\n{FANCYLIST}\\r\\n\\r\\n!!{img src=pics/icons/help.png
>> alt="Help"} Need help?\\r...\'', 'options' => 'array (\'is_html\' =>
>> \'0\')', ))
>> * /var/www/tiki/trunk/lib/tikilib.php : 6370 ‑> cache_links(array (
>> 'links' => 'array (0 => \'http://info.tikiwiki.org/Learn+More\', 1 =>
>> \'http://info.tikiwiki.org/Help+Others\', 2 =>
>> \'http://doc.tikiwiki.org\', 3 => \'http://www.tikiwiki.org/forums\',
>> 4 => \'http://info.tikiwiki.org/Join+the+community\')', ))
>> * /var/www/tiki/trunk/lib/tikilib.php : 3505 ‑> cache_url(array (
>> 'url' => '\'http://info.tikiwiki.org/Learn+More\'', 'data' => '', ))
>> * /var/www/tiki/trunk/lib/tikilib.php : 3739 ‑> queryError(array (
>> 'query' => '\'insert into `tiki_link_cache`(`url`,`data`,`refresh`)
>> values(?,?,?)\'', 'error' => 'NULL', 'values' => 'array (0 =>
>> \'http://info.tikiwiki.org/Learn+More\', 1 =>
>> \'\\n\\n\\n\\t\\n\\n\\n\\t\\t\\n\\t\\t\\n\\t\\t\\n\\n\\t\\n\\n\\n\\t\\t\\n\\t\\t\\n\\t\\t
>>
>
> cache_url unconditionally calls queryError(). I don't know what
> queryError() is supposed to do (and certainly didn't hope to find this
> documented), but the following code from Bridge.php is odd:
>
> function query( $query = null, $values = null, $numrows = ‑1,
> $offset = ‑1, $reporterrors = true ) // {{{
> {
> return self::get()‑>query( $query, $values, $numrows, $offset,
> $reporterrors );
> } // }}}
>
> function queryError( $query, &$error, $values = null, $numrows = ‑1,
> $offset = ‑1 ) // {{{
> {
> return self::get()‑>query( $query, $error, $values, $numrows,
> $offset );
> } // }}}
>
> Calling self::get()‑>query() with in turn $values or $error as second
> argument is strange. I figure queryError is probably meant to call
> self::get()‑>queryError() instead.
>
> This code was introduced in r20205.
>
{QUOTE}
tracker item
Linking to a shared or local drive or directory
tracker item
Links in definitionlist
In Tiki 3.5 when you want to link to a page with ~np~((somepagename))~/np~ within the __;__-Part of a definition list, the definition gets formatted as the question.

;help ((fixing)) this: defintion
tracker item
Links pointing to nowhere
When the Wiki feature is disabled, some links are created pointing to nowhere.

Example:
http://www.vic-fontaine.com/forum/tiki-view_forum_thread.php?comments_parentId=13&topics_sort_mode=lastPost_desc&forumId=1

First link points to:
http://www.vic-fontaine.com/forum/tiki-index.php?page=Fw: LOVE WORDING WALLPAPERS

"This feature is disabled: feature_wiki"

Similar in articles:
http://www.vic-fontaine.com/forum/tiki-read_article.php?articleId=1

A link to is automatically created for the key word TikiWiki:

http://www.vic-fontaine.com/forum/tiki-editpage.php?page=TikiWiki


Test user/password: smarty
tracker item
LIST Filter by distance command not working
tracker item
Wiki syntax: Lists inside (larger) paragraphs are rendered as outside
tracker item
login to tv.tiki.org broken (issue with PluginSlider?)
tracker item
LTS Regression: images not shown if align=center as param (reproduced in doc.t.o)
tracker item
Hotwords and WikiWords are parsed to links in Table of Contents (maketoc) entries, breaking HTML
When including a maketoc into a page, the titles in the page are still parsed for WikiWords and Hotwords. This breaks HTML, links, and may decrease the readability of page TOC-s.
tracker item
maketoc duplicates TOC headings when using "all languages" feature
tracker item
maketoc needs backlinks from headings to TOC, heading formatting options, outline numbering, etc.
A small collection of related issues with maketoc:

^{maketoc} -=Maketoc issues=-^
!!! ''TOC and heading type sizes''
* This is an issue that seems to crop up repeatedly on tw.o. Users would like to be able to easily control type size of both the TOC itself and headings created by maketoc. Type size for both seems to be theme-dependent now, with many themes using very large type size for headings, some with a type size for TOC entries that is too small for users with only slight vision loss. It would be a Good Thing if TOC and heading type sizes could easily be set globally, per object type, and by category, with switches available to vary those settings on a per page or object basis.
!!! TOC and heading character attributes
* It would help reduce inconsisistencies in TOC and heading character attributes (as in this tracker item) if the attributes could be set globally, per object type, and by category, with TOC switches available to vary those settings on a per page or object basis. However, the ability to manipulate emphasis within a single TOC/heading entry should be retained, so that for example, a single word could be italicized in a TOC/heading entry.
!!! Vertical linespacing between headings and text
* Under some themes, vertical linespacing between text and headings is too much for taste, or as in the theme affecting this tracker item, too small for taste. This is another setting that should be unleashed from the themes and made easily selectable by a Tiki admin through global, category, and object type settings, with switches for per page or object variation.
!!! ''Backlinks from headings.''
* Links from the TOC to headings are now 1-way. For larger pages, maketoc would be much more user friendly for those viewing pages if clicking on a heading would take you back to the TOC.
!!! Outline numbering.
* TOC formatting and heading formatting would be friendlier to the eye if both could be assigned numbering schemes such as 1., 1.1, 1.1.1, 1.2 or I., A., 1., a., II, etc. Settings might be implemented as described for ''TOC and heading formatting.'' If developed, this might be implemented for lists as well.
!!! Headings indentation.
* Many power users in the word processing and outliners worlds expect headings to inherit the indentations of the corresponding TOC entry. This would help break up the visual clutter that happens when many headings are close together vertically as a result of short text elements separating them, as in this tracker item (but it is far worse when there are subtopics and corresponding subheadings). Settings might be implemented as described for ''TOC and heading formatting.''
!!! Text indentation
* Many people used to word processors' outlining or stand-alone outliners expect text to be left-indented one tab more than its heading. Relevant settings might be implemented as described for ''TOC and heading formatting.''
!!! Associated features
* Display current settings in editor, change current settings from editor. Make changes to settings made from the editor apply only to the object being edited, so that users do not accidentally apply per object settings to other objects. Admins should have option to disable deviations from admin-set settings.
* maketoc is commonly used in conjunction with list features. Any changes to maketoc should not unintentionally impact the list feature and ''vice versa.''
* Need to ensure that all enhancements suggested render correctly when Tiki objects are exported as PDF.
!!! Future options
* Future options might be kept open by maintaining compatability between Tiki objects containing maketoc elements and various formats used by outliners such as OPML, XOXO, OML, or OpenDocument XML. (See corresponding Wikipedia articles.) E.g., it might be feasible at some point to directly export an outline file to Tiki where it is imported as a wiki or blog page and ''vice versa.''
tracker item
maketoc generates "super Table of Contents" with too many headings in Multiprint
__The message below was edited.__ {sign user="Chealer9" datetime="2018-06-08T15:57:21+00:00"}

We are running into an issue of maketoc appending onto itself if more than one maketoc appear per page. for starters, our server is TikiWiki 3.2, Windows Server 2003, apache 2.2.13, mysql 5.1.39, php 5.3.0, Multiwiki setup.

We are seeing this in ((doc:Multiprint)). What I am seeing is that if I have Tikipage A with a ~np~{maketoc}~/np~ at the VERY top and headings 1, 2, 3 and Tikipage B with a ~np~{maketoc}~/np~ at the VERY top and headings 4, 5. When I Multiprint using the Pages selector (both Tikipage A and B) there will be 2 TOCs displayed in the resulting print page. The first TOC will show 1,2,3 and further down the page will be 1,2,3,4,5 (when I expected only 4,5). We are trying to Mulitprint hundreds of pages (and most have their own maketoc) so the very last TOC takes up 15 pages itself (after accumulating TOCS over 100s of wiki pages). Big problem for us as our nurses need to have a hardcopy/offline copy on hand in case our systems go down.



So it is the parsing of the maketoc that is causing the appending of subsequent TOCs. I found a bug by "larryg" where he tries to fix a similar issue (cf {wish id=2781} and [http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=2&comments_parentId=34791]) but his fix did not work for me. I think that he is on the right track. Does anyone know of a fix? Has anyone experienced this? Is it fixed in 4.x?

Thanks in advance,

Tim
tracker item
Managing XML in TikiWiki for re-use by external apps
XML files are cool for data interchange.

For example, you can create an xml file to feed a Flash animation. However, you still need to update that XML file via FTP. What if you could edit a wiki page (with permissions, history, etc) and have the Flash animation get the data from it as if it was xml?

Or maybe a button on a wiki page "save to .xml", which would save on the filesystem WikiPageName.xml? (where the Flash would know to look for it)

Related idea:
* {wish id=467}
* {wish id=3103}


Louis-Philippe Huberdeau --will look into-- used [http://www.yaml.org/|YAML] --to see if this could be useful-- and it is very useful for the ((Profile Manager))
tracker item
Markdown plugin does not parse quoted text properly
tracker item
Markup not parsed when switching from normal (wiki) to wysiwyg (html) editors
When switching a "wiki" format page to the wysiwyg editor, wiki markup not converted into HTML.
Likewise switching an HTML page to the normal editor, HTML markup not converted to wiki.

tracker item
MediaWiki import script
For many people, Wikipedia (powered by MediaWiki) was their first contact with wikis. MediaWiki has a very nice interface and has done an amazing job to get Wikis known to the public, via Wikipedia. MediaWiki/Wikipedia is probably the best thing that happened to the Wiki world since Ward Cunningham invented the wiki in 1995.

MediaWiki is excellent to make an encyclopedia. However, it is not designed to be an Intranet/corporate wiki with an advanced permission system. Also, MediaWiki is "only" a wiki. It doesn't have extra features like forums, trackers, blogs, etc. Maybe these features will eventually be added to Mediawiki, but it doesn't seem imminent.

Users which want more can use some glueware to combine a Wiki and an existing full featured CMS (ex.: Drupal + MediaWiki or Xoops + MediaWiki) or they can choose Tiki Wiki/CMS/Groupware.

There are apparently millions of MediaWiki installs. In contrast, there are "only" tens of thousands installs of TikiWiki. While this number is very good, we can expect more & more people will want to migrate from MediaWiki to TikiWiki. Even if a small proportion of MediaWiki installs migrated to Tiki, it would still be a very large influx of users.

Tiki can already look like WikiPedia:
http://themes.tikiwiki.org/Tikipedia

One important step for Tiki's future is to have a converter from MediaWiki to TikiWiki so users can have a painless upgrade path and gain access to more features.

http://dev.tikiwiki.org/MediaWiki+to+TikiWiki+converter

Related:
*[wish1531|Wiki markup for icons]
*[wish1805|Universal Wiki Edit Button]
*[wish2102|Support some of the MediaWiki syntax that doesn't conflict with TikiWiki syntax]
*[wish1191|Wiki editing: Preview with diff, like Mediawiki]
*[wish1843|Infoboxes like MediaWiki/Wikipedia, but making use of trackers to be future-proof]
*[wish1781|Support for the Wiki creole markup (syntax)]
tracker item
Minify JavaScript causes JS errors (e.g. Clicking on edit toolbar buttons reloads page)
When editing a wiki page, clicking on any of the toolbar icons:

{img id=102}

causes page to refresh.

Tested with FireFox 3.5 (linux) and IE 6.

If the page is edited using the edit icon (which loads the editor using Ajax), then the feature does work.

This feature works on previous version of tiki (3.x) with the same browsers.

Tiki cache was ceared. No difference.
tracker item
Misterious error that appear during translation edition
I started today collaborating with translation into Portuguese language.
My first edition the page [http://doc.tikiwiki.org/tiki-editpage.php?page=Usando%20Páginas%20Wiki|Using Wiki Page (pt)]

the moment I clicked SAVE, I got an error page.
I created a PDF document from it.
As this is my first Bug report I hope I will be able to send the PDF attached to this Bug Report.
tracker item
Monospaced text not correctly formatted
Issue was described here:
[http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=31233&topics_sort_mode=lastPost_desc&forumId=4]

When you insert text like:

"You should call ~np~-+intValue()+-~/np~ in ...." then that comes out as:
"You should callintValue() in ...." with "intValue()" monospaced. Note the missing space.

This is caused by the regular expression used to replace the Wiki Syntax with HTML.

The bug is in tikilib.php, line 6467.
It reads:

// Replace monospaced text
$line = preg_replace("/(^|\s)-\+(.*?)\+-/", "< code >$2< /code >", $line);

The first group captures the whitespace. But only the second capturing group is saved.
tracker item
multibyte-letter-wiki-document-name between double braces are not recognized.
tikiwiki syntax for 'wiki-link' only works when doc-name is consists of alphabet.

just to avoid wiki syntax works on this bug report field,
currently using as follows :
DOUBLE BRACE OPEN 'WIKI_DOC_NAME' DOUBLE BRACE CLOSE
--> make hyperlink for 'WIKI_DOC_NAME'

DOUBLE BRACE OPEN 'ASIAN_CHAR_WIKI_DOC_NAME' DOUBLE BRACE CLOSE
--> parse 'ASIAN_CHAR_WIKI_DOC_NAME' as normal texts. then just print the texts.

please fix this problem soon. thanks in advance.
tracker item
Multimedia Flash unusable due to XSS protection
The "Multimedia" feature requires a "ur‍l" parameter, which is damaged to ~np~url~/np~ by XSS protection. TikiWiki has no way to play MP3 files (XSPF mod seems nonfunctional in 2.1).

~np~{FLASH(movie=>"tikimovies/multiplayer.swf?url=http://yoururl/file.mp3&MODE=AUDIO")}{FLASH}~/np~

tracker item
Multiple code plugins on a single WYSIWYG page not correctly parsed
tracker item
multiple color tags doesn't work in one line
If you put two (and possible more) color tags in one line (maybe to mark one word in red and the other one in blue) it doesn't work.

Example:
~~#FF0000:text~~ text ~~#FF0000:text~~

~~#FF0000:text~~ text ~~#0000FF:text~~

~~red:text~~ text ~~#FF0000:text~~

~~#FF0000:text~~ text ~~blue:text~~

~~red:text~~ text ~~blue:text~~

would produce:
text~~ text ~~#FF0000:text

text~~ text ~~#0000FF:text

text~~ text ~~#FF0000:text

text~~ text ~~blue:text

text~~ text ~~blue:text

in all red letters


an example can be found here:
http://doc.tikiwiki.org/tiki-index.php?page=UserPageDesertWolf
tracker item
Multiple header with same text causes maketoc type header links to fail
When there are multiple headers of the same text, for example:

!!!!Windows Media Player

stuff about WMP

!!!!!Platform availability

WMP is available in these platforms....

!!!!Adobe Reader

stuff about WMP

!!!!!Platform availability

Adobe Reader is available in these platforms....

The links by maketoc all point to the first instance of Platform availability. This is not correct.

{maketoc}
tracker item
Multiple IE fixes for tiki-js.js and tiki-jquery.js TikiWiki V4.2
Multiple problems exist with TikiWiki tiki-js.js and tiki-jquery.js scripts in relation to editing wiki pages with the Wiki editor. The problems vary by IE version:

* IE requires the 'label' property to be set in 'Option' objects
* IE editing requires use of textRanges
tracker item
natokpe
tracker item
Argument Variables are parsed even in "No parse" (np) zones
tracker item
nofollow on hyperlinks
Please see:
http://www.wikimatrix.org/wiki/feature:nofollow
http://googleblog.blogspot.com/2005/01/preventing-comment-spam.html
tracker item
Non-Breaking Space Character in Headers
tracker item
non-parsed tiki syntax is ignored
tracker item
Number in First numbered header in 2nd level lost in wiki pages with no header of first level
tracker item
on multi-page Wiki Pages {maketoc} does not link to the right page
Hi, I know ''maketoc'' is said not to like other ''maketoc''s on a wiki page but it obviosly does not work correct (on my REV 24736) if inserted on another page than the first one. If inserted on e.g. the third page all links to headlines of the firstpage carry "pagenum=3" in the link instead of no pagenum or "pagenum=1".

{CODE(caption="Example")}
!# first page
!! test
test test test
!! test
test test test
...page...
!# second page
!! test
test test test
!! test
test test test
...page...
{maketoc}
!# third page
!! test
test test test
!! test
test test test
...page...
!# fourth page
!! test
test test test
!! test
test test test
{CODE}

My initial intention was to put a ''maketoc'' at every end of a subpage to be able to navigate back. BTW: on my REV 24736 multiple ''maketoc''s do not cause any additional problem.
tracker item
one-letter wiki page links broken
creating an in-wiki link like {CODE()}((M)){CODE} does not work, it is displayed as {CODE()}((M)){CODE}
tracker item
Only red color appear when editing wikis from Foreground Color icon
Hi,
Only red color appear when editing wikis from Foreground Color icon. Wihtout any pallete of color.

Anyones know why?

working version tikiwiki 3.1

Thank in advance
tracker item
Opening external links in Colorbox does not work anymore
tracker item
Optional disabling on javascript stripping protection
Tiki, be default, strips all javascript from all text box entries. This is meant as a security protection.

While most of the time, this is a good thing, sometimes, it is appropriate to use this javascript. For example, an add placed in a dynamic content module.

tracker item
output of {maketoc} in a DIV to make it easy to apply a style
the output of {maketoc} in Wiki is not contained in a special
DIV so one can not define a style for displaying it for example in a box or ...
tracker item
Page Alias doesn't seem to work.
tracker item
Page alias doesn't work on nextdoc.t.o (12.x) nor doc.t.o (11.x)
tracker item
Page alias links replaced by simple wiki links when "wiki wysiwyg" is on
tracker item
Page break syntax ...page... no longer working in Tiki 11
tracker item
Page break syntax with collapsible sections breaks site layout
tracker item
Page Break will not work
tracker item
Page description breaks links on other pages
I discovered a problem where one of our users had created a page containing the words SeaMonkey in the description. When she later tried to link to this page with the syntax ((PageName|This is the link text)), the link broke, and tried to embed a link to create a new page titled SeaMonkey among other things. The cause of the problem, was that the description of the page she linked to, was inserted as the title of the <a>-tag.
tracker item
pagenames with dashes and spaces clash with -+ monospace syntax parsing
Page name like
{CODE()}
((Unix Install - Information))
gets parsed with the <code> in it
{CODE}
Changing order of parsing may not be best solution at this stage. changing urlencode to rawurlencode may also not be ideal. Need elegant solution.
tracker item
Pagination doesn't work on 11.x
tracker item
Paragraphs in Wiki HTML Sometimes Fail to Render
tracker item
Parser regression on -> between 6 and 9, and still present in 10 and 11
tracker item
Parsing issues in wiki HTML pages
#The ~np~[[~/np~ syntax acts just like ~np~[~/np~ on wiki pages with HTML enabled
#The HTML character entity &lt; is treated just like < on wiki pages with HTML enabled if not followed by a space
tracker item
Parsing of external links
URLs in external links in the form of

{img src=images/code.png}%%% {CODE()} [url|description] {CODE}

are completely parsed. This causes problems (HTML error 404 = site not found) if the URL contains character sequences which are part of the Wiki syntax. Using

{img src=images/code.png}%%% {CODE()}
~np~
{CODE}

doesn't work for parts of the URL as a space is added. The only workaround is to use

{img src=images/code.png}%%% {CODE()}
~np~
{CODE}

for the whole URL. This results in a behaviour which is not in line with the Wiki setting saying that external links should be opened in a new window.

Two examples are http://www.consumerfocus.org.uk/en/content/cms/Energy_Help___Advice/Energy_Supplier_Pric/Energy_Supplier_Pric.aspx and http://www.deutsche-rentenversicherung.de/nn_23882/SharedDocs/de/Navigation/Rente/Ausland__Rente__node.html
tracker item
Parsing of special character wiki syntax in PluginHTML seems broken
tracker item
period (.) in page names conflicts with Short URLs rewrite rules
A new short URLs / Search Engine Friendly / Rewrite Rule with .htaccess was added to Tiki 2.0 as experimental (great!)

However, this causes issues with pages like:

http://tikiwiki.org/Custom+email+message+to+new+tikiwiki.org+registrants
http://tikiwiki.org/TikiWikiRelease1.6


Related:
[wish2108|Equivalent characters for page linking, backlinking, searching, etc (ex.: space, underscore, period)]
tracker item
php errors aftert upgrade to tiki15: mb_strlen() and trim() expect parameter 1 to be string, array given
tracker item
Plugin editing should be disable when looking at history
tracker item
Plugin Fancytable content not parsed when using Markdown
tracker item
Plugin inline editing is saved but modal stays open
tracker item
plugin rcontent causes WSOD
placing {rcontent id=1} into an assigned module causes WSOD.

this was a big problem for me on upgrade, because I had rcontent in my 2.x installation, upgrade to 3.1 gave me WSOD. Lack of access (because of WSOD) made fixing the problem much more difficult for me, as an end-user.

According to luciash in chat:
seems conflict between plugin {RCONTENT() /} and {rcontent} wiki syntax to me, because recently the syntax was made more universal and plugins can be called using lowercase {pluginname} syntax too




note, sorry if this posts twice...
tracker item
plugin rcontent causes WSOD
note, I posted this twice before, but with the problem code in the post,

http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=2797

http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=2799

and both of those now show the WSOD that I saw. So again, here we go, this time I won't post the code as I used it, as it appears to be causing the same problem on those tracker pages. So...

using rcontent in a module causes a WSOD in 3.x

according to luciash in chat:

seems conflict between plugin RCONTENT and rcontent wiki syntax to me, because recently the syntax was made more universal and plugins can be called using lowercase {pluginname} syntax too
tracker item
Plugin SPLIT is broken on Tiki13
tracker item
Plugin WantedPages reports alias
You can see here: ((WantedPages))

Some wanted pages have links to the alias.
tracker item
PluginMatcher.php Times Out
tracker item
PluginQuote "eats" text when used along with Markdown plugin
tracker item
Plural WikiWords when using ((WikiWord))
Plural WikiWords seem to work fine for CamelCase words.

We would need it to work when we use ((

And backlinks should work as well. We will DogFood on doc.tikiwiki.org instead of all those page redirects (which are OK, but not the best))

Related:
[wish1489|Wiki page name Alias]
[wish1119|Better handling of page renaming]
[wish1610|Redirect plugin : should permit to set status "Moved Permanently"]
tracker item
Preview mode not parsing wiki syntax correctly
I was writing up a document that contains the following

-+/MSS/<CustomerID_from_Remedy>/<External_Device_IP>+-

When you hit the preview button, it shows up as "/MSS//" but if you save the page, it shows up exactly as it should
tracker item
Preview Oddities
The Ajax preview has some minor HTML rendering weirdness, like this one...

No line breaks: http://dev.tiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=3740

If you use HTML special characters (like &mdash;), particularly with the wiki-style editor, it will appear OK in the preview but as plain-text on the actual page. As a workaround, I'm inserting the characters themselves, which is not great web practice but works.

There are probably others that don't come to mind presently but will add as I think of or come across them again.
tracker item
Quicktags simplebox assign from single caret to double to allow for more elements inside
The tiki normal editor has a problem when a page uses multiple carat elements. It creates unwanted boxes. i.e ~np~10^¹¹~/np~ used twice would create a malformed simplebox breaking the natural math operators into unreadable divisions.

The {img src=images/code.png}%%% {CODE()} ~np~ … ~/np~ {CODE} is not a workaround as this creates an unwanted space after the carat and before the next character. It is also awkward. It also does not allow the natural use of an otherwise perfectly suited math symbol.




tracker item
Replace Emoticons with Emoji
tracker item
rtl in codemirror 3.16: scrollbar on the right should disappear
tracker item
Saving in WYSIWIG removes Edit Section buttons; saving in Wiki restores them; Wiki edit option disappears when doing a section edit
If you save a page in WYSIWYG, Edit Section buttons disappear. (However, if just before saving, you Switch Editor to wiki, the Edit Section buttons will (re-)appear (:wink:))

Note also separate bug #3764, i.e. the Switch Editor button does not appear if your edit is invoked by a Edit Section button. This makes the first bug very discouraging for new contributors.

This bug is a big issue for sites wishing to encourage collaborative editing, especially with longer pages:
*Having Edit Section buttons at each heading cries out 'Edit me! Edit me!'. If they disappear, it is much scarier for a beginner to edit a page.
*If someone bravely uses an Edit Section button only to find that it has disappeared as a result of their work, they may think they no longer have edit rights. They will think the site is stupid, and be greatly discouraged re further editing.
tracker item
Search displays markup code in resultss
Currently search displays markup code in results... Could there be an option to filter out parsed code? Code between ~np~ and ~pp~ tags however, is part of the desired search content (but should still remain unparsed).

Thank you,

OC
---
also:
http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=66&topics_sort_mode=lastPost_desc&forumId=4&comments_parentId=21785
tracker item
maketoc adds bogus content to search index, causing false positives
hi

following problem:

i don't know if it was during an upgrade or if it was already there before upgrading to 3.6 but somehow one of our tikis indexes words which aren't on the pages.

e.g. lichtschnittgerät (as one example) - should be only in one page but after you search it is listed in several tens maybe hundreds of pages.

the text in the resultlist show several other words which shouldn't be there (and are always the same)

i trieds refreshing the searchindex, deleting the tiki_searchindex table and redoing the searchindex all with no luck (lichtschnittgerät is listed there as lichtschnittgerät but thats some kind of code issue i guess)

Edit:
~np~So far i narrowed the problem down to the {maketoc}-Plugin:

on refresh-functions.php on line 175 I added:
if (substr($id,0,3) == "KT0") { // Just get me one of the pagegroups I know where the fault is
echo $id;
insert_index(search_index($content), $index_type, $id);
}

and on top pf the function &search_index I entered this
echo '<pre>'.$data.'</pre><hr>';
just to be able to see what data he gets - and at the place where {maketoc} is in the sourcecode of the page, a whole list of words appear instead of the table of contents (or nothing or whatever it should print out) of the particular page~/np~
tracker item
Search problems when the result has multiple pages.
When you search for a word, if the word found is in a multiple pages context, like on the page "Formatting Standards" on the site doc.tw.o the result will show you
the first page. But the word you were looking for might be on page six, so you need to go from page to page with the little arrows in order to find the right page. This could be a problem if you have more then 8 pages like in the Formatting Standards. It should find the appropriate page directly.
tracker item
Section Edit, to edit part of a wiki page
Long overdue feature in TikiWiki:

http://en.wikipedia.org/wiki/Help:Section#Section_editing

[http://sourceforge.net/mailarchive/message.php?msg_name=435AF64C.1050106%40marclaporte.com|2005-10 discussion on the developer's mailing list.]

If "edit by section"=Y as a wiki feature, all H2 should create a bookmark and a section that can be edited individually. As an option, all heading levels could become sections.

Section edit should be optional and there should be a syntax to override (either way)

More explanation from our friends at WikiMatrix:
http://www.wikimatrix.org/wiki/feature:section_editing
tracker item
Section edit fails and loses page content
This is on trunk Revision: 37484 and still in current trunk (Révision : 37823)

I have a rather long wiki page.

When I use section edition (any section), saving gives a blank screen.

Then I go back to the page and the whole page is replaced by one single line like:
the text "PK" followed by hex "0003 0004 0014 0008"

Then it is necessary to rollback the page from the version before the section edit.

Additional info:
It does not happen on short pages. I have not been able to find time to reduce the offending page to a demo case :-(
The error logs say there is a PHP memory exhaustion but when i upgrade my memory from 128M to 256M, it exhausts just the same :
^{CODE(caption="error log",wrap="1")}
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4096 bytes) in /www/mywebsite/htdocs/lib/diff/Diff.php on line 460, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP Stack trace:, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 1. {main}() mypath/htdocs/tiki-editpage.php:0, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 2. TikiLib->update_page() mypath/htdocs/tiki-editpage.php:994, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 3. diff2() mypath/htdocs/lib/tikilib.php:4230, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 4. Tiki_Text_Diff_Renderer->render() mypath/htdocs/lib/diff/difflib.php:134, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 5. Text_Diff_Renderer->_block() mypath/htdocs/lib/diff/difflib.php:80, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 6. Text_Diff_Renderer_unified->_changed() mypath/htdocs/lib/diff/Renderer.php:126, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 7. diffChar() mypath/htdocs/lib/diff/renderer_unified.php:64, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 8. Text_Diff->Text_Diff() mypath/htdocs/lib/diff/difflib.php:152, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 9. Text_Diff_Engine_native->diff() mypath/htdocs/lib/diff/Diff.php:44, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 10. Text_Diff_Engine_native->_compareseq() mypath/htdocs/lib/diff/Diff.php:379, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1
[Sun Oct 02 19:45:48 2011] [warn] [client xx.xx.xx.xx] mod_fcgid: stderr: PHP 11. Text_Diff_Engine_native->_diag() mypath/htdocs/lib/diff/Diff.php:586, referer: http://mywebsite/tiki-editpage.php?page=test+section+edition+1&hdr=1{CODE}
^
tracker item
Section edit: one too many buttons when there is no content before 1st section
{img src="show_image.php?id=94" }
tracker item
Setting cell color font does not work for two cells in the same row
The above code does not work on 3.x and work perfectly on 2.x:

||with color|~~#FF0000:with color~~|~~#FF0000:with color~~
without color|without color|without color||

See print screen of the problem attached

Probably there has been some change in the parser in the new version that caused this.

This bug may be related with those other bugs:

*{wish id=2496}
*{wish id=2492}
*{wish id=2720}
tracker item
Several flash plugin issues in TW 3.0
I am having problems using the flash plugin in TW3, that a TW2.4 site test that I have does not have.

1 - First of all the flash module code has to be re-written for it to work at all.
from:
{CODE()}{FLASH(movie="http://www.youtube.com/watch?v=JeqdtbYz_M4")}{FLASH}{CODE}
to:
{CODE()}{FLASH(movie="http://www.youtube.com/watch/v/JeqdtbYz_M4")}{FLASH}{CODE}
Can the edit window button be modified to insert the correct code?

2 - 'Flash player not available' appears in slides of wiki pages although wiki pages themselves work fine.

3 - In calendar, list view shows flash movie but the preview doesnt - gives the error message 'Flash player not available'. Any tips or directions to solve these problems??
tracker item
Signature and/or datestamp and/or approval-vote and/or comment plugin/syntax
Seen on IRC:
{img src=images/code.png}%%% {CODE(wrap=>1)}
(10:33:47 AM) ***dthacker also wonders if there is a login-timestamp wiki syntax such as mediawiki's ~~~~ that would auto sign with user id and date/time.
{CODE}


Wiki pages are great to produce Neutral Point of View (NPOV) content. If we need to know who added what, we check the edit history.

For debates, discussions, opinions, etc, people will often use Tiki blogs, Tiki forums or comments at the bottom of wiki pages. These are more natural formats and it's clear who thinks what and who said what. Comments & forum threading make it clear who is responding to who/what.

However, in some cases, it is useful to have this type of interaction in wiki pages. The [http://doc.tikiwiki.org/Editorial+Board|TikiWiki documentation Editorial board] has monthly meetings to discuss and make decisions. Members can edit, comment and vote on motions.

The way people add their comments is not standard and if we are not careful, it can get messy. This often happens in wikis.

Some wikis use a special syntax for "signature". This would be a way to associate the name of the user and maybe the date to a specific comment. It would be nice to clearly and visually associate the user to the comment. Maybe the comment & signature are in a same box?

It would be nice also for people to be able to express support to an idea in the wiki page, with a thumbs up (+1) or a thumbs down (-1). Right now, the wiki ratings feature let's us vote only once per wiki page.

These syntaxes should be quicktags to it's easy to add. Maybe some of the less important meta data (ex.: date of comment) would be only visible on mouse-over. (and thus not in printed mode). The mouse over could also contain a link to the user's personal wiki page and some data about the user (his avatar, score, etc).


Ex.:
*click my PluginComment tool (in toolbar)
*Pre-fill text that will be mouse-overed with previously selected text
**add date & signature (with link to userpage)


Everyone: please share your ideas on this and how you have seen it implemented elsewhere.

Thanks!


Related:
{wish id=2102}
tracker item
Smarter detecting of domains and auto-links
www.mozilla.com is automatically turned into a link. (great)

but support.mozilla.com is not.

So I must do:

{img src=images/code.png}%%% {CODE()}
[http://support.mozilla.com|support.mozilla.com]
{CODE}

If automatic detection of support.mozilla.com is too risky, maybe the following:
{img src=images/code.png}%%% {CODE()}
[support.mozilla.com]
{CODE}

should be smart enough to know that I meant:
http://support.mozilla.com

and not:
http://dev.tikiwiki.org/support.mozilla.com
tracker item
Some bash scripts in the {CODE} syntax stops pages rendering
After adding the following to wiki pages it stops them rendering.


{CODE(caption=>~np~ bash ~/np~)}

LOCATION=smb://server/directory/
IFS=$'\n'
for SONGS in $(find -type f |grep .mp3 | awk 'sub("./","") {print $0}';find -type f |grep .wmv | awk 'sub("./","") {print $0}'; find -type f |grep .ogg | awk 'sub("./","") {print $0}')
do
echo $LOCATION$SONGS
done
{CODE}
tracker item
Display of collapsible sections ("+"/"-" headers) in FADE zones broken
tracker item
Some wiki syntax crashes page, with error message: Not unique table/alias: 'ts'
tracker item
Sorting Alpha not working at Tiki.org page
tracker item
special characters break wiki links
creating links, ending with special characters like {CODE()}((osc~)){CODE} does not work, it is displayed as {CODE()}((osc~)){CODE}
tracker item
Special characters in Wiki page titles break the doubled-parentheses type of link
There are many common non-alphanumeric characters that, when part of the title of a wiki page, break the ability to link to that page using the ~np~((Name of page))~/np~ method.

Characters which cause this type of linking to break include: comma (,), apostrophe ('), hyphen (-), question mark (?), asterisk (*), and percent sign (%).

The consequence is (a) you're extremely limited in what characters you can include in titles or (b) you have to link to a page by its URL. (b) is very limiting, because when a page is renamed, all the links to it will break.

Test with this:
~np~
((test,test))

((test's test))

((test-test, hyphen))

((test? question mark))

((test*test asterisk))

((100% correct))

((this should work with no problems))

((test_underscore))
~/np~

You'll see:
~np~
((test,test))

((test's test))

((test-test, hyphen))

((test? question mark))

((test*test asterisk))

((100% correct))

this should work with no problems?

test_underscore?
~/np~
In other words, all but the last two page names ("this should work with no problems" and "test_underscore") were ''not'' treated correctly as being links to web pages.
tracker item
Special Characters with tilde ~ don't seem to work
Wiki Syntax for special characters seems to fail in 1.10 (I can get it in WYSIWYG). Thus, ~np~~169~~/np~ no longer shows the copyright symbol.

The problem appears to lie in TikiLib - parse_data
if (!$simple_wiki and $prefs['feature_wysiwyg'] == 'n') {
$this->parse_htmlchar($data);

Here's this issue - I have WYSIWYG set to Y, but NOT showing by default. It seems that the test should be whether WYSIWYG is actually showing - I have no idea what the variable is.
tracker item
split-plugin doesn´t work correctly
Using the split-plugin in cooperation with the sort-plugin would run in some trouble.

In tiki5 the combination of this:

{CODE()}

{SPLIT()}

-=A=-
{SORT(sort->asc)}
((AC))
((AG))
((AA))
{SORT}

---

-=B=-
{SORT(sort->asc)}
((BB))
((BA))
{SORT}

---

-=C=-
{SORT(sort->asc)}
((CX))
((CD))
{SORT}

{SPLIT}
{CODE}


will work fine. You will get three columns and every entry is sorted and seperated fine.

After tiki5 this code-creation doesn´t work any more, the entry´s wouldn´t seperate by CR , only by SPACE. Anything is in one row.


This appears to be a basic parser problem in the way nested plugins are parsed. Same issue affects the FANCYTABLE plugin - see [http://dev.tiki.org/item4216]
tracker item
Strikethrough syntax, and avoid collision --strike-- -- no strike--
{img src=images/code.png}%%% {CODE(caption=current strikethrough syntax)}
{TAG(tag=>strike)}texte{TAG}
{CODE}

Suggested one for us:
--strike--

As suggested in wikicreole:
http://www.wikicreole.org/wiki/Strike

All wiki engines:
http://www.wikimatrix.org/syntax.php?i=27

This is very useful when using wiki pages for ((project management))
tracker item
Strikethrough syntax, and avoid collision --strike-- -- no strike--
{img src=images/code.png}%%% {CODE(caption=current strikethrough syntax)}
{TAG(tag=>strike)}texte{TAG}
{CODE}

Suggested one for us:
--strike--

As suggested in wikicreole:
http://www.wikicreole.org/wiki/Strike

All wiki engines:
http://www.wikimatrix.org/syntax.php?i=27

This is very useful when using wiki pages for ((project management))
tracker item
Support for hashtags
tracker item
Support for the Wiki creole markup (syntax)
Please see:
http://www.wikimatrix.org/wiki/feature:CREOLE%20support
http://www.wikicreole.org/wiki/TikiWikiCMSGroupware

Related:
http://dev.tiki.org/Why+Wiki+Syntax+is+Important
http://dev.tiki.org/tiki-index.php?page=2007-07-18+IRC+MediaWiki+discussion&highlight=creole
http://tiki.org/RFCWiki


Related:
*[wish1531|Wiki markup for icons]
*[wish1805|Universal Wiki Edit Button]
*[wish2102|Support some of the MediaWiki syntax that doesn't conflict with TikiWiki syntax]
*[wish1843|Infoboxes like MediaWiki/Wikipedia, but making use of trackers to be future-proof]
*[wish1220|MediaWiki import script]
tracker item
Support some of the MediaWiki syntax that doesn't conflict with TikiWiki syntax
Please go to "Syntax Examples" here:
http://www.wikimatrix.org/compare/TikiWiki-CMS-Groupware+MediaWiki

Please also see:
http://meta.wikimedia.org/wiki/Help:Wikitext_examples

Some syntax could be supported as it doesn't really conflict with the existing.

__Basic formatting markup__
{img src=images/code.png}%%% {CODE()}
You can ''italicize text'' by putting 2 apostrophes on each side.

3 apostrophes will '''embolden the text'''.

5 apostrophes will '''embolden''' and ''italicize''
'''''the text'''''.
{CODE}


__Signature/timestamp__
{img src=images/code.png}%%% {CODE()} You should "sign" your comments
on talk pages:
- Three tildes gives your
signature: ~~~
- Four tildes give your
signature plus date/time: ~~~~
- Five tildes gives the
date/time alone: ~~~~~ {CODE}

__Section headings__
{img src=images/code.png}%%% {CODE()} == Section headings ==

''Headings'' organize your writing into
sections.
The ''Wiki'' <u>ab</u>
##software can automatically
generate a [[table of contents]] from them.

=== Subsection ===
Using more "equals" (=) signs creates a subsection.

==== A smaller subsection ====

Don't skip levels,
like from two to four equals signs.

Start with 2 equals signs not 1
because 1 creates H1 tags
which should be reserved for page title. {CODE}


However, links & images could be more problematic.

Related:
*[wish1531|Wiki markup for icons]
*[wish1191|Wiki editing: Preview with diff, like Mediawiki]
*[wish1843|Infoboxes like MediaWiki/Wikipedia, but making use of trackers to be future-proof]
*[wish1781|Support for the Wiki creole markup (syntax)]
*[wish1220|MediaWiki import script]
tracker item
Support to set limit of header level to show by maketoc
It will be nice to allow the setting of limit of levels to show for maketoc:
{CODE()}
{maketoc maxlevel=2}
{CODE}
will cause only ! and !! headers to be shown, not !!!.
tracker item
Syntax structures including ":" and color syntax doesn't work within a definition term (parser bug)
Syntax that should work inside a description term (the x in ";x:y") don't. This includes anything in a ':' in it even if it's nested within another syntax structure like a link or table. In a link, it's especially bad, since you can't use ~np~~np~~/np~ to fix it, e.g. you can't fix ~np~((a:b))~/np~. Also, ~np~~~color:x~~~/np~ doesn't work.

~pp~
!!!~np~;a:text~/np~
;a:text
works
%%%%%%%%%%%%
!!!~np~;~~red:a~~:text~/np~
;~~red:a~~:text
looks like ~np~;a:text~/np~
%%%%%%%%%%%%
!!!~np~;((a)):text~/np~
;((a)):text
works
%%%%%%%%%%%%
!!!~np~;((a:b)):text~/np~
;((a:b)):text
looks like ~np~;a:((a:b|b)):text~/np~
%%%%%%%%%%%%
!!!~np~;((a|b:c)):text~/np~
;((a|b:c)):text
looks like ~np~;b:((a|c)):text~/np~
%%%%%%%%%%%%
!!!~np~;((a|~np~b:c~/np~~/np~~np~)):text~/np~
;((a|~np~b:c~/np~)):text
works
%%%%%%%%%%%%
!!!~np~;__a__:text~/np~
;__a__:text
works
%%%%%%%%%%%%
!!!~np~;||a||:text~/np~
;||a||:text
works
%%%%%%%%%%%%
!!!~np~;||a:b||:text~/np~
;||a:b||:text
this just looks strange
~/pp~

I looked in the parser code, and it's pretty obvious why these bugs occur. The parser code, to put it bluntly, sucks. It uses regexps for most parsing instead of a proper context-free parser, so it's bound to have these types of bugs.
tracker item
t.o: page alias feature not working because some duplication exists (not prevented at edition time and feedback gone too quickly)
tracker item
Table editor in wiki edit doesn't open anymore in some scenarios
tracker item
Table of content (TOC) - maketoc or autotoc - polluted ?
tracker item
Task/action markup for meeting notes and plans (like Twiki Action Tracker Plugin)
Well explained here:
http://twiki.org/cgi-bin/view/Plugins/ActionTrackerPlugin

We'd output in htask microformat
http://microformats.org/wiki/htask

And we'd need some sort of reporting. All tasks assigned to person X.

We currently usually do this with ((doc:trackers)). But doing it fully in the wiki would be more flexible in some contexts.

The system should be able to send email reminders at a certain date. This could be used as well to schedule actions / Email reminders as explained here:
http://www.youtube.com/watch?v=8XwyhSEqTs0

This is part of what is needed for ((Project management))
tracker item
text annotations (select a snippet, and add a signed/dated text note)
Similar to ((doc:PluginAnnotation)) for images.

This would make it easier for people to know who added what comment, when and to distinguish the main content, from notes.

Similar to ((doc:PluginMouseOver)), but should be easier to use.

Related:
{wish id=1409}
tracker item
Text area toggle issue e.g. !-# or !+#
tracker item
Text coloring in links
__Tikiwiki__ V6.1
__Firefox:__ 3.6.13

Using the "Colored Text" specifier in a Wiki link specifier like this:

~np~((Second Deletion List|~~red:__Unix Shared ID Deletion 2__~~))~/np~

results in the ~np~<SPAN>~/np~ tag being revealed instead of presenting text colored as specified. While not a critical item, we have just upgraded a site that has smattering of these throughout. It did work at one time obviously or they wouldn't be there now.

The link does still work and is not effected.

--Steve
tracker item
Text colour palette is blank on wiki editor toolbar
tracker item
Textarea hidden when edit form opened (codemirror on, in dev.t.o)
tracker item
The {{itemId}} {{page}} {{user}} wiki-syntices do not work
TW50B1 does not replace the {{itemId}} {{page}} {{user}}. I just displays all these without touching them.
See last section of
http://doc.tikiwiki.org/Advanced+Wiki+Syntax+usage+examples&structure=Documentation
which describes what should happen.
tracker item
The field with the smilies does not appear in places where they should be available
In certain instances when editing a page through the text editor (or creating a new blog post), with the wysiwyg-available available (though hidden) the smilies field is not displayed.

The problem is probably due to the fact that the variable $wysiwyg contains an 'n' if the editor is hidden while in some instances the value is NULL. This is probably because if the wysiwyg feature in admin-features is disabled then the $wysiwyg value is NULL, but if it is enabled but hidden the value is 'n'.

There is a conditional in templates/tiki-editpage.tpl that does not take this into account.

(The problem may be present in other versions as well)
tracker item
The string "<link" is replaced with "<link" before being passed into plugins
Any occurrence of the string "<link" in a plugin of any case (for example, within a CODE block) is being replaced by the string "<link" (note case conversion) before being passed to the plugin as $data.

tracker item
Tiki 7.1 HTML parsing - WYSIWYG/CKE - not working in some feature like for ex. in articles
Hello Devs,

I did upgrade a site to 7.1 this weekend.

Using WYSIWYG/CKE I have the following prblem:

In some features of the Tiki 7.1 the output the editor is just the plain
HTML Source.

That means, not in Wikipages, but in the articles and in the calendar
events, there is not a nice text with formatting bold, italic, colors
and pictures etc, but only the plain HTML source code visible to the
website user/visitor.

The WYSIWYG/CKE editor works normal and I can see the content just
normal like ever, being in the editing mode. But when I save, I can just
see the source code, like it would be in codeplugin.

This affects as said articles and calendar (perhabs more, I will hope to
find out) but it does not affect wikipages by now.

And it affects existing articles and events aswell as newly edited.

(worked well in 6.x before)

Thx for reply and wish a nice sunday to all,
cheers
Torsten
tracker item
Tiki comments wiki syntax not parsed anymore with PluginInclude as seen on https://nextdev.tiki.org/File-a-bug
tracker item
Tiki parsing error in wiki
A backslash followed by 00 between non-parsing pre-formatted commands worked previously in tiki 1.8.5 but caused fatal memory errors / blank pages (even after memory increase to 64M) in tiki 1.9.2

Below is the exact line that caused the problem.
~pp~
#1 0x08071f28 in MJobSelectClass (J=0xd225858, ModifyJob=1 '\001', ModifyRM=1 '\001',
~/pp~
tracker item
TikiWiki 2.0: Enable Wiki Syntax on Custom Header Section
It is great that TikiWiki allows an administrator to customize the Custom Header of a given Website. This allows more personalization than the out of the box "Powered by TikiWiki" logo.

To extend this flexibility, it would be great if one could reference Wiki plugins - custom-built or native Tiki - in the header. As an example, a {RANDOMQUOTE} plugin similar to the simple PHP function on the attached page

http://php.about.com/od/finishedphp1/p/random_quote.htm

I know Christmas is a way's away, but this would be a great early gift!
tracker item
TikiWiki Forums execute code outside of {CODE}
Using the forums, when posting code the {CODE} button must be used (which places it inside the box).

If this is not used, the code will execute.

Example:

http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=32456&topics_offset=7&topics_sort_mode=lastPost_desc&forumId=4

What happened:

This uses the {REDIRECT} plugin. I forgot to put it inside a code block while seeking assistance.
---
2013-12-04 petjal
Confirmed on show:
http://comnenus-10695-2381.show.tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=1
un/pw: show/show
admin/pw: admin/showadmin
(I couldn't figure out how to add a comment to this bug.--Pete)

tracker item
Titles (headers) in FADE plugin call content are included in table of contents (maketoc)
tracker item
tracker comment editwiki_toolbar is not turned off even if section_comments_parse is disabled
tracker item
Tracker description not wiki parsed when using TRACKER plugin
When using the TRACKER plugin with Tiki 2.2:
*I created a new tracker.
*In the tracker's description, I enabled the "Wiki parsed" option and included wiki syntax in the description.
*On a wiki page, I added the tracker with the TRACKER plugin
*I set the __showdesc=y__ option.

The description appeared, but was not wiki parsed.
tracker item
Tracker fields textarea content wiki parsing doesn't work the same as wiki page content parsing
tracker item
Tracker list plugin cache is showing a hash

{THUMB(id=17,url="show_image.php?id=17")}{THUMB}
tracker item
Tracker, Text Area help; The help button above a tracker area field at dev.t.o doesn't work anymore
tracker item
trackerlist plugin: popup breaks on certain content
Seen problem on ! and ^

Ex.:
http://dev.tikiwiki.org/tiki-index.php?page=WYSIWYG
tracker item
Translation of this page is incomplete - displays in wrong language.
__Wiki / Translate / Translate this page to a new language__

When creating a tranlsation of a wiki page by way of the "Translate this page to a new language" button, the following is automaticlaly inserted above the untranslated text trabsferred fromn the original page to the new page:

^Translation of this page is incomplete.^
I assume this is designed for the benfit of people reading the page (rather than those editing it) and as such I find it very useful for the following two reasons:

If you are using a site in one language, say English, and a page appears in another, say French, its very useful for the reader to understand that:
* nothing is wrong e.g. they haven't mistakenly navigated to the wrong page or changed their language settings, and
* the site editors are aware that the content requires translating.

The problem is that it displays in the wrong language (e.g.in our example above in English when the reader may only understand French). The reader needs to see "Translation of this page is incomplete." in their own language regardless of the language of the untranslated text beneath it, otherwise the benefits above are lost.

(Of course, the same should all apply to Articles but they don't seem to have the "Translate this page to a new language" feature yet - only the ability to link to another already created Article at present).
tracker item
Trying to make a text with link highlighted in bold syntax breaks the page layout
tracker item
TWPCode
wiki
UI of Feature External Wikis in 14.x shows 2 extra unrelated fields
tracker item
Unable to insert a wiki plugin
tracker item
update php to php-5.2.11-r1 and in tikiwiki-2.4 break tag ~pp~ and ~/pp~ whit use russian
Type in wiki page:
^
~pp~
!test test
1111
~pp~
2222
3333
~/pp~~/pp~
^
Work fine:
^
__test test__

1111

2222
3333
^
if type russian heading:
^
~pp~
!тест тест
1111
~pp~
2222
3333
~/pp~~/pp~
^
Result is break:
^
__тест тест__

__2222__
__3333__

__3__
~pp~~/pp~~/pp~
^
tracker item
URLs including wiki-syntax are not linking properly
tracker item
Wanted: default class for images added in wiki editors
Images that are added using the wiki editor (anyway the normal editor, I didn't check the wysiwyg editor yet) don't have a default class. This is the simple case of no containing box or anything added along with the image. Therefore it isn't possible for them to have a default style such as margin or border unless it is added manually by the page author. Or if it is specified by the stylesheet (.postbody img or .wikitext img, etc.) then ''all'' images in those divs get the treatment, including smileys and external link icons, etc.

I suggest adding a default class like "contentimage" to enable a default style. Page authors can always add a second class if needed.
tracker item
wiki "edit by section" doesn't allow concurrent editions of different sections on the same page
Wiki "((doc:edit by section))": Nice feature added, thanks heaps to those who made that possible! :-)

BTW, I found that it doesn't allow concurrent edition of different wiki sections of the same wiki page.
Tried on doc.tw.o on June 8th 2008, using Mittwoch and also Tikinewt.css (After clearing tiki cache) , and it didn't work for me on any of both cases.

doc.tw.o page needs to be updated once fixed.
http://doc.tikiwiki.org/edit+by+section
tracker item
wiki (wysiwyg) inline editor transforms page alias links into standard wiki page link on save (alias lost)
tracker item
Wiki Argument Variable error when used with Wiki Plugin
2022-10-17: I (marclaporte) added PluginCode on examples below because it causes issues on index rebuild.

When using Wiki argument variables within a Wiki plugin, the combination of the curly braces and the quotation mark (e.g. {{itemId}__}"__)prematurely ends the plugin's options syntax.

Example:
{CODE()}
||__Plugin__|TrackerFilter
__Plugin Field__|url
__Field Value__|"Edit+Compound&itemId={{itemId}}"||
{CODE}

The following is an example of what I can see when editing the text of a wiki page:
{CODE()}
|| ~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"}}"} ~/pp~ ||
{CODE}

This is what should be shown:
{CODE()}
||~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"} ~/pp~||
{CODE}

If you keep on editing the plugin using the edit icon and saving without making any changes, it will keep adding on any options that proceed the argument variable, like thus:
{CODE()}
|| ~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" url="Edit+Compound&itemId={{itemId}}" silent="y"}}" silent="y"}}"} ~/pp~ ||
{CODE}
tracker item
Wiki Argument, page; It is now necessary (on Tiki26) to use the wiki variable page and/or limit pagination to 1 to pass it inside a smarty template using it.
tracker item
Wiki formating for box - no box
The Wiki Help page lists [carat] ^a box^ [carat] to generate a box. But it doesn't generate a box in the WIKI entry, nor in the Help page.
tracker item
New wiki links are broken on updated RTL Tiki when in a list
tracker item
Wiki link with equation tag fails
A wiki link in combination with a equation tag parses falsely.
This editor entry

{CODE()}((Fire weather index|{EQUATION()}FWI{EQUATION})){CODE}

displays the text output:

<img src="lib/equation/pictures/564a4dc730e638713aa76bb604088f85.png" alt="§7008f9602faf2722caf095a92ed8d624§" style="vertical-align:middle">§1a7e9ee2385aa1db7956a7f63689955f§

In HTML code:

<a class="wiki" title="Fire weather index" href="tiki-index.php?page=Fire+weather+index">&lt;img src="lib/equation/pictures/564a4dc730e638713aa76bb604088f85.png" alt="§7008f9602faf2722caf095a92ed8d624§" style="vertical-align:middle"&gt;§1a7e9ee2385aa1db7956a7f63689955f§</a>

The same in version 4.2 which is correct:

<a class="wiki " href="tiki-index.php?page=Fire+weather+index" title="Fire weather index"><img align="absmiddle" alt="FWI" src="lib/equation/pictures/04d4e88879dbf4f876f4b62fea56172f.png"></a>
tracker item
Wiki links with brackets at end of page name drop closing bracket
If I enter:
~np~
((pagename(something_in_brackets))) or ((pagename|description(something_in_brackets)))
~/np~

The pagename or the description will not have the closing bracket included. It should.
tracker item
Wiki Links with space hyphen-minus space do not work
When creating a link like this

((test - test))

to link to a page named 'test - test' then the created page is missing the hyphen. Additionally the pages is always shown as non-existent, meaning that the question mark behind the source link is always there, even if th e page was manually renamed. It is a real blocker.


tracker item
Wiki markup for icons
In addition to smilies and text formatting like bold, add syntaxes for commonly uses markers in text.

Please see some nice examples here:
http://wikifeatures.wiki.taoriver.net/TextFormattingRules

Which are inspired by :
[http://moinmo.in/HelpOnSmileys|MoinMoin]

I like:
/!\ warning
(./) check
{OK} thumbs up
{i} information
{1} {2} {3} for nice numbering

We currently use images at doc.tikiwiki.org and it's cumbersome.


From #wiki (freenode)

(11:20:53) TheSheep: marclaporte: btw, if you need some icons, there are some I drew at http://sheep.art.pl/Icons
(11:21:10) TheSheep: marclaporte: especially the hand icons can be... uhm... handy
(12:16:35) marclaporte: hehe
(12:17:52) marclaporte: for icons: is license compatible with LGPL?
(12:18:15) marclaporte: I wish we had a license compatibility grid for CC vs GNU
(12:19:58) TheSheep: marclaporte: I can relicense it for you
(12:20:17) TheSheep: marclaporte: although using gpl for something that's not software is weird for me
(12:33:22) marclaporte: yes, but icons have to in the app, no?
(12:42:45) TheSheep: marclaporte: but icons are also distributed when somebody merely uses the web app
(12:43:00) TheSheep: marclaporte: would you want to force them to provide the source code?
(12:44:49) marclaporte: I just don't want any trouble
(12:45:02) marclaporte: and to respect author's wishes
(12:45:51) TheSheep: marclaporte: I can promise I won't give you any trouble, just tell me what you need to use them :)
(12:46:01) marclaporte: hehe
(12:46:13) TheSheep: marclaporte: it will also help me to release my future works in a way that is friendly for developers
(12:46:22) ***marclaporte is adding on todo list
tracker item
Wiki option, "Discuss pages on forums" - option not sticking
Hello,

Recently upgraded to 3.0..

Thought I'd turn on the "Discuss pages on forums." option.. Created a forum for the purpose.. Went to the Wiki admin page and selected the option.. Picked the forum from the popup that appeared.. Pressed "Change preferences."..

No change.

Tried several times in different ways on different browsers.

No change.


How can I enable this option?



Thanks in advance,

Karl
tracker item
Wiki page edit switching to fullscreen mode and back broken
tracker item
Wiki pages: define a content template as default?
Content Templates are an easy and comfortable way to change the look and content of wiki pages. It would be nice to be able to define such a template as your default for wiki pages, instead of having to choose it every single time you create a new wiki page, or changing the template of wiki pages in general.
tracker item
Wiki parse is broken in custom modules
tracker item
Wiki parser is unable to parse two wikilinks separated by one hyphen
Tikiwiki is unable to properly parse the following syntax:

~np~((Somelink))-((Otherlink))~/np~

The expected output is two wikilinks separeted by the hyphen. Instead the output is (tested on svn branches 3.0 and 4.0):

((Somelink-Otherlink))
tracker item
Wiki parsing in link text of wiki links partly broken
in older versions eg. 2.4, it was possible to use wiki page links with ampersands ( &) and also different color in the link text

for instance : ((Look_and_feel|Look & feel)) gave the link like <a href=./Look_and_feel> look & feel </a> does

or ((Look_and_feel|~~#00F:Look and feel~~)) gave the link in blue color

Both works with external link syntax [./Look_and_feel|~~#00F:Look and feel~~]

most probably it's the same error as describe in bug #3585


if it's helpful : I'm willed to give a bonus to the person who will fix the bug
tracker item
wiki parsing processes inefficiently much and maybe even insecure
Try this:
{CODE()}
{GROUP(groups=>"xyz")}
{PLUGIN(that takes long) /}
{ELSE}
{ANOTHERPLUGIN(that takes long) /}
{GROUP}
{CODE}

The parser goes through both plugin and another plugin.

Related: 3134
http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=3134&trackerId=5&show=view

Is the parser improvement already on the TW6.0 blockers' list?
tracker item
Wiki plugin (syntax and) parsing makes embedding code inconvenient
It is rather difficult to write plugins that embed other plugins. The reason is the wiki syntax of the plugins not expressing if it is a beginning or an ending clause. The default is the "{X} body {X}" syntax.
Instead, {X} body {/X} should be used.
While this latter syntax as well as the {X /} are accepted by $tikilib->parse_data, it does not process the embedded calls. E.g {X} {X /} {/X} does not work. It returns an empty body instead of {X /} or the result of {X /}.
tracker item
Wiki slideshow viewing mode (Slides) shows fragments of plugins
# enable Slideshows feature on Wiki Admin panel
# log out
# click on the Slides button under HomePage content; tiki-slideshow.php?page=HomePage&slide=1 displays fragments of plugins as ~np~{DIV}~/np~, ~np~{ELSE}~/np~ and ~np~{GROUP}~/np~ (in other words it doesn't parse the plugins properly)
tracker item
Wiki syntax doesn't work in Tracker comments
Wiki syntax is not enabled in Tracker comments on this site. May be usability bug in later Tiki versions.
tracker item
Wiki Syntax for page alias should be a wiki plugin
tracker item
Wiki syntax or plugin for back button
A plugin like this:
{img src=images/code.png}%%% {CODE()}
{BACK()}{BACK}
{CODE}

Thats does this:
{img src=images/code.png}%%% {CODE()}
<input type=button value="Back" inhibited_Click="history.go(-1)">
{CODE}
tracker item
Wiki Syntax: add support for @username mentions with notification
tracker item
Wiki Table syntax: WYSIWCA for QuickTags
In the Quicklinks, there are two table links (one for the old wiki-table syntax, and one for the new).

On the Wiki table syntax in effect (from tiki-admin.php?page=wiki) should appear.

In templates/tiki-edit_help.tpl, this is already done with:

{if $feature_wiki_tables eq 'new'}

---
On second thought, since the new table syntax is so much better, and it's now the default on new installs. All references to old syntax should be phased out. People should only use it if they have large amounts of legacy data that they don't want to take the time to convert.
tracker item
Wiki Table-Syntax broken
Wiki syntax parsing for tables is broken

Following two things are supposed to work. These are just copied from the offered quicktags.

||r1c1|r1c2
r2c1|r2c2||

||r1c1|r1c2||r2c1|r2c2||

First one works, but the second ones ends the table at the || and then just prints the text " r2c1|r2c2|| ".

Ok, just saw that Trakcer-Items are Wiki-parsed, too. Good thing! As you can see the effect live! :)

Hmm, everything gets saved, when editing a Tracker except for the feature.... I really have to start working with them.... and search for bugs... sorry for three mails about this, if you are subscribed!
tracker item
wiki tag "file" rendering issue
Following code inserted into wiki page is causing problems.

{file name=attached_file_name}

In TikiWiki 1.9 was name of file shown with link to file. In TikiWiki 2.x only single closing bracket (i.e. '}') is shown instead.

Following wiki code gives expected result in both 1.9 and 2.x versions (please note space before closing bracket)

{file name=attached_file_name }

File tag is parsed in file lib/tikilib.php in function parse_data(). Tag file is translated to call of ATTACH wiki plugin. It seems that essential is call of split_tag() method with cleanup parameter set to FALSE (in tikilib.php revision 1.801.2.92 it's line 5474). In branch 1.9 was cleanup hardcoded to TRUE in split_tag() body. Setting cleanup to TRUE 2.x gives expected result.

I can see that optional cleanup parameter of split_tag() method was introduced in tikilib.php revision 1.602. At the same revision was cleanup value in file tag parsing section set to FALSE. Commit comment says "Minor tweak to preserve ' in {file ...} links.". I don't know idea behind it so I'm not able to correctly fix file tag rendering issue. Simple change of cleanup parameter to TRUE would probably cause regression of another bug.
tracker item
Wiki text color breaks with two colors on one line
In Tiki 3.1, the wiki syntax for text color breaks when there are two colors on one line. See http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=&comments_parentId=33947 for the forum post reporting this, and examples of the problem.

(Edited to check "watch" feature.)
tracker item
Wiki text returned from plugn not parsed
__Tiki:__ 6.1
__Firefox:__

Wiki text returned by the SQL plugin is not translated. I used the "Quote" plugin to verify if this problem exists for all plugins returning Wiki text and the value translated as specified in the data passed.

We make fairly extensive use of the SQL plugin on our internal department site. A technique for implementing this plugin we use is to enclose the return value of a column in double parenthesis. This enables us to have a web page reference for each of the returned rows.

This technique is used in several circumstances. One is that we select from our database stored information on hundreds of servers making the server name a link to a detailed info page. The example below is used to link to project detail pages describing individual active projects.

{CODE(caption="Example SQL",wrap="0")}
select
concat( '((', p.project_name, '))' ) as "Project Name",
u.user_username as "Project Owner",
tdv.value as "Project Status"
from
projects p,
departments d,
project_departments pd,
tsi_dp_valsets tdv,
users u
where p.project_id = pd.project_id
and pd.department_id = d.dept_id
and d.dept_name = 'TSI-KPHC'
and u.user_id = p.project_owner
and tdv.ID = p.project_status
and tdv.value != 'Archived'
and tdv.value != 'Complete'
order by tdv.value;
{CODE}

This issue is not restricted to link specifications as bold (double underscores) no longer work when returned by SQL either.

I have rated this a "9" strictly from a personal importance perspective and not as a definition of impact to the overall Tiki project. The customers of our department rely on these returned links for information and updates.

I have been all through the Administrative areas hoping to find a feature flag to turn on wiki text parsing of plugins (before trying the above referenced "Quote test") and am also unable to find such a flag specific to the SQL plugin.

--Steve
tracker item
Wiki transclusion a-la MediaWiki templates
The capability to include (recursively) with parameters is probably the most powerful and content factorizing feature of our best competitor MediaWiki.

It make not only produce content much faster and in a much more modularised way.

The references :
* [http://en.wikipedia.org/wiki/Transclusion]
* [http://www.mediawiki.org/wiki/Help:Templates]
* [http://doc.tikiwiki.org/PluginInclude]
tracker item
Wiki-syntax parsing is different in lot of other places than in Wiki
You can see the effect of Wiki-syntax getting parsed differently with the ~np~ ~np~ ~/np~ tag and the~np~ {CODE()} ~/np~ -plugin.

~pp~
~np~text here~/np~ - strips all linebreaks out of "text here" - ~pp~ works

{CODE(caption=>test)}
text here and some enclosed in <these brackets> here
{CODE}

The text between the <>-brackets doesn't get shown at all.
~/pp~

Also, (just in case it's related): tiki-view_blog.php complains to admin user about a division by zero by split plugin (tiki 1.9.2):
* {CODE()}
Warning: Division by zero in /var/lib/gforge/chroot/home/groups/gclub/htdocs/lib/wiki-plugins/wikiplugin_split.php on line 74
{CODE}
* This warning message was not present with 1.9.1. (Xavi - xavidp)

The blogs were htmlspecialchar()ed, too - it looks like fixed in CVS now!
tracker item
Wiki: Page rename to also change links in menu system, in forums and in trackers
When a wiki page is renamed, all links in Wiki pages are fixed. Excellent!

However, menu items are not updated. This would be a nice to have. Same thing for wikilinks in forum posts, trackers, etc

I guess it could get tricky because some use links like tiki-index.php?page=blabla, but some just but blabla and use the .htaccess
tracker item
Wikiparser interprets tags different in editpage than in the page view
If you enter following code in a wiki-page ~np~ ...page... ~/np~ there is a bug in the interpreter. The preview-mode is working right and shows ...page... as plain text, but when you save the page wiki-parser interprets it as a tag and shows the pagenavigation-bar.
tracker item
wikiplugin_include change from Tiki15->Tiki18
tracker item
WikiWords don't work
Typing a WikiWord does not result in a wiki link. You must enclose the word in (()), even if the feature is turned on.
tracker item
Prevent special characters in page names is not effective when using using multilingual
tracker item
WIP: Wiki Syntax, Markdown; Wiki links are not parsed (when markdown is enable)
tracker item
wrong linebreak with ">"-character in wikipage
if you enter the <-character in a text (e.g. for an arrow like -->) the following lines have no linebreaks anymore
tracker item
WYSIWYG and normal editor are not screen width in IE8
This bug is seen by our IE 8 clients. We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

When our users try to edit their pages either in WYSIWYG or normal mode, their editor text box is half the width that it should be. They need to use the dragger to make it wider. If we edit in Firefox then the editor is the correct width.

Since IE is our corp standard our users need to be able to add files using that browser. Also, this is the same problem we had in Tiki 5.x and we were hoping 6.x would have fixed it.

Thanks,
Tim
tracker item
WYSIWYG editor addes extra <br> tags
When you edit text using the WYSIWYG editor, extra <br /> tags are added when the text is displayed in preview or when it is saved. These break tags do not show up when you try to edit the page again, making them impossible to remove.

For example, if the markup in the WYSIWYG editor, when you view the source, is as follows:

''<p>This is some text.<br />This is some more text, on a new line</p>''

What shows up when you view the source of the page that is generated after you save/preview is as follows:

''<p>This is some text.<br /><br />This is some more text, on a new line</p><br />''

As a result of this, the spacing on pages edited by the WYSIWYG editor is bizarre and stretched out.

tracker item
WYSIWYG editor addes extra <br> tags
When one is using the WYSIWYG editor to edit text, extra <br /> tags are added after all <p> and <br /> tags when the text is displayed after save or preview. These tags don't show up in the source code in the WYSIWYG editor at all, so you can't remove them. As a result, the spacing between the text is all wrong.

For example, if you view the source of a page in the WYSIWYG editor, it would look like this:

<p>Some text<br />And more text on a new line</p>

But when you view the source of the page after you have saved it, it looks like this:

<p>Some text<br /><br />And more text on a new line</p><br />

tracker item
wysiwyg editor, or normal editor with html enabled, doesn't parse {maketoc} on wiki pages
See live example here:
http://moviments.net/cursos/IMDIG-I-Apunts

Wysiwyg editor is enabled, and those are the general wysiwyg settings on the site:
|| Wysiwyg Editor is optional: | X
... and is displayed by default: |
Reopen with the same editor: | X
Content is parsed like wiki page: | X
Content is partially parsed: | X ||

The wiki page http://moviments.net/cursos/IMDIG-I-Apunts was last edited using normal editor, keeping "allow html" checkbox as enabled on that page. When you write
{CODE()}
{maketoc}
{CODE}

The string ~np~{maketoc}~/np~ is displayed, but the table of contents fort that page.
tracker item
WYSIWYG_6x - Anchor flag not saving
We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

This bug is across all browsers.

Our users are editing in the CKEditor WYSIWYG and trying to add anchors. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%our users use the Anchor icon (flag) to create an anchor at the bottom of a page. The anchor name window comes up and they give it a name, save, a yellow anchor icon is displayed in the editor. If they jump to the top of the page and create a Link (using the Link icon in the toolbar) and select Link Type: "Link to another anchor in the text", Select an Anchor/By Anchor Name and press Ok. At this point everything looks correct in CKEditor.The user presses Save. The Link at the top is correct using the normal syntax %%% {CODE()}[#myAnchor|Link to bottom]{CODE}%%%however the anchor at the bottom is gone as if it never saved or the parser has discarded it.

I have had to instruct our users how to type in manually the anchors using the old plugins [http://doc.tiki.org/PluginAlink] and [http://doc.tiki.org/PluginAname]. They are not happy about using long hand plugin notation.

I have tried in both IE 8 and FF 3.6 with the same result.

Since IE is our corp standard our users need to be able to add anchors using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system.

May be related to [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1499]
tracker item
WYSIWYG_6x - Edit Section buttons return blank page
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not edit a section using the Edit Section button. A blank WYSIWYG screen is displayed and if you enter content and save it gets thrown to the bottom of the wiki page and not within the section.

Reproduce: Create a blank wiki page in WYSIWYG, create a bunch of headers, save, view edit icons (if not already), click on "Edit Section" button.
tracker item
WYSIWYG_6x - Formatting breaks "header" status
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not format the header (color it red) without breaking the "header" status.

Currently we have a page with a ~np~{maketoc}~/np~ at the top and a bunch of h1, h2, h3 headers. We wanted to make the text color red for one of the h1 titles so it was more visible to users. Once we did this in the WYSIWYG editor, the header is no longer listed in the maketoc AND the Edit Section button is gone next to the header text. This ''may'' be associated with another bug [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=3763].

tracker item
WYSIWYG_6x - List spacing inconsistent
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%% the lists (numbered and unordered) have irregular spacing between lines. Edited in Wiki normal and WYSIWYG Source modes work fine.

To reproduce create the following structure in a WYSIWYG editor{CODE()}*blah zaa zaa
*This is a list
**now indenting the list
**blah
*back out
**back in
***really far in
*all the way out{CODE} %%% this example displays for us as {CODE()} blah zaa zaa

This is a list

now indenting the list
blah

back out

back in

really far in
all the way out
{CODE} %%% Sometimes there is a break, other times there is not. If I Preview while editing it looks fine. If I edit the HTML via the Source WYSIWYG view and save then it looks fine until I save it in WYSIWYG mode again.
tracker item
WYSIWYG_6x inserts !'s into text before any text formatted as a header, saved, then edited again
When editing or creating a page using the WYSIWYG_6x editor, setting any text as a header then saving the file works correctly, however if the page is edited again, the WYSIWYG editor inserts a ! before or sometimes after the text you decided to format as a header.

Looking at the source, it appears that it is inserting the following into the page:

<p>
!</p>

Attempting to remove it by deleting the ! in the WYSIWYG editor just results in it showing up again, either immediately after saving or on the next edit of the page. This results in people not wanting to use the header feature or finding other workarounds such as larger font size.
tracker item
xavi
Contributors
tracker item
XML code gets erased when switching from wiki editor to WYSIWYG
tracker item
XSS Sanitization destroys links with certain strings
tracker item

Keywords

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)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Diagram
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw -superseded by Diagram
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Gantt
Group
Groupmail
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Kanban
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend
Terms and Conditions
Theme
TikiTests
Federated Timesheets
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
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
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools