Name | Type |
---|---|
"internal link" button doesn't work -- "local.php not found" | 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 ja Search for ja http://tikiwiki.org/tiki-searchindex.php?highlight=ja 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 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 " 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 " |
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: ur }{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: ur {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 ( >> 'ur >> * /var/www/tiki/trunk/lib/tikilib.php : 3739 ‑> queryError(array ( >> 'query' => '\'insert into `tiki_link_cache`(`ur >> 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 < 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()} [ur 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 —), 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 |
syntax type=markdown code disappears from Content Template | 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 "<li Any occurrence of the string "<li |
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__|ur __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" ur {CODE} This is what should be shown: {CODE()} ||~pp~ {trackerfilter filters="126/m" trackerId="11" fields="123" ur {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" ur {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"><img src="lib/equation/pictures/564a4dc730e638713aa76bb604088f85.png" alt="§7008f9602faf2722caf095a92ed8d624§" style="vertical-align:middle">§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 |
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)