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

The WYSIWYG editor supports tables whether the content is stored as HTML or as Tiki/wiki syntax. However, Tiki syntax only supports basic tables. CKeditor offers advanced operations on tables via secondary click -> Cell, such as merging, splitting, and propably everything in Cell Properties.

The result of advanced operations will generally be lost. In a few cases, these operations will properly carry to wiki format after conversion.
After advanced operations, the issue will be noted either after saving, or simply by switching to Source and going back to WYSIWYG.

For example, the table with a fixed left cell width...
{CODE(colors="htmlmixed" theme="default")}<table class="wikitable table table-striped table-hover">
<tbody>
<tr>
<td class="wikicell" style="width: 123px;">1</td>
<td class="wikicell">3</td>
</tr>
</tbody>
</table>{CODE}
...is simply converted to wiki...
{CODE(colors="tiki" theme="default")}||1|3||{CODE}
This issue exists in both Tiki 12 and r65080 trunk.

the button "insert internal link" (on the WYSIWYG-editor) doesn't work.

it opens a new window "local.php not found -- This is normal if you have not run the tiki installer yet".


(but i run the tiki installer)

the button "insert internal link" (on the WYSIWYG-editor) doesn't work.

it opens a new window "local.php not found — This is normal if you have not run the tiki installer yet".


(but i run the tiki installer)

If you check the setting "Wysiwyg Mode" in the Wizard so that you have the Wysiwyg Editor and edit a page it appears that there is a bug regarding brackets.

What I did was, I edited the standard homepage from tiki wiki and wrote a h1 heading with "Hier steht jetzt irgendwas" and beneath it i added a ["Test"].

When I safe the page and reload it, the browser shows everything correct, accept that there is a unencoded sign (the ? on a black diamong) behind "jetzt".

If I try to edit the page again, the input field is empty, accept for "ajax error" and I get the error message:

Fehler
json_encode - Malformed UTF-8 characters, possibly incorrectly encoded

Will try to reproduce my issue on a tiki instance here.

12.x html code embedded in a tracker item field text-area-with-wysiwyg lost after edition

See it in action here:
http://xavi-9794-5186.show.tikiwiki.org/tiki-view_tracker_item.php?itemId=1

u: admin
p: 12345

Code added (without the code plugin tags):

{CODE()}
{HTML()}<iframe src="http://www.slideshare.net/slideshow/embed_code/33417641" width="427" height="356" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px 1px 0; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe> <div style="margin-bottom:5px"> <strong> <a href="https://www.slideshare.net/xavi/140413-fs-cat2014xavierdepedroconeixementlliure" title="Hack-tivisme amb eines i continguts alliberats: beneficia-te&#x27;n!" target="_blank">Hack-tivisme amb eines i continguts alliberats: beneficia-te&#x27;n!</a> </strong> from <strong><a href="http://www.slideshare.net/xavi" target="_blank">Xavier de Pedro</a></strong> </div>{HTML}
{CODE}

After edition of that tracker item:

http://2014.forumsocialcatala.cat/item11

...in field: "Presentations", with wysiwyg enabled, the html code was lost, and only the non html code is present (converted to wiki) with the surrounding html plugin tags.

{CODE()}
{HTML( wiki="0")}__[https://www.slideshare.net/xavi/140413-fs-cat2014xavierdepedroconeixementlliure|Hack-tivisme amb eines i continguts alliberats: beneficia-te'n!]__ from __[http://www.slideshare.net/xavi|Xavier de Pedro]__{HTML}
{CODE}

(I had to add the html code again)

12.x: accents not shown properly in forum posts when wysiwyg-html is on

Reproduced in precarios~~black:.org~~

And in
http://xavi-9794-5228.show.tikiwiki.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=1&amp;thread_sort_mode=commentDate_asc#comments

See he reply that says:
{CODE()}
Otro m&aacute;s
{CODE}

and it should say:
{CODE()}
Otro más
{CODE}

If you disable storing syntax as HTML but revert it to store wiki syntax, then everything is fine again for new posts.

When you have your Tikiw with Wysiwyg enabled, and using wiki syntax in the wiki pages, then page alias links are saved as internal links.

Example for the domain example.com. This syntax in that context at page "foobar":
{CODE()}
(alias(foo bar))
{CODE}

Would be converted, after page save, into:
{CODE()}
((foobar|foo bar))
{CODE}

And therefore, we loose the alias name. If you attempt to visit page

http://example.com/foo+bar

you would get that the page doesn't exist, instead of showing you the aliased page

http://example.com/foobar


Reproduced here:
http://xavi-9794-5083.show.tikiwiki.org/tiki-index.php?page=foobar
u: admin
p: 12345

Wywiwyg editor in mobile mode never ends to load in article body

Reproduced using either chrome or firefox on an android smartphone with 1Gb of RAM

~tc~ here
http://creientsendiaspora.org/tiki-edit_article.php?topicId=1
~/tc~
See title (description to be improved in a later stage, even if title shoyld be enough)

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

If a user uses CTRL-Z on a page that they are editing to undo a change, they will break all internal wiki links on the page on the next save.
This appears to only happen when editing with firefox.

The edit button (and switch to wysiwyg) link to nowhere (except back to homepage.)

This appears to be an ajax related problem many buttons/links do not work.

verified on my site and 110.tikiwiki.org

edit button links to:
http://sitename.com/#


switch to wysiwyg does not work, navigation buttons in list-pages,

After creating a new blogpost and saving it, the post shows a lot of empty lines at the beginning of the post.
Looking at the html result, there are about 9 <br/> entries before the actual text.

The branch is downloaded on wednesday, 25th of June 2008 8AM GMT.

A 1.10b1 release of about a month ago did not show this behaviour.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

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

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

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

{syntax type="tiki" editor="plain"}
In displaying a calendar event it doesn't display as written in the edit window using WYSIWYG. Instead it displays with the HTML code.

The WYSIWYG editor should have a button to create HTML comments that will only be visible in edit mode, and not in read mode.

As with all HTML, the comment tags should not be visible in WYSIWYG mode. The commented text should be a different color; perhaps grayed out.

This feature would enable editing discussion to happen right within the page being edited. Editors could more easily reference the text under discussion, since it would be right next to the comments. Discussing pages separately in the forum would no longer be needed, or would be optional.

{syntax type="tiki" editor="plain"}
I created a test newsletter on a new tiki 4.x (using recent svn, similar to tiki4rc1)

* Switched editor to wysiwyg
* copied some content from this page: http://en.wikipedia.org/wiki/Paul_R._Ehrlich (from the title "Paul R. Ehrlich" until the title "other activites" (so that, it's including also a few images available on the internet, in case it matters)
* cliked on the switch editor button (to go back to a normal editor showing wiki syntax)
* a blank page is produced, after 10-15 seconds.

! Update to below, see attached screenshot. Just discovered a pop-up application for pasting text. Very weird to see after decades of pasting text the old fashioned way ;-)

!!WYSIWYG Editor Tiki 5 RC-1
fresh from svn

__Cannot paste text into editor __
*anything pasted just disappears
*tried wiki and blog post
*tried 5 Alive and The News themes
*tried Mac Safari and Chrome


__Cannot paste text__
TW 4.1: Edit a wiki page with WYSIWYG editor:

#Can type & use formatting tools.
#Cannot paste text. When Text is pasted, the desired text appears very briefly, sort of flashes on the screen, then disappears. Saving at this point saves any typed or formatting changes, but the pasted text does not appear.
#Can switch to Wiki Editor, paste text, switch back to WYSIWYG and format it from there.

{syntax type="tiki" editor="plain"}
Hi,

Into the wysiwyg help on plugins, the height of the scroll list of plugins is superior to the eight of the popup. So the bottom of the list and scroll commands are not accessible.

The height is calculated from the height of the popup with is resizable.

[enhance] request : set a button into "plugin" to select the suitable plugin.

May be change tooltip of help to Help "Help on wysiwig syntax and plugins" rather than "Wysiswig"

The plugin manager should include the "help plugin which is into help", after the choice of plugin the manager help to fill it and include it.

I imagine that's the working is doing but I just add may be my view of this part of the Wysiwyg implementation.

{syntax type="tiki" editor="plain"}
Since r19838, Admin templates uses the WYSIWYG editor even if WYSIWYG was not enabled. The root of this problem is usage of the Smarty wysiwyg variable, which is not always set since r9595.

See video

{sign user="pascalstjean" datetime="2013-08-20T18:15:37+00:00"}
+1 for this idea