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

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)

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.

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

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

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.

Contributors

Contributors

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.

Contributors

- 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

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.

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

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.

External wiki links are mistakenly identified as wanted pages

http://profiles.tikiwiki.org/Admin

{WANTEDPAGES()}{WANTEDPAGES}

Contributors

Contributors

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!

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.

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:)

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

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

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 )

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">.....

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]

[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

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.

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.

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.

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}

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.

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.

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

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

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

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.

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.

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

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

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.

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.

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))

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'

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.

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. ****

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.

~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.

The dynamic variable syntax (~np~%dynamic_variable%~/np~) displays as plain text in my 1.10 installations, rather than functioning as designed.

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.

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.

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.

The title says it all!

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}

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}

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))

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

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.

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}

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

The Full Screen edit button is visible in my quicktags list, even though I have the __Allow fullscreen edit__ option disabled.

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)]

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}

Not totally sure if this is feature request, bug, or lack of knowledge. Basically I need some way of supporting maketoc with WYSIWYG pages.

~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~

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

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~

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.

just like this ((text中文))

it can't be parsed correctly as a page referer.

If you click on an Edit Section button, the Switch Editor button is not available when you are editing.

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.

No indent
: One indent
:: Two indents

Please see:
http://www.mediawiki.org/wiki/Help:Formatting

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.

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.

((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]

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.

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

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

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.

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>"

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

Discussed on wiki pages:
* ((Screencast))
* ((Copy-Pasting an image))

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

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.

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}

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}

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

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