Category: Release20

Tested when generating webhelp from a wiki structure...

With the "best langauge" feature enabled, Tiki will generate wiki links with the &bl=y suffix. When converted to webhelp, Tiki does not remove this link suffix.

As a result, HTML links includes this suffix. For example: foo&bl=y.html

This is incorrect -- the link should simply be: foo.html

Tested with 1.10 SVN from June 20, 2008...

When using the TRACKER plugin on a wiki page, if the user submits the tracker successfully, Tiki scrolls to an anchor in the tracker from to display the success message.

However, if the tracker was not submitted successfully (such as missing a mandatory field), the page is redisplayed at the top of the page -- Tiki does not scroll down to the form to show the error message. The user will be unaware that the tracker was not submitted.

To test:
1. Create a long wiki page.
2. At the bottom of the wiki page use the TRACKER plugin to add a form
3. Attempt to submit the form (using invalid data).

Tested with 1.10b1...

When generating webhelp from a wiki structure, Tiki creates the ../pages/img/wiki_up/ folder, but does not populate the folder. This results in missing images when viewing the generated HTML files.

Tested with 1.10b1...

When generating webhelp for a wiki structure, if the wiki page contains {TOC} or {MAKETOC} plugins (that generate a list of child pages/headings), the list is not included in the generated webhelp HTML.

Tested with 1.10b1 from SVN (not sure about prior releases).

When generating webhelp from a wiki structure, if a wiki pagename or page description includes a " (quote), the webhelp will fail.

Workaround:
After Tiki generates the the files, you must manually edit the following file:

../webhelp/YOUR STRUCTURE NAME/menu/menuNodes.js

Look for the entry that contains the " (quote). It may be similar to:

insDoc(foldersTreeAAA,gLnk("R","Your page title with "quotes" here","pages/Your page name.html"));

You will need to "escape" the quotes as follows:

insDoc(foldersTreeAAA,gLnk("R","Your page title with \"quotes\" here","pages/Your page name.html"));

The webhelp will now function properly.

(This bug has been tested and verified on clean installs of TW 1.10b1 , 1.9.11 and on opensourcecsm.com)

When someone starts to create a new article (submit/edit/new) and chooses a different article type from the menu "Type", the field "Body" disappears (even if the heading_only property of the field is NOT set).

The problem seems only to exist on clean installs with empty databases which fill up the default values with null instead of 'n' for the different type settings.

In turn, the conditional in the function chgArtType() in the file /lib/tiki-js.js does not do a proper checking of the null values creating a situation where it interprets that the heading_only property for all article types is active (or so I gather). Thus it disables the Body field every time regardless of what the property of the article type says.

{syntax type="tiki" editor="plain"}
When printing a wiki page (or viewing the printer-pretty version) that has links, it would be nice if links actually showed the full URL.

For example

((http://yourtiki/foo|Foo)) would display as Foo (http://yourtiki/foo)

((http://yourtiki/foo|Bar)) would display as Bar (http://yourtiki/foo)

[http://foo.com|Bar] would display as Bar (http://foo.com)

When reporting that a categ. mandatory field is missing, another mandatory category multiple checkboxes loose their previous selection.

You can try that here:
http://moviments.net/cursos/Inscripcions+2008

Fill all mandatory fields except the last mandatory one. Submit. User gets the message that the last field is missing, which is true, but then, the selections made in the first mandatory field (category multiple check boxes) are lost. So if user only clicks on last missing mandatory field, he gets a message again that the first is missing, but the last is missing again then, etc.





Same behavior when using the tracker directly (instead of tracker plugin)

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

In 1.9.x, Side-by-side diff is the default

Sometime in the history of 1.10 (around when WYSIWYG editor arrived I think), HTML diff became the default.

This appears to be more of an accident than a conscience choice.

Side-by-side should re-become the default.

Ever better, the admin should should what the site default it.

Even better, each user could override this value in their preferences.

The wiki RSS feed seems to show the source code (.diffchar tags, etc.) of page version diffs, rather than showing the list of pages and their links.

{syntax type="tiki" editor="plain"}
Hi,
I found an issue using "wikiplugin_files" plugin.
If You try to use it (on Wiki pages or in other available places like parsable ptracker descriptions etc) Wiki page show files in the particular gallery but You can only download file. You cannot update newer version or see a history of that file althou theres an option to do it.
Ive try it both on TW 2 and TW 3(beta).
Ive tried to turn off/on all java UI thingy but w/o success.

Best regards,
Piotr

I have a strange problem on Tiki 2.0RC2:

I have two similar TikiWiki-installations. One just for testing on my Linux-Server and the second on a WinNT-Server. The Windows-Server is the one we want to/have to use for our Wiki :-(

On my Linux-Server works everything.

On the Win-Server don’t work wysiwyg-editor’s “Insert/Edit an internal wiki link”-button. The “window” opens but it shows only this animated waiting-bar. (See the picture)
Any other button works fine!

Right now using 1.10svn code when using wysiwyg you are not allowed to use ! (headings) and * or # (lists) as wiki markup (it gets shown as simple text, even if placed at the beggning of new lines)

According to http://doc.tikiwiki.org/Wysiwyg+Editor+Admin (April 10th, 2008) , the setting "__Content is partially parsed__" just includes:
* parsing of links
* parsing of images and generally what is included in { }
* parsing of wikiplugins

Header and butllets are vey simple and common wiki markup that would help mixing conent in wysiwyg pages from newbies on tiki 1.10 sites and more experienced users (not much skills needed for that markup)

This tracker item could not be found

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.

When saving a Smarty template for a specific theme using the TikiWiki admin GUI then all kinds of fake tags </x> are inserted in javascript.
It seems that the XSS filter is hitting here. It should not since it is a super-admin function and should not be XSS-filtered, of course.

I tried to edit tiki-editpage.tpl when this occured.

At http://tikiwiki.org/TikiWikiTV, the YOUTUBE plugin is being used, but the videos aren't displaying. A look at the finished page source shows that the movie src url is partially repeated, so broken. (The url in the page edit is the correct form, so then gets broken.) For comparison, the FLASH plugin works ok on that page, with no url distorting.

Once saved, style changes (such as setting the font size or centering text) results in pages displaying like these:

My test starts here. Not much of yle="font-size: larger">interest going on though!
AND
yle="text-align: center">Home Page Test

Clicking to insert an image: dialog is displayed buyt clicking on the Browse server button results in the error "Error creating folder "" (Can't create directory)". Manually entering an image in source view mode (<img src="blah-blah">) and saving results in: img src=/home/lib/fckeditor/editor/blah-blah height=30 width=28 (surrounded by curely brackets)

Both related to parsing the html from the WSYWIG editor?

Clicking "Insert/Edit an internal wiki link" shows the "Insert Internal Link" popup but no content is displayed. The dialog briefly shows a cancel button and then the "wait squares" but nothing more.

Found with clean installs of 2.0RC4 on Windows Server 2003 x32 and also server 2008 x64. PHP 5.2.6 (x32); MySQL 5.0.51b (x32 and x64); Apache 2.2.9 (x32)

(sorry if these aren't sufficiently related and should be in separate bug reports)

Hello,

sorry for my bad English, but I´m from Germany and I´ve got my last lesson at school - nearly 20 years ago...

So I hope that you will understand me, here my problem :

I use Tiki 2.0 RC4 with the "andreas08"-Theme. It works quite good, but this bug (maybe ?) happens when I try to edit and save the Theme-CSS via the Admin-Menu :

Some command lines will be added with a "x" (included by tag-brackets) and the instruction given by this command will be ignored - cause it´s "rubbish" than.
( I can´t show you an example, i tried it, but here the "X" in the brackets not appears after saving this thread. )

This strange "effect" also happens by editing or formatting an text by the wysiwyg-editor, so that the text appears with some "rubbish" code-tiles instead of the formatted styles. (Text-Color, Size, Justify, etc.)

I´m not sure - is it a bug, or is this a failure caused by myself ?

Thanks for any answers or comments an greeting form Germany.

Hofnarr

Text search on files is not usable in 2.0RC4. Table tiki_files "search data" is empty. Files were uploaded, then I defined MIME types, then reindexed. I clicked on "Reindex all files for search" in Admin>File Galleries but can't tell if anything happened; nothing is in Tiki Logs (I already know there is no code for Debug Console to show what Admin>File Galleries is doing). I defined the MIME filters in http://doc.tikiwiki.org/tiki-index.php?page=Search+Admin&bl=n

This apparently sometimes works. In my "trunk" development system I have different text/.doc files uploaded and those were reindexed after I defined the MIME types.

UPDATE: I had trailing spaces in the MIME type names and the filter commands, due to cut-and-paste behavior. I request that trailing spaced be trimmed from the MIME filter input fields.

Using the released tiki 2.0: db password should be hidden at typing time on upgrade through tiki-install.php

Right now, password can be seen by others when the admin type it on the screen when first calling to tiki-install.php on an upgrade of running tiki site.

The new "saved_msg=y" fails when SEFURL is on - both new pages and editing. It gives me a 404 not-found error. Makes SEFURL pretty useless. Example:
http://www.casesofinterest.com/tiki/Everything+is+Patentable&saved_msg=y

Following 2 separate/different upgrades from 1.9.11 to v2.0, in both cases the "Contact us" page is blank when it displays. The linkable page title shows OK at the top of the page but nothing else is displayed.

Both sites worked OK before the upgrade and everything else looks OK.

I've double checked that in both sites "Contact us" and "Contact us anonymously" are still set, plus the contact user is also still set with an e-mail address, but the blank page happens whether I'm logged in or not even when logged in as admin.

I originally posted this to the Features/Usability forum but xavi suggested it may be a bug so have now posted it here.

Have now also shown that this problem occurs with a new/clean install so doesn't seem to be related to the upgrade process.

When Shadowbox is activated, when an image in a gallery is clicked, instead of displaying using the normal shadowbox method, the image opens in a new window that's otherwise blank. Shadowbox worked in Tiki 2 prelease versions.