Category: WYSIWYG (What You See is What You Get)

WYSIWYG is now a basic feature in 12, but the panel is not visible from tiki-admin.php

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.

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

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)

When using WYSIWYG in HTML mode (wysiwyg_htmltowiki disabled), the WYSIWYG help available by clicking the blue question mark at the right assumes that the wysiwyg_wiki_parsed preference is enabled:
# The first tab claims that "Wiki plugins can be used and edited in WYSIWYG mode" since r30245.
# The second tab offers adding plugin calls, as if they would be interpreted.

In fact, it is known that the implementation "is not designed to work best" when wysiwyg_wiki_parsed is disabled (even though [https://tiki.org/tiki-view_forum_thread.php?comments_parentId=67421|the idea behind wysiwyg_wiki_parsed is unrelated to WYSIWYG]). The first tab contains:
{QUOTE()}
This new implementation is designed to work best with some site preferences set in a certain way. These can all be found on the WYSIWYG admin page. A profile to set these up correctly can be found on profiles.tiki.org which can be applied using the profiles admin page.
{QUOTE}
The WYSIWYG_6x profile enables wysiwyg_wiki_parsed.

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

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

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"

This tracker item could not be found

The WYSIWYG editor removes some syntax from the page. Such as "~126~~110~~112~~126~...~126~~47~~110~~112~~126~". It also converts characters, which are specified with the "~NNN~" syntax to ordinary characters.

To reproduce:

- Create a new page with the non-WYSIWYG editor.
- Enter "~126~~110~~112~~126~! XX~126~~47~~110~~112~~126~"
- Save the page. It shows up as intended: "! XX"
- Open the page and switch to the WYSIWYG editor.
- Click on "Save". Now the "XX" shows up as a heading.
- Open the page again and switch to the non-WYSIWYG editor. The "~126~~110~~112~~126~" and "~126~~47~~110~~112~~126~" parts have vanished.

With quoted characters, such as "~126~033~126~" it's similar. They get converted to non-quoted characters when the page is opened in the WYSIWYG editor and are saved that way when the page is saved.

This bug makes the WYSIWYG editor next to unusable.

The WYSIWYG editor has a transparent background that seems to be hard-coded and unaddressable by css. It appears in an iFrame so the page's body background colour is seen in the textarea.

This makes it unusable for themes with dark backgrounds like Strasa as you have basically black-on black text.

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?

In version 12 the Wysiwyg editor is no longer an experimental feature.
The wysiwyg help text should be updated.
The help text should cover both fullscreen and inline editing, since the toolbar icon to display it is there for both.

{img fileId="435"}

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

Most of the icons are not showing up for WYSIWYG kama theme in firefox.

Demonstrated on instance.

{img src="http://i.imgur.com/cCLoy3R.png"}

Just for clarity, I don't believe its a local cache issue. I tried it, and someone I work with tried it, different browsers, cleared caches, etc.

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

When you double click a link in the WYSIWYG editor the dialog says square bracket "mailto" links are wiki pages (with no page filled in) and wiki page links are external ones.

This bug happens when you have WYSIWYG editing enabled, and a wiki page template that looks like this:

{CODE()}
[tiki-index.php?page=HomePage#SomeSection]
{CODE}

i.e., it contains a link to a page section.

If you setup a quickedit module to create a page with that template, then when you save the page, the #SomeSection part of the link gets deleted. So the link points to HomePage instead of HomePage#SomeSection.

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

This seemed to be working correctly on my previous version of Tiki Wiki (18.x). However, some of the primary WYSIWYG buttons are now unusable.
This same behaviour can be seen on the [https://demo.tiki.org/18x/tiki-editpage.php?page=HomePage|demo Site].

In WYSIWYG mode, the link buttons show the dialog, but does not 'insert' and the table builder button show s a dialog without any rows to insert.

The browser console error I'm getting when clicking the Table Builder button in WYSIWYG mode is as follows:
{CODE(theme="default")}
tiki-toolbars.js:92 Uncaught TypeError: Cannot read property 'indexOf' of undefined
at dialogSelectElement (tiki-toolbars.js:92)
at dialogTableOpen (tiki-toolbars.js:394)
at HTMLDivElement.open (eval at <anonymous> (tiki-toolbars.js:50), <anonymous>:1:25)
at $.(/tiki/anonymous function).(anonymous function)._trigger (http://localhost/tiki/vendor_bundled/vendor/components/jqueryui/jquery-ui.js:697:13)
at $.(/tiki/anonymous function).(anonymous function).open (http://localhost/tiki/vendor_bundled/vendor/components/jqueryui/jquery-ui.js:12215:8)
at $.(/tiki/anonymous function).(anonymous function).open (http://localhost/tiki/vendor_bundled/vendor/components/jqueryui/jquery-ui.js:144:25)
at HTMLDivElement.<anonymous> (jquery-ui.js:256)
at Function.each (jquery.js:354)
at jQuery.fn.init.each (jquery.js:189)
at jQuery.fn.init.$.fn.(/tiki/anonymous function) [as dialog] (http://localhost/tiki/vendor_bundled/vendor/components/jqueryui/jquery-ui.js:236:10)
{CODE}

When I create a WYSIWYG table using the editor WYSIWYG table editor is create a code like this is one and single row:

{CODE()}||table|a|b %%% 1| |  %%% 2| | ||{CODE}
Carriage returns are turned into wiki syntax and therefor it break the table

It should have been:
{CODE()}||table|a|b
1| | 
2| | ||{CODE}