Category: Error

{syntax type="tiki" editor="plain"}
In the italian version of Tikiwiki 3.3 near login boxes the link "I forgot the password" is "Ho dimanticato la password". The correct translation is "Ho dimenticato la password".

* report about usability (& scary bug for the end user because WSoD)
** intro: you have one site with a custom theme in a tiki installation. No change of theme is allowed for users.
** problem (when): you upgrade from tiki3 to tiki5 to a new folder in your server or new server, without your new custom theme there yet.
** problem (what): after upgrade, anons. see the site in thenews.css (for instance). Good enough. But once you log in in the upgraded site, you get WSoD, until you are able to remove the .css seletions stored in tiki_preferences table.

Kind of an edge case, but if layout theme names change between versions or due to development work, so there's a mismatch between the stored layout preference and the layouts listed in the files, then a blank screen is the result. The database needs to be edited directly to correct the problem (tiki_preferences site_layout updated to match available layout names).

There should be a fallback to a default layout ("basic") if the preference name isn't found, similar to how the site will fall back to the default theme if the selected theme or stored-preference theme isn't found.

I tried to access the poll at dev.t.o using the Setting menu item, polls.
It goes to a 500 page error.

Polls are working fine at tiki.org

On a Tiki23 I use description for meta tag (may be unrelated) and if I insert a description that is more than 200 char (more than 199 I think) on save I have a white screen.

{syntax type="tiki" editor="plain"}
This seems solved in Tiki 5.

''type content'' : Problem, way to go around and may be a quick way to go to a solution

Hy,
4.0, 4.1

I test all functions including those that are not finalized.

The problems occurs with Firefox 3.5 not with IE8 (other ie not tested neither opera, google etc...)

In WISIWIG text editing WIKI obtained in circumstances that I can not confirm the background color of textarea is black when you scroll to the end of long text (the text is more long than the height of textarea).
The content text exist and you can see it if you select it and change the text background color.
The problem is the scroll with the background property color (in strasa css #F3FCFE color)

''Complements''
*Problems occurs in wysiwyg mode (not in view source mode)
*If you change the background color of the text you can see it
*The problem is directly linked to scroll, when you change the textarea size (for example go to "fullscreen" edit), the black background appears at the bottom just one line after beginning to scroll down



I hope to have provided informations to go straight to the bug.

Best regards

If I add a poll in a module, a registered user can see it even though he can't vote.

It is currently possible to see links to tracker items we are not supposed to see. (clicking gives error message)

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!

--I was originally having a smaller wysiwyg bug on my tiki 12 instance, but I'm not sure what is going on with it anymore after testing with a fresh instance.

On the current instance created for this ticket, the formatting bars (Format, styles, font, size, etc) are not showing up for WYSIWYG, and going to the toolbar admin and changing things doesn't change the toolbars for the WYSIWYG, but changing things for "Wiki only" added them to the WYSIWYG too.

It seems to be acting really weird, and "link" and "unlink" show up when you go to the editor toolbar admin, but don't show up in the editor (feature is enabled).

user: admin
password: 12345

update: looks like maybe WYSIWYG only shows the "visual wiki" toolbar, but I'm not too familiar with how that works. Hopefully this is user error, but I've customized editor toolbars in tiki wiki before, and this seems to be working strangely.--

!!Here is a more concise explanation of what is going on. Ignore Above

Turns out it was in fact mostly user error + confusingness, though there is a bug.

bug:
Setting the toolbar selection mode to "WYSIWYG Only", and then adding an icon to the toolbar adds the icon for all editors instead of just WYSIWYG. This is present in tiki 11 also, but I can't seem to destroy the instance and test other versions (tried from multiple browsers).

Possible bug:
"Link" icon tiki WYSIWYG does not set link element class to "wiki" by default, resulting in possible css/styling inconsistencies. Links created with square bracket tiki syntax always have class="wiki external". I think that links from both should be generated with same class so css can apply to both without having to set css for all anchors just to cover links generated by "Link" (but I'm not a CSS guru, so I don't really know css best practices. Seems inconsistent though).

Discussion/What I thought was a bug:

I had previously talked about the lack of formatting bars (Format, styles, font, size, etc) in wysiwyg being a bug, but this is not really bug. In tiki 12, the "Use Wiki syntax in WYSIWYG" perference's description says "Using wiki syntax in wysiwyg mode will limit toolbar to Wiki tools", which would make it so that only the visual wiki toolbar shows up when you are in the wysiwyg editor, and you don't get any WYSIWYG toolbar icons (as I understand it).

When you enable WYSIWYG, the "Use Wiki syntax in WYSIWYG" preference is enabled along with it by default, meaning that by default WYSIWYG does not actually have any WYSIWYG toolbar functionality, and is really tiki toolbar icons with a wysiwyg text interface.

The reason I thought this was a bug was because I did not understand the implications of "Use Wiki syntax in WYSIWYG", and in tiki 11.0, with "Use Wiki syntax in WYSIWYG" enabled, the toolbars were still usable. The description still stated "Using wiki syntax in wysiwyg mode will limit toolbar to Wiki tools" however, suggesting that perhaps in tiki 11.0, the fact that the formatting bars still worked was itself a bug. However, if that can happen through a bug maybe that is something that should happen intentionally? Seems like a big loss that if you enable "Use Wiki syntax in WYSIWYG" you lose the entire WYSWIWYG toolbar, and you don't get a hybrid toolbar. Anyway, just throwing that out there/explaining confusion.

Problem: Corrupted URLs when linking pages using international characters in the page name.
It works when the link is first saved, but a reload and a subsequent saved will corrupt the URL.
The same problem occurs in 6.x 7.x and 8.0 SVN.

In these tests the WYSIWYG editor is used.
(I have formatted the output a little for better readability)

--- Test using latest 8.0 SVN version ---

1. Create the page "ÆØÅ page"
2. Create the page "MyLinkPage"
3. Add a link to "ÆØÅ page" on MyLinkPage, using the link tool in the menu
4. Save and exit editor

Content of MyLinkPage (wiki source view)
<p><a class="wiki" href="tiki-index.php?page=%C6%D8%C5+page">ÆØÅ page</a></p>

Content of MyLinkPage in the database (tiki_pages.data)
'<p><a class="wiki" href="tiki-index.php?page=%C6%D8%C5+page">ÆØÅ page</a></p>'

5. Edit MyLinkPage again <<<<<<<<<<<<< URL is no longer encoded, but the page name is

Content of MyLinkPage (WYSIWYG source view)
<p><a class="wiki" href="tiki-index.php?page=ÆØÅ+page">&AElig;&Oslash;&Aring; page</a></p>

6. Add some text in the WYSIWYG editor
added some text

8. Save and exit editor <<<<<<<<<<<<<<<< CONTENT HAS A CORRUPTED URL

Content of MyLinkPage (wiki source view)
<p><a class="wiki" href="tiki-index.php?page=%C3%86%C3%98%C3%85+page">ÆØÅ page</a></p>
<p>added some text</p>

Content of MyLinkPage in the database (tiki_pages.data)
'<p><a class="wiki" href="tiki-index.php?page=%C3%86%C3%98%C3%85+page">ÆØÅ page</a></p>
<p>added some text</p>
'

---- end of test ----

As far as I can see, the problem occurs when the WYSIWYG editor loads the page
(it works the first time, because the links are not loaded, only saved).

I tried a similar test using the wiki editor
The wiki editor stores the wiki content.
Thus database the content is: ((ÆØÅ page|ÆØÅ page))
The wiki editor has no problems.

A variation is loading the page using the wiki editor, then switching to the WYSIWYG editor
The source in WYSIWYG is afterwards

<p><a class="wiki" href="tiki-index.php?page=Ã?Ã?Ã?+page" title="ÆØÅ page">&AElig;&Oslash;&Aring; page</a><br />
added some text</p>

thus also corrupted the URL.

Some work colleagues are testing tiki for their own department. They did setup their test tiki with tiki18 and full wysiwyg editor as the main editor in wiki pages, using wiki syntax.
When they open the page for edition, and they click on the help icon, the popup help shows up. they select the tab for plugins, and when clicking at the icon of a plugin shows nothing (no plugin helper popup is shown).
This usability bug might be critical for them (they seem to be comparing Tiki with other professional wikis out there).

Some js bug maybe somewhere?

I'll try to reproduce in a show.t.o instance.
For some reason, I can't reproduce it yet:
http://xavi-9794-7146.show2.tikiwiki.org/tiki-editpage.php?page=foo
u: admin
p: 12345

I'll adapt that page to the same content that produces the issue in the tiki behind our intranet at work. in the mean time, leaving as "pending" and with tag "worksforme"

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.

Uploading any non image into the file gallery with the upload image button in the WYSIWYG editor works fine. But when selecting that file to put in the site, TikiWiki incorrectly specifies that the file is an image. This results in the webpage with "File is not an image".

My php is 5.3 and fileinfo extention is set up correctly. I can correctly display the file by switching to Wiki text mode and changing the designation from "img" to "file"

OK, before anyone calls me stupid, the button does say "Choose or Upload Images" There is no button for choosing and uploading files, but I assume that since the "File Gallery" and not the "Image Gallery" is being called up, it should be able to handle both. If not, then I guess someone needs to add a button to CKEditor.

I created a show-me instance to show the problem in the current branch. However, this version has the option to add more buttons to the WYSIWYG. There is a file button that solves this problem. But this is a major hassel for me in the 11.1 branch. Any way I can get the file button in version 11?

The WYSIWYG doesn't load the bars with size and font into the post (''and several other tools in the toolbar'') .
Please see this short video recording which explains and shows the issue:
[https://drive.google.com/file/d/1-kZWIMVLvu-Z9AO_C0nsPKupW194NYQ_/view|https://drive.google.com/file/d/1-kZWIMVLvu-Z9AO_C0nsPKupW194NYQ_/view]

Kind regards
PowerQuest

Only happens in real IE7. IE8 in IE7 compatibility mode does not have this problem.

Basically an attempt to edit the image plugin parameters followed by clicking on "Insert" results in a JS error "Invalid argument" at line 4929 of lib/jquery/jquery.js (r30367). If you continue through the error, the image disappears.

{CODE()}
clean: ....
.....
if ( fragment ) {
.......
if ( ret[i].nodeType === 1 ) {
ret.splice.apply( ret, [i + 1, 0].concat(jQuery.makeArray(ret[i].getElementsByTagName("script"))) );
}
fragment.appendChild( ret[i] ); // this is line 4929
{CODE}

If the image is at the end of a paragraph (or on a line of it's own) resulting in the following cases, you will have the problem.

{CODE()}
<p>
Paragraph text{img fileId="10" rel="box[g]" imalign="left"}</p>
{CODE}

{CODE()}
<p>
{img fileId="10" rel="box[g]" imalign="left"}</p>
{CODE}

If you instead have text after the image, the problem does not appear. For example, the following are both OK.

{CODE()}
<p>
Paragraph text{img fileId="10" rel="box[g]" imalign="left"}Paragraph Text</p>
{CODE}

{CODE()}
<p>
{img fileId="10" rel="box[g]" imalign="left"}Paragraph Text</p>
{CODE}

I suspect (just a theory) maybe the plugin replacing procedure is wiping out the closing para tag leading to malformed HTML that IE7 does not like. A search on the web on similar errors in relation to Jquery show that IE7 is very sensitive to unclosed tags or malformed HTML in inserted text.

[http://tikiwiki.org/tiki-view_blog_post.php?blogId=2&postId=249|See an exemple of result]


It was working fine in BRANCH-1-8

ON aVersion 2.2 installation on a Windows server.

When I use the WYSIWYG editor and select the insert internal link icon, the window appears titled "Tiki Link - insert internal link" and the squares indicating loading are blinking, but it hangs (and does not bring up the list of links).

{syntax type="tiki" editor="plain"}
Paragraphs appear with an extra line of whitespace when laid out in the wysi editor.

The same page performs as expected for white space if you click edit, switch to wiki editor and save.

But then: Re-opening the same page (with wysi set as site default) shows everything on one line with just spaces where the linefeeds used to be.


Also just noticed: Editing post makes a new publication date--in advance of current date time.

The topic says it all. I am running SLES Linux 10 for wiki host and with MySQL on a Netware box on the back end. MySQL Version 4.0.26a over TCP/IP.

I hope this helps.

{syntax type="tiki" editor="plain"}
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.

{syntax type="tiki" editor="plain"}
The following error occurs always when i follow a link from tiki-searchresults.php and the search string contained a slash (/).

E.g. searching for 343/07 reveals the correct article. On tiki-searchresults.php the string "343/07" is highlighted (tiki-searchresults.php?highlight=343%2F07&where=pages&search=Los). Following the link (articleXXXX&highlight=343/07) I get this error message:

^Error: the xajax Javascript Component could not be included. Perhaps the URL is incorrect? url: lic/ajax/xajax/xajax_js/xajax_core.js^

The problem is caused by the slash in (articleXXXX&highlight=343__/__07). If I change the url manually to "articleXXXX&highlight=343" everything's fine.

Creating a XML Zip worked in 12.x, in tiki 15+ it ends in a white screen with no zip download.

Creating a XML Zip worked in 12.x, in tiki 15+ it ends with 2 php error messages:

Strict Standards: Redefining already defined constructor for class XML_Parser in /var/www/drsassafras-11658-6198/vendor_extra/pear/XML_Parser/Parser.php on line 222

Deprecated: Assigning the return value of new by reference is deprecated in /var/www/drsassafras-11658-6198/vendor_extra/pear/XML_Parser/Parser.php on line 611

admin password for show instance: 12345

Importing of a XML zip fails.

Attached is an XML zip created on 12.x

This is a php7 issue. It works fine with php 5.x

PHP Error: PHP Parse error: syntax error, unexpected 'new' (T_NEW) in /Sites/tiki/vendor_extra/pear/XML_Parser/Parser.php on line 611

Tiki show instance not useful as its hosted on php 5.x

I have a xml.zip attached for trial reasons, but it does not matter what is being imported, it all fails.